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