Re: bug in 2.1.89 include/net/sock.h?
Alan Cox (alan@lxorguk.ukuu.org.uk)
Sun, 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