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

Message-ID: <56E6933E.3050407@solarflare.com>
Date:	Mon, 14 Mar 2016 10:32:30 +0000
From:	Edward Cree <ecree@...arflare.com>
To:	Alexander Duyck <alexander.duyck@...il.com>,
	Tom Herbert <tom@...bertland.com>
CC:	Linux Kernel Network Developers <netdev@...r.kernel.org>
Subject: Re: Generic TSO

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);

-Ed