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]

Date:	Mon, 14 Mar 2016 10:26:57 +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 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)?

Fortunately, with the design I'm currently planning on, a tunnel
driver could just set a flag in the SKB to say "unsafe for generic-
TSO", and we'd just send out the first segment normally and fall
back to regular software segmentation.

-Ed