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]

Message-ID: <20160312043952.GC26486@oracle.com>
Date:	Fri, 11 Mar 2016 23:39:52 -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 20:07), Tom Herbert wrote:

> 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.

sorry, historically, OS DDI/DKI's for kernel modules have always
had some way to set up startup parameters at module load time.  And 
clusters have been around for a while. 

So let's just focus on the technical question around module config here,
which involves more than TCP sockets, btw.

>  Any way, it was just an idea... ;-)

Thank you. 

Moving on,

> 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.

Even that needs an extra daemon. 

Without getting into the vast number of questions that it raises (such
as every module with startup params now needs a uspace counterpart?
modprobe-r behavior, namespace behavior? Why netlink for every kernel
module? etc)..

One module parameter is as much a "distribution management"
problem as 10 of them, yes? I hope you see that I dont need that module
param and daemon baggage- I can just use  sysctl to set up all my params,
including one bit for module_can_start_now to achieve the same thing.

But it is still more than the handful of lines of code in my patch,
so it would be nice to understand what is the "distribution" issue.

Stepping back, how do we make sysctl fully namespace friendly? 

btw setting kernel socket keepalive params via sysctl is not a problem
to implement at all, if it ever shows up as a requirement for customers.

--Sowmini