Re: [PATCH 1/2] Update description of net.sctp.sctp_rmem and net.sctp.sctp_wmem tunables

[Neil Horman <nhorman@tuxdriver.com>]

On Tue, Jul 05, 2011 at 12:00:19PM +1000, Max Matveev wrote:
> On Mon, 4 Jul 2011 10:54:54 -0400, Neil Horman wrote:
> 
>  nhorman> On Mon, Jun 20, 2011 at 06:08:10PM +1000, Max Matveev wrote:
> 
>  >> sctp_rmem - vector of 3 INTEGERs: min, default, max
>  >> -	See tcp_rmem for a description.
>  >> +	Only the first value ("min") is used, "default" and "max" are
>  >> +	ignored and may be removed in the future versions.
>  >> +
> 
>  nhorman> Its accurate to say that only the first value is usd
>  nhorman> currently, but because of the way this sysctl is contructed
>  nhorman> (its used by the sysctl_rmem pointer in the sctp_prot
>  nhorman> struct, which expects an array of three integers in the
>  nhorman> commong __sk_mem_schedule function), we wont' be removing
>  nhorman> the other two values.
> 
> Technically it can be just a single integer - UDP does use it 
> that way but I'm not going to argue, v2 of the patch removed
> that bit.
> 
Yeah, but the only reason udp gets away with it is because the common code in
__sk_mem_schedule only happens to touch the first element in the array.  I
suppose we could just drop the array semantics in the common code and save the
sizeof(int) bytes per protocol, but then individual protocols may (or may not)
access other elements of the array.  Hmm, odd situation.  I'd just as soon leave
the sctp elements in place, they probably have use for ongoing work to fix up
sctp's buffer accounting.

Anywho, thanks!
Acked-by: Neil Horman <nhorman@tuxdriver.com>

> max
>