netdev - Re: [PATCH net-next 0/4] net: cleanup for UDP tunnel's GRO

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: <b876be9e-3eca-5423-f99a-adc3d6a3ac99@stressinduktion.org>
Date:	Fri, 8 Jul 2016 17:40:33 -0400
From:	Hannes Frederic Sowa <hannes@...essinduktion.org>
To:	Shmulik Ladkani <shmulik.ladkani@...il.com>
Cc:	Alexander Duyck <alexander.duyck@...il.com>,
	Paolo Abeni <pabeni@...hat.com>,
	Netdev <netdev@...r.kernel.org>,
	"David S. Miller" <davem@...emloft.net>,
	Jesse Gross <jesse@...nel.org>,
	Tom Herbert <tom@...bertland.com>, Jiri Benc <jbenc@...hat.com>
Subject: Re: [PATCH net-next 0/4] net: cleanup for UDP tunnel's GRO

On 08.07.2016 17:19, Shmulik Ladkani wrote:
> On Fri, 8 Jul 2016 16:57:10 -0400 Hannes Frederic Sowa <hannes@...essinduktion.org> wrote:
>> On 08.07.2016 16:17, Shmulik Ladkani wrote:
>>> On Fri, 8 Jul 2016 09:21:40 -0700 Alexander Duyck <alexander.duyck@...il.com> wrote:  
>>>> I get that there is an impression that it is redundant but there are a
>>>> number of paths that could lead to VXLAN or GENEVE frames being
>>>> received that are not aggregated via GRO.  
>>>
>>> There's the case where the vxlan/geneve datagrams get IP fragmented, and
>>> IP frags are not GROed.
>>> GRO aggregation at the vxlan/geneve level is beneficial for this case.  
>>
>> Isn't this a misconfiguration? TCP should not fragment at all, not even
>> in vxlan/geneve if one cares about performance? And UDP is not GRO'ed
>> anyway.
> 
> It's not an ideal configuration, but it is a valid one.
> 
> Imagine TCP within vxlan/geneve, that gets properly segmented and
> encapsulated.
> 
> The vxlan/geneve datagrams go out the wire, and these can occasionally
> be fragmented on the way (e.g. when we can't control the MTUs along the
> path, or if unable to use PMTUD for whatever reason).

PMTUD doesn't work with vxlan in most situations anyway. But you can
still control the mtu/mss with ip route and you don't need to modify the
mid-hosts.

> At the receiving vxlan/geneve termination, these IP frags are not GROed.
> 
> Instead they get reassembled by the IP stack, then handed to UDP and to
> the vxlan/geneve drivers.
> 
> From that point, GROing at the vxlan/geneve device, which aggregates
> the TCP segments into a TCP super-packet still make sense and has
> benefits.

Given the spreading with which those fragments will be send, I wonder if
the GRO ontop of the tunnels will really aggregate them?

Bye,
Hannes