Here's a patch to make that prequeue comment a little clearer. Look ok?
Signed-off-by: Andy Grover <andrew.grover@xxxxxxxxx>
===== include/net/tcp.h 1.105 vs edited =====
--- 1.105/include/net/tcp.h 2005-02-22 10:45:31 -08:00
+++ edited/include/net/tcp.h 2005-04-28 14:02:43 -07:00
@@ -1560,6 +1560,13 @@
* idea (VJ's mail "Re: query about TCP header on tcp-ip" of 07 Sep 93)
* failed somewhere. Latency? Burstiness? Well, at least now we will
* see, why it failed. 8)8) --ANK
+ *
+ * Actually, even though the prequeue is not as important for fast
+ * csum anymore, it is important for scheduling, to generate ACKs
+ * when the data is received by the process, not the stack.
+ * davem says, "Without prequeue, we ACK immediately. This artificially
+ * makes the sender believe it can pump data out at that rate to the
+ * receiver."
*
* NOTE: is this not too big to inline?
*/
The TCP prequeue thing is based on old facts, and has drawbacks.
1) It adds 48 bytes per 'struct tcp_sock'
2) It adds some ugly code in hot paths
3) It has a small hit ratio on typical servers using many sockets
4) It may have a high hit ratio on UP machines running one process,
where the prequeue adds litle gain. (In fact, letting the user
doing the copy after being woke up is better for cache reuse)
5) Doing a copy to user in softirq handler is not good, because of
potential page faults :(
6) Maybe the NET_DMA thing is the only thing that might need prequeue.