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

[Jesper Dangaard Brouer <jdb@comx.dk>]

On Thu, 2011-02-24 at 20:29 +0100, Eric Dumazet wrote:
> - Its important to set TSO off (ethtool -K eth0 tso off), or else we
> send big packets (up to 64Kbytes) and this used to break SFQ fairness.
> This can really hurt latencies of interactive flows.

Don't you mean "GSO" Generic-Segmentation-Offload (ethtool -K eth0 gso
off) as this happens in the stack.  While TSO Tcp-Segmentation-Offload
happens in hardware, and you will not see it in the SFQ qdisc?

I recommend that both is turned off, on small bandwidth links where
latency matters.

I'm wondering if LRO (Large-Receive-Offload) affect you, when you are
using SFQ on ingress?


Recently had some "funny" issues with GRO, where a 100 Mbit/s customer
could "only" get approx 90 Mbit/s throughput to our speed test server
(other customers, in another appartment building could get approx 96
Mbit/s). The issue was resolved by disabling GSO on the speed test
server.  The theory is that some switch on the path cannot handle the
bursts generated by GSO, which is max 64K (I think, correct me if I'm
wrong).

When adjusting buffer sizes, its important to take this bursty TCP
behavior into account, which is created by both GSO and TSO.  I'm not
saying that the queue size needs to be above 64K.  For smaller links, it
might make sense to set it, significantly below 64K, to avoid a GSO
enabled Linux machine to ramp up its window size, which makes it capable
of bursting.

-- 
Best regards
  Jesper Brouer
  ComX Networks A/S
  Linux Network Kernel Developer
  Cand. Scient Datalog / MSc.CS
  Author of http://adsl-optimizer.dk
  LinkedIn: http://www.linkedin.com/in/brouer