Re: iproute uses too small of a receive buffer

[Ben Greear <greearb@candelatech.com>]

On 10/28/2009 12:05 PM, Patrick McHardy wrote:
> Eric Dumazet wrote:
>> Stephen Hemminger a écrit :
>>> Just having larger buffer isn't guarantee of success. Allocating
>>> a huge buffer is not going to work on embedded.
>>>
>>
>> Please note we do not allocate a big buffer, only allow more small skbs
>> to be queued on socket receive queue.
>>
>> If memory is not available, skb allocation will eventually fail
>> and be reported as well, embedded or not.
>>
>> I vote for allowing 1024*1024 bytes instead of 32768,
>> and eventually user should be warned that it is capped by
>> /proc/sys/net/core/rmem_max
>
> How about this? It will double the receive queue limit on ENOBUFS
> up to 1024 * 1024b, then bail out with the normal error message on
> further ENOBUFS.
>
> Signed-off-by: Patrick McHardy<kaber@trash.net>

First:  This still pretty much guarantees that messages will be lost when
the program starts (when messages are coming in too large of chunks for small buffers)
If you are debugging something tricky, having lost messages will be
very annoying!

Second:  Why bail on ENOBUFS at all?  I don't see how it helps the user
since they will probably just have to start it again, and will miss more
messages than keeping going would have.

And, even 1MB may not be enough for some scenarios.  So, probably best to
let users over-ride the initial setting on cmd-line.  If not, then use
a large value to start with.

Thanks,
Ben



-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com