Re: network outages

[Greg Troxel <gdt%lexort.com@localhost>]

mlelstv%serpens.de@localhost (Michael van Elst) writes:

> gdt%lexort.com@localhost (Greg Troxel) writes:
>
>>I then did binary search on just changing sendspace.  The highest value
>>that works exactly is 209715 which is 0x33333.
>
> 262144 * 2048 / ( 512 + 2048 ) = 209715.
>
> The relevant setting is kern.sbmax. Setting a socket buffer beyond
> sbmax * MCLBYTES / (MSIZE + MCLBYTES) fails and the TCP protocol
> no longer attaches.

Thanks; I can see how we got here but it doesn't seem like reasonable
behavior.

I could see:

  - If TCP tries to allocate a buffer and it exceeds kern.sbmax, just
    clamp it and proceed.

  - When writing sendspace/recvspace, check sbmax and if it isn't big
    enough error on the setting of {send,recv}space.  Same for
    setsockopt.

  - When writing sbmax, either don't allow it if it's too small for the
    default values of send/recv, or shrink those values to fit (rounded
    to 2048?).  (Assume that this does not reduce already allocated
    buffers.)


> The correction factor obviously should make kern.sbmax show the
> total memory used for a buffer including the headers.  But it's
> just confusing.

I don't quite follow.  It seems sbmax is the memory for the mbufs and
the clusters, so the amount that one can store in clusters is less.
Maybe you are saying sbmax should be about the bytes that can be in a
buffer, not how many bytes a buffer data structure can use.