Thread (45 messages) 45 messages, 6 authors, 2012-02-27

Re: limited network bandwidth with 3.2.x kernels

From: Eric Dumazet <hidden>
Date: 2012-02-16 18:22:08

Possibly related (same subject, not in this thread)

Le jeudi 16 février 2012 à 12:22 -0500, Neal Cardwell a écrit :
Our team has also run into issues with GRO/LRO "stretch ACKs", and
their negative impact on TCP performance. We have a patch that we've
been working with that deals with the sender-side issues. It turns out
that neither the ABC nor non-ABC byte counting quite fixes the stretch
ACKs issues.

On the receiver side, the approach of changing tcp_grow_window() and
__tcp_grow_window() to adjust things in terms of actual packet size
rather than a fixed 2*MSS sounds great to me as well.

In terms of the original 3.1 vs 3.2 issue report that started this
thread, I didn't see any evidence of LRO or GRO causing stretch ACKs.
(Alexey, would you be able to confim by running "ethtool -k eth0" on
both kernels?) So it seems that probably the original issue is
unrelated to stretch ACKs?
I do believe the "3.1 vs 3.2" issue is a matter of how skb truesize
fixes uncover prior bugs in tcp stack. Some drivers were lying about skb
truesize in hope to avoid these bugs...

For instance, I think we dont open receiver window fast enough in this
case, (and we probably enter the slow __tcp_grow_window() path)

On sender side, there are also issues, because if I have TSO on or off
on my 'netem delay 50ms' machine, performance is completely different.

It might have something to do with BQL. More testings needed.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help