netdev - Re: GRO disabled with IPv4 options

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 16 Nov 2017 14:47:10 -0800
From:   Tom Herbert <tom@...bertland.com>
To:     Herbert Xu <herbert@...dor.apana.org.au>
Cc:     Cristian Klein <cklein@...umu.se>,
        Linux Kernel Network Developers <netdev@...r.kernel.org>,
        Ahmed Ali-Eldin <ahmeda@...umu.se>
Subject: Re: GRO disabled with IPv4 options

On Thu, Nov 16, 2017 at 1:40 PM, Herbert Xu <herbert@...dor.apana.org.au> 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!

Tom

> Cheers,
> --
> Email: Herbert Xu <herbert@...dor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt