GSO (was: Please enter issues into the issue tracker - Issue system organisation needed)

[Eric Dumazet]

Le vendredi 25 février 2011 à 16:48 +0100, Jesper Dangaard Brouer a
écrit :

> Yes, both servers (/proc/sys/net/ipv4/tcp_sack = 1).
> 
> I think that the bufferbloat theory is that SACKs will not work, due to
> the long delays introduced by buffers(bloat).   In this case, you can
> see on the graph, a max RTT around 150 ms and an average of 20 ms.  
> 
> While another, more well behaved path in the network to the speed
> server, I would only see a max RTT around 25 ms and an average of 15 ms,
> see:
> http://people.netfilter.org/hawk/dropbox/bloat_vs_GSO/speed-to-pc314a-1.png
> 
> You can also see this path had an ave of 90Mbit/s, but with significant
> throughput drops (the 92Mbit/s line is an artificial line on the graph).
> This behavior is probaly caused by the GSO effect.
> 
> Disabling GSO on speed server fixed the problem as can be seen on graph:
> http://people.netfilter.org/hawk/dropbox/bloat_vs_GSO/speed-to-grantoften-solved.png
> 
> The really strange part when troubleshooting this issue was that the
> throughput as fine between the two customer end-boxes ("grantoften" and
> "pc314a") as can be see here:
> http://people.netfilter.org/hawk/dropbox/bloat_vs_GSO/pc314a-to-grantoften-1.png
> 
> 

Its a bit hard to interpret these graphs, I am a bit lost...
What exactly is sampled ? Is it from tcpdump analysis or output from
HTB/SFQ stats ?

For sure, one TSO drop really drops a full range of [XX] tcp segments,
while with TSO off, a drop is one segment drop.

This certainly can explain bad artifacts, as receiver interprets this as
a huge congestion indication.

TSO/GRO are good only in the datacenter domain, where we want 10Gb flows
between two nodes with low CPU impact.