lkml.org 
[lkml]   [1998]   [Mar]   [22]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
From(Alan Cox)
SubjectRe: bug in 2.1.89 include/net/sock.h?
DateSun, 22 Mar 1998 17:24:51 +0000 (GMT)
> 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.

Your analysis is slightly flawed. ACK frames are a legitimate resource and
need resource management like anything else. The wakeups are a valid issue,
however I dont think we can simply forget about resource management of ack
frames. Whether they should be charged to the socket or to some seperate
ack resource is a good question. That resource itself has to be vaguely
fairly shared.

We can keep ack frames queued locally for 2 minutes or more potentially when
running TCP/IP over a flow controlled link layer such as X.25. Each ack
+ all AX.25 headers could be a couple of hundred bytes.

Maybe we need to wake up on passing a threshold of free space only.


Alan


-
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