lkml.org 
[lkml]   [1998]   [Mar]   [22]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
DateSun, 22 Mar 1998 09:07:40 -0800
From"David S. Miller" <>
SubjectRe: bug in 2.1.89 include/net/sock.h?
   From: alan@lxorguk.ukuu.org.uk (Alan Cox)
   Date: 	Sun, 22 Mar 1998 16:57:20 +0000 (GMT)
   But its valid to change the owner of an existing sk_buff anyway

Note that the other day Alexey and myself noticed another set of
oddities in the current SKB ownership behavior in various situations.

Since nearly every TCP handled SKB, both the original and the clone
created for transmission, gets ownership to a socket, the following
two cases arise due to the memory charging scheme:

1) When sending ACK frames, after transmission the device frees the
   SKB, causing the data_ready callback to get called which wakes up
   the process unnecessarily.  Also ACK frames are temporal, memory
   should not be charged to the SOCK for this case, yet we must link
   in the SOCK to the SKB for routing cache purposes etc.

2) In the transmit queue (both in the existing stock 2.1.90 code and
   in my upcoming rewritten TCP output queueing engine) the clones
   created are not only charged for the full amount of data to the
   SOCK, on transmission freeing of the SKB the SOCK process is
   awoken, again via the data_ready callback.

Both these cases add undue wakeups to TCP senders and receivers.

Alan, I know how touchy you are about our SOCK memory charging
policies, so let me know if my analysis here is kosher.  Because if it
is, I want to fix it.

Later,
David S. Miller
davem@dm.cobaltmicro.com

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu

\
 
 \ /
  Last update: 2005-03-22 12:41    [from the cache]
©2003-2008