man mount


Sets or gets the maximum socket receive buffer in bytes. The kernel doubles this value (to allow space for bookkeeping overhead) when it is set using setsockopt(2), and this doubled value is returned by getsockopt(2). The default value is set by the /proc/sys/net/core/rmem_default file, and the maximum allowed value is set by the /proc/sys/net/core/rmem_max file. The minimum (doubled) value for this option is 256.

but I think such a buffer can hold no packets

What values may Linux use for the default unix socket buffer size?


The per-packet overhead is a combination of struct sk_buff and struct skb_shared_info, so it depends on the exact size of these structures (rounded up slightly for alignment). E.g. in the 64-bit kernel above, the overhead is 576 bytes per packet.

Is the above correct? Is there any good reason that the kernel enforces a minimum socket buffer size of 256?

1 Answer 1


Looking at a previously-asked question "What is the minimum SO_RCVBUF value?" and this network programming guide, your suspicions seem correct. UDP and IP packets would get silently dropped because there would insufficient room to store the packet, and (from what I gather) TCP connections wouldn't work because the minimum transfer window size would be larger than the buffer; in any case, you wouldn't receive anything.

As to why the minimum socket buffer size is so small, that's probably a historical artifact in the documentation. Looking at the Linux source v4.0 (linux/include/net/sock.h), it appears that the actual minimum size of quite a bit larger (2048+the aligned size of sk_buff) and has been for quite some time. My guess as to why the documented minimum is so low is to allow for raw access to ATM cell packets, which were 48-53 bytes, but this merely a guess.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .