On Thu, Nov 16, 2017 at 5:47 PM, Tom Herbert <[email protected]> wrote: > On Thu, Nov 16, 2017 at 1:40 PM, Herbert Xu <[email protected]> > wrote: >> On Thu, Nov 16, 2017 at 04:12:43PM +0100, Cristian Klein wrote: >>> >>> Does somebody know the rationale for this? Is it because IPv4 >>> options are rarely used, hence implementing GRO in that case does >>> not pay off or are there some caveats? Specifically would it make >> >> Precisely. GRO is about optimising for the common case. At the >> time there was no impetus to support IP options. >> >>> sense to do GRO when the IPv4 options are byte-identical in >>> consecutive packets? >> >> Yes there is no reason why we can't do this. As long as it doesn't >> penalise the non-IP-option case too much. >> > Of course it would also be nice to have GRO support for various IPv6 > extension headers, at this point we're more likely to see those rather > than IP options in real deployment!
ipv6_gro_receive already pulls common ones with ipv6_gso_pull_exthdrs. And to add a counterpoint: GRO has to be resilient to malformed packets, so there is value in keeping it simple and limited to the common case.
