Large receive offload
Posted Aug 4, 2007 7:59 UTC (Sat) by bgoglin
Parent article: Large receive offload
> The initial LRO implementation used hardware features found in Neterion
> adapters; it never made it into the mainline and little has been heard from
> that direction since.
Actually, lots happened in the last year or so. First, the neterion driver (s2io) had its own LRO implementation merged in mainline for a while, since 2.6.17. Then some patches were posted to add LRO in the Myri-10G driver (myri10ge) for 2.6.19, but they got rejected because the kernel maintainers didn't want 2 driver-specific implementations, they wanted a generic LRO (what Jan-Bernd did in the end). For the same reason, the Chelsio driver (cxgb3) LRO got the same reject later.
However, this long discussion got unfair suddenly because the new NetXen driver (netxen-nic) got merged in 2.6.20 with its own LRO by mistake, which made the myri10ge and cxgb3 maintainers kind of jalous :)
Now that Jan-Bernd posted this generic LRO patch, drivers are being ported to use it. "skb-mode" drivers can take a look at the patch that Jan-Bernd posted to port the eHEA driver. "page-based" drivers can look at the myri10ge driver patch that has been posted by Andrew Gallatin. He also provided lots of useful input during Jan Bernd's rework of his initial LRO patch (which was basically only designed for eHEA, i.e. skb-mode, only certain HW-checksum features, ...).
Everybody should be happy now, at least as long as the generic LRO performance is as good as the driver-specific LRO perf. So far, only the myri10ge driver can run both the generic LRO from Jan-Bernd or its own specific LRO (not included in mainline). Andrew confirmed the performance was similar, fortunately.
to post comments)