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 22:44:21 -0500
From:	Sowmini Varadhan <sowmini.varadhan@...cle.com>
To:	Tom Herbert <tom@...bertland.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 (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.

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?

--Sowmini