size of socket rcvbuf?

[Lars Hofhansl]

Hi,

is there any particular reason why the sndbuf and rcvbuf
of a socket must be < 65536 ?

For an application I need a larger receivebuffer.

Here the relevant part from net/core/sock.c :

case SO_SNDBUF:
if(val > SK_WMEM_MAX*2)
val = SK_WMEM_MAX*2;
if(val < 256)
val = 256;
if(val > 65535)
val = 65535;
sk->sndbuf = val;
return 0;

case SO_RCVBUF:
if(val > SK_RMEM_MAX*2)
val = SK_RMEM_MAX*2;
if(val < 256)
val = 256;
if(val > 65535)
val = 65535;
sk->rcvbuf = val;
return(0);

On Digital Unix we don't have this limitation. In addition
DU returns "No buffer space available" on a request for a
buffer which is too large, whereas Linux silently sets it
to 65535.

Would it have any implications to raise that limit to 131072?

Also in tcp_new_window(...) found in net/ipv4/tcp_output.c
only half of this space is used, because the rest is
supposed to be handling-overhead (?).

Cheers,

Lars

--
Legal Warning: Anyone sending me unsolicited/commercial email
WILL be charged a $100 proof-reading fee. See US Code Title 47,
Sec.227(a)(2)(B), Sec.227(b)(1)(C) and Sec.227(b)(3)(C).

[a...@muc.de]

Lars Hofhansl <lars_h...@public.uni-hamburg.de> writes:

This was changed in 2.1 (to return ENOBUFS), but had to be reverted
back because it broke too many applications.

>
> Would it have any implications to raise that limit to 131072?

DoS problems. The kernel needs to limit the memory to prevent every
user to fill all kernel memory up.

You're not saying for what you need the increased buffer space.
If you need it for TCP it makes no sense to set it >64k (actually 32k)
in TCP and 2.0 anyways, because the maximum window without window scaling
is 32k [64k in theory by a kernel recompile, but Linux limits itself to
32k to cope with broken stacks that do 16bit signed window arithmetic)

If you know that you don't communicate with such a stack you can change
the MAX_WINDOW define in /usr/src/linux/include/net/tcp.h to 64k, if you
need more you need to update to 2.1.

In 2.1 this is fixed - it supports TCP window scaling to support bigger
windows, and it has sysctls (/proc/sys/net/core/*_max) to tune the default
and the maximum buffer size.

>
> Also in tcp_new_window(...) found in net/ipv4/tcp_output.c
> only half of this space is used, because the rest is
> supposed to be handling-overhead (?)

Yes, that is the heuristic used, because Linux doesn't really reserve
the announced space in advance, but plays a gamble instead. In practice
this heuristic works well (although there are some other effects, e.g.
bus mastering cards that allocate full-sized skbuffs and don't copy to
smaller buffers unless the threshold exceeds a particular limit - this
means some memory is wasted)

-A.