Monitoring and Tuning the Linux Networking Stack: Receiving Data

blog.packagecloud.io

144 points·lindvall··9 comments

A nice overview; thanks for sharing it!

I don't think that your claim that GRO is "a software implementation of a hardware optimization that is known as Large Receive Offloading (LRO)" is correct, though. GRO effectively replaces LRO [1]; it has fewer limitations (it works with non-TCP traffic and with bridging [2], for example). Drivers need to support it, but they are free to take advantage of hardware offloading/acceleration, and many do (including e.g. the ixgbe driver [3]).

----

[1] In terms of function, and in the sense that LRO could be removed if the drivers that were using LRO were updated to use GRO instead.

[2] Relevant bug: https://bugzilla.redhat.com/show_bug.cgi?id=772317

[3] Which actually supports both LRO and GRO; if I recall, in older versions, bad things(tm) would sometimes happen if you had both enabled at the same time (whereas now the LRO setting is ignored if GRO is enabled).

While most of this can be found in the MAN pages, this is a nice synopsis to have on hand. Definitely going to bookmark this.

> There is, unfortunately, no easy way out.

Disagree. BSD.

That's a tough pill to swallow for many

There's also kernel bypass setups which seem to be common when crazy performance is required.

It is a bit hard to follow the listings as they don't use a monospaced font. A part from that, very detailed and useful article.

Sorry about that! What browser/operating system? I suspect this is a missing font issue.

I think I see the same thing on Chrome/Linux. If I comment out the `font-family: monaco` rule in the `article.type-system-sans code` CSS rule, then a monospace font is used and makes things much more readable.

Just deployed a fix, thanks for the bug report!

Reply on news.ycombinator.com