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