On Wed, Jun 22, 2016 at 4:31 PM, Eric Dumazet <eric.duma...@gmail.com> wrote: > On Wed, 2016-06-22 at 15:56 -0700, Alexander Duyck wrote: > >> It could be that you and Rick are running different firmware. I >> believe you can expose that via "ethtool -i". This is the ugly bit >> about all this. We are offloading GRO into the firmware of these >> devices with no idea how any of it works and by linking GRO to LRO on >> the same device you are stuck having to accept either the firmware >> offload or nothing at all. That is kind of the point Rick was trying >> to get at. > > > Well, we offload TSO to the NIC. Or checksums as much as we can. > > At one point we have to trust the NIC we plug in our hosts, right ? > > Why RX is so different than TX exactly ? > LRO requires parsing the packet and hence DPI for things like foo/UDP. TSO is much more straightforward and does not rely on parsing (e.g. LRO would require NIC to parse EH, TSO doesn't). Also, TSO is work-conserving, whereas LRO is not. I don't believe there is any standard for how NICs are supposed to determined when to set packets to host. All of this makes LRO much less deterministic and means there's a lot of variance between NIC implementations. Plus there's also the question of whether a vendor is testing IPv6. I do think all this can be "fixed" once we have programmable NICs and we can program our own implementation of LRO, but until then I think there is inherent risk in using it. GRO rocks though!
Tom > Yes, LRO is hard to implement properly compared to TSO, > but not something that is _fundamentally_ broken. > > Claiming that hardware assist GRO is not possible is a plain mantra. > >
