netdev - Re: [PATCH net-next] rds-tcp: Add module parameters to control sndbuf/rcvbuf size of RDS-TCP socket

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 11 Mar 2016 20:07:46 -0800
From:	Tom Herbert <tom@...bertland.com>
To:	Sowmini Varadhan <sowmini.varadhan@...cle.com>
Cc:	Stephen Hemminger <stephen@...workplumber.org>,
	"David S. Miller" <davem@...emloft.net>,
	Linux Kernel Network Developers <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next] rds-tcp: Add module parameters to control
 sndbuf/rcvbuf size of RDS-TCP socket

On Fri, Mar 11, 2016 at 7:44 PM, Sowmini Varadhan
<sowmini.varadhan@...cle.com> wrote:
> On (03/11/16 19:21), Tom Herbert wrote:
>> You could consider and alternate model where connection management
>> (connect, listen, etc.) is performed in a userspace daemon and the
>> attached to the kernel (pretty much like KCM does). This moves
>
> You have to remember that, like it or not, RDS has some IB legacy
> compat requirements that cannot be shed easily.  The above suggestion
> suddenly requiring an extra daemon per node in a cluster
> involving 100's of nodes with very complex DB setup procedures and
> rigid HA requirements (nodes in the cluster try to reconnect
> on connection failure).  An extra daemon, with its own startup requirements
> and additional latency, would be hard to justify for something
> that can otherwise be done with module_param.
>
You are describing your deployment of RDS, not kernel implementation.
What I see is a very rigid implementation that would make it hard for
many us to ever even consider deploying. The abilities of applications
to tune TCP connections is well understood, very prevalent, and really
fundamental in making TCP based datacenters at large scale. Any way,
it was just an idea... ;-)

> As such, the above suggestion is even non-trivial than the "ugly" code
> I referred to in my previous email.
>
> It is actually far simpler to just tell the cluster-setup scripts to just
> refrain from an ifup of the relevant interfaces till all the config
> is set up.
>
> Besides, the basic problem remains: for an arbitrary kernel module
> that has parameters that need to be customized before module init,
> what are the options today?
>
Maybe add one module parameter that indicates the module should just
load but not start, configure whatever is needed via netlink, and then
send one more netlink command to start operations.

> --Sowmini