On Thu, 30 Mar 2006, David S. Miller wrote:
> From: Bill Fink <[EMAIL PROTECTED]>
> Date: Fri, 31 Mar 2006 01:58:35 -0500
>
> > I don't think it makes perfect sense. If there's overhead, fine go
> > ahead and add the overhead, but do it under the covers and invisible
> > to the user.
>
> How in the world would you ever be able to figure out what
> value the kernel is using for the receive buffer?
I guess it depends on what exactly SO_SNDBUF/SO_RCVBUF actually
defines, whether it should include the kernel overhead or not.
I would argue that it should only specify the actual amount of
data space for buffering user application data in the kernel,
and the kernel just allocates whatever additional memory is required
for overhead to insure the user gets the amount of data buffering
requested for the application. There could be a separate mechanism
(perhaps /proc) for monitoring the actual total amount of kernel
memory being used for the user socket.
> It also isn't an exact science, doubling the value is best
> effort.
You've convinced me from your following example that the overhead
can be substantial. But to me the variability of the kernel
overhead, from fairly small proportionally for high performance
bulk data TCP transfers to quite large proportionally for a high
volume stream of small UDP packets, is another argument that
the SO_SNDBUF/SO_RCVBUF arguments to the {set,get}sockopt() calls
shouldn't include the kernel overhead.
> For example, if you, for example, receive a lot of tiny UDP packets,
> wherein the "struct sk_buff" overhead far exceeds the amount of data
> in the packet, it still might not work out. You could specify 100K
> and only be able to receive say 60K of receive data in the socket
> at once.
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.
-Bill
-
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
