netdev - Re: Generic TSO

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] [day] [month] [year] [list]

Message-ID: <CAKgT0UfMp6c89dyAavWO5J0E+2ZvF7EMbq4znJmWY+y5YyY+6w@mail.gmail.com>
Date:	Mon, 14 Mar 2016 08:59:19 -0700
From:	Alexander Duyck <alexander.duyck@...il.com>
To:	Edward Cree <ecree@...arflare.com>
Cc:	Tom Herbert <tom@...bertland.com>,
	Linux Kernel Network Developers <netdev@...r.kernel.org>
Subject: Re: Generic TSO

On Mon, Mar 14, 2016 at 3:32 AM, Edward Cree <ecree@...arflare.com> wrote:
> On 14/03/16 10:26, Edward Cree wrote:
>> On 12/03/16 05:40, Alexander Duyck wrote:
>>> Well that is the thing.  Before we can actually start tinkering with
>>> the outer header we probably need to make sure we set the DF bit and
>>> that it would be honored on the outer headers for IPv4.  I don't
>>> believe any of the tunnels are currently doing that so repeating the
>>> IP ID would be the worst possible scenario until that is resolved
>>> since VXLAN tunneled frames can be fragmented while TCP frames cannot
>>> so we really shouldn't be repeating IP IDs for the outer headers.
>> So how do we progress with that?  I'm presuming it's not as simple as
>> just patching the tunnel drivers to set DF if the inner packet has it,
>> as that could break existing setups.  (I've heard that "but they're
>> already broken anyway" is not usually an acceptable argument.)  Some
>> sort of configuration option on the tunnel (like we do with udpcsum)?
> ...and immediately I find out it already exists.  (I guess I should have
> looked there first!)
> From drivers/net/vxlan.c:2001:
>> else if (info->key.tun_flags & TUNNEL_DONT_FRAGMENT)
>>             df = htons(IP_DF);

I'm still not a fan of trying to freeze the outer IP header.  I think
it should be the one that should have the IP ID increment while the
inner IP header be the one that is frozen.  Maybe that is where we can
differ per device.  I would be okay with the outer tunnel headers and
inner IP header being frozen on ixgbe which will be needed in order to
compute outer UDP checksum anyway.  Then we could leave it up to the
driver's discretion as to if the outer header has the IP ID that
increments or the inner header.

- Alex