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.
[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).
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.
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).