The article says "Enabling a packet size of 185,000 bytes increased network throughput by nearly 50%" So they essentially tripled the max TSO/GRO size from ~64

The article says "Enabling a packet size of 185,000 bytes increased network throughput by nearly 50%" So they essentially tripled the max TSO/GRO size from ~64k to 185k and that resulted in more throughput, presumably due to less overhead. That's a LOT of per-packet overheads, and seems a bit surprising to me. In tests I've done, I have not seen much difference between a 16k max tso and a 64k max TSO. Then again, my benchmark is generally a TCP_STREAM (throughput), and not a TCP_RR (ping pong) test. In general, outside a datacenter, the last thing you want to do is dump 185KB for the same connection on the wire in a giant burst, as you'll blow out router buffers when transiting the internet from 100GbE in your datacenter to some crappy DSL router at your users' houses. So I wonder how much the benefit is reduced when using some kind of software based packet pacing? I think linux has some kind of packet scheduler designed to avoid large bursts, etc. Does it break apart these giant TSOs? Or does using it just cap the max TSO size? At least in FreeBSD. the TCP stack controls pacing and one thing it does is to send down smaller TSOs to NICs that don't support hardware pacing. The goal is to reduce the burst size on the wire, so TCP will send down a few KB, wait several milliseconds, dribbled down more, etc. This reduces our average TSO size, and increases overhead.