From: Mark Butler <[EMAIL PROTECTED]>
Date: Fri, 31 Mar 2006 10:26:05 -0700
> 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
>
From: Bill Fink <[EMAIL PROTECTED]>
Date: Fri, 31 Mar 2006 10:15:08 -0500
> 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 wo
From: Andi Kleen <[EMAIL PROTECTED]>
Date: Fri, 31 Mar 2006 13:11:21 +0200
> For TCP it doesn't apply anymore though because the kernel would
> do a GC of the skbs in this case. So maybe it could be changed for STREAM
> sockets.
TCP does some clever things to determine overhead on the send
side,
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 th
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
On Friday 31 March 2006 09:24, David S. Miller wrote:
> 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 sa
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 th
On Thu, 30 Mar 2006, Mark Butler wrote:
> David S. Miller wrote:
>
> >This has been this way for centuries and it's the correct behavior.
> >
> >We double it on the way in to account for "struct sk_buff" etc.
> >overhead, applications assume that the SO_RCVBUF setting they make
> >will allow that
David S. Miller wrote:
This has been this way for centuries and it's the correct behavior.
We double it on the way in to account for "struct sk_buff" etc.
overhead, applications assume that the SO_RCVBUF setting they make
will allow that much actual data to be received on that socket.
Applicati
This has been this way for centuries and it's the correct behavior.
We double it on the way in to account for "struct sk_buff" etc.
overhead, applications assume that the SO_RCVBUF setting they make
will allow that much actual data to be received on that socket.
Applications are unaware that "str
Begin forwarded message:
Date: Thu, 30 Mar 2006 09:33:54 -0800
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: [Bugme-new] [Bug 6309] New: SO_RCVBUF doubled on set not halved on get
http://bugzilla.kernel.org/show_bug.cgi?id=6309
Summary: SO_RCVBUF doubled on set not halved
11 matches
Mail list logo
