Re: network outages

On Sat, Mar 21, 2026 at 07:00:55PM -0400, Greg Troxel wrote:
> I could see:
> 
>   - If TCP tries to allocate a buffer and it exceeds kern.sbmax, just
>     clamp it and proceed.

Maybe. But I guess this was just seen as a configuration error, and
the behaviour is already in the original 4.4BSD code.


>   - 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.)

In the original code, that's all compile time values. And with the
sysctl knobs there is no individual handler routine, you just set
a variable.

The "default values" obviously do fit. This all just occurs
when you, as a system adminstrator, tune it and set conflicting
values. I don't think that's a problem.


> > 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.

An mbuf is a header plus a 512 byte (or maybe 256, depending on platform)
data area. When you allocte a cluster (2048 bytes), the data area is
left unused. So 1 mbuf with a cluster can store 2048 bytes but uses
2048 + 512 bytes. Multiply sbmax with the number of open sockets
and you know how much precious kernel memory you need. But using
sbmax as a boundary for tcp_sendspace needs some non-intuitive
computation.

I also doubt that sbmax was ever seen as a boundary for tcp_sendspace,
that's just a side effect. It's a stopgap to prevent applications from
allocating huge socket buffers that exhaust kernel memory.


Greetings,
-- 
                                Michael van Elst
Internet: [email protected]
                                "A potential Snark may lurk in every tree."