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.
Ok. In this case I propose:
1) resource allocation charging is done the same as now
2) a mechanism is added to tell sock_[rw]free() to not make
the "space available" wakeup callbacks, perhaps a sort
of skb_nowakeup() which sets state in the skb, after memory
and SOCK linkage has been made, which makes this happen
and we use this in TCP for ACK frames, and transmission clones
3) we investigate wake up policies past these changes at some
later data, ie. research problem ;-)
Sound good?
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