Bill Fink wrote:
Another reason the SO_SNDBUF/SO_RCVBUF values shouldn't include
the kernel overhead. If the user requests 100K of kernel data
buffering, then they should get 100K. It shouldn't matter to the
user that the kernel would actually be using a total of 167K of
memory to satisfy the request for 100K of data buffering.
That could be done with separate atomic variables for allocated data and
allocated overhead, at measurable cost with relatively little gain.
Overhead would still have be tracked and limited separately to handle
cases where the overhead is far greater than the amount of pure data.
For example, in SCTP an application can send a series of short,
uncollapsable messages with an overhead / data ratio of 10x or more.
[It is actually a problem beyond the API - RFC2960 defines the SCTP
receive window in terms of data bytes, but the actual overhead varies
greatly with message size making proper advertised receive window
determination problematic]. TCP is similar, except one can collapse
skbs when the overhead gets too high.
- Mark B.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
