David Miller wrote:
From: Andrew Gallatin <[EMAIL PROTECTED]>
Date: Tue, 23 Oct 2007 11:11:55 -0400
I've attached a patch which adds support to inet_lro for aggregating
pure acks.
I've applied this patch to net-2.6.25... but!
This needs some serious thinking. What this patch ends up doing is creating
big stretch-ACKs, and those can hurt performance.
Stretch ACKs are particularly harmful when either the receiver is cpu
weak (lacking enough cpu power to fill the pipe completely no matter
what optimizations are applied) or when there is packet loss (less
feedback information and ACK clocking).
It also means that the sender will be more bursty, because it will now
swallow ACKs covering huge portions of the send window, and then have
large chunks of it's send queue it can send out all at once.
Fundamentally, I really don't like this change, it batches to the
point where it begins to erode the natural ACK clocking of TCP, and I
therefore am very likely to revert it before merging to Linus.
Sounds like one might as well go ahead and implement HP-UX/Solaris-like
ACK sending avoidance at the receiver and not bother with LRO-ACK on the
sender.
In some experiements a while back I thought I saw that LRO on the
receiver was causing him to send fewer ACKs already? IIRC that was with
a Myricom card, perhaps I was fooled by it's own ACK LRO it was doing.
rick jones
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
