On 23/06/16 18:07, Alexander Duyck wrote: > I would prefer to see us extend LRO to support "close enough GRO" > instead of have us extend GRO to also include LRO. This reminds me of something I've been meaning to bring up (sorry for slightly OT, but it might turn out relevant after all). In sfc we have an (out-of-tree and likely staying that way) LRO that's entirely in software. The only reason it exists is for users who want the 'permissive' merging behaviour of LRO, i.e. they don't need the guarantees of reversibility and by merging more stuff they can get slightly higher performance. I wonder if it would be a good idea for the GRO implementation to have some knobs to allow setting it to behave in this way. That would imply a scheme to define various GRO/SSR semantics, which then would also be a convenient interface for a driver to report the semantics of its hardware LRO if it has any. And it would make crystal clear that the difference between GRO and LRO is kernel vs hardware, rather than reversible vs not.
-Ed
