From: Sowmini Varadhan
Date: Mon, 14 Mar 2016 14:06:42 -0400
> However, it would still be nice to know exactly what distribution
> issues come out of modparam.
Module parameters mean unstable interfaces, and provide inconsistent
ways to do the same exact thing from driver to driver and protocol
In any case, to wrap up this thread.
I managed to set this up with sysctl. End result gives me a tunable
per netns (which modparam would not), and thanks to the RDS reconnect
infra, can be done dynamically at any time, not just at startup.
And it is more compact than a daemon-y solution.
I'll s
On Fri, Mar 11, 2016 at 8:39 PM, Sowmini Varadhan
wrote:
> 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 abi
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 underst
On Fri, Mar 11, 2016 at 7:44 PM, Sowmini Varadhan
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
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
On Fri, Mar 11, 2016 at 6:43 PM, Sowmini Varadhan
wrote:
> On (03/11/16 11:09), Stephen Hemminger wrote:
>> Module parameters are a problem for distributions and should only be used
>> as a last resort.
>
> I dont know the history of what the distibution problem is, but I
> did try to use sysctl a
On (03/11/16 11:09), Stephen Hemminger wrote:
> Module parameters are a problem for distributions and should only be used
> as a last resort.
I dont know the history of what the distibution problem is, but I
did try to use sysctl as an alternative for this. I'm starting to
believe that this is on
From: Sowmini Varadhan
Date: Fri, 11 Mar 2016 13:29:49 -0500
> Some payload sizes/patterns stand to gain performance benefits by
> tuning the size of the TCP socket buffers, so this commit adds
> module parameters to customize those values when desired.
>
> Signed-off-by: Sowmini Varadhan
No m
On (03/11/16 11:09), Stephen Hemminger wrote:
>
> Module parameters are a problem for distributions and should only be used
> as a last resort.
I was not aware of that- out of curiosity, what is the associated problem?
What would be the alternative recommendation in this case?
--Sowmini
On Fri, 11 Mar 2016 13:29:49 -0500
Sowmini Varadhan wrote:
>
> -#define RDS_TCP_DEFAULT_BUFSIZE (128 * 1024)
> +static int sndbuf_size = 16384;
> +module_param(sndbuf_size, int, 0444);
> +MODULE_PARM_DESC(sndbuf_size, "SO_SNDBUF size of kernel tcp socket");
> +
> +static int rcvbuf_size = 87380
Some payload sizes/patterns stand to gain performance benefits by
tuning the size of the TCP socket buffers, so this commit adds
module parameters to customize those values when desired.
Signed-off-by: Sowmini Varadhan
---
net/rds/tcp.c | 16 +++-
1 files changed, 15 insertions(+)
12 matches
Mail list logo
