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

[Sowmini Varadhan <sowmini.varadhan@oracle.com>]

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