netdev - Re: [PATCH v2 net-next 00/10] geneve: introduce double tunnel GSO/GRO support

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: <12266a40-cbf9-4a55-bf9f-625e38be90c1@redhat.com>
Date: Tue, 13 Jan 2026 19:05:37 +0100
From: Paolo Abeni <pabeni@...hat.com>
To: netdev@...r.kernel.org
Cc: "David S. Miller" <davem@...emloft.net>,
 Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>,
 Simon Horman <horms@...nel.org>, Donald Hunter <donald.hunter@...il.com>,
 Andrew Lunn <andrew+netdev@...n.ch>, Shuah Khan <shuah@...nel.org>,
 Willem de Bruijn <willemdebruijn.kernel@...il.com>
Subject: Re: [PATCH v2 net-next 00/10] geneve: introduce double tunnel GSO/GRO
 support

On 1/12/26 9:50 PM, Paolo Abeni wrote:
> This is the [belated] incarnation of topic discussed in the last Neconf
> [1].
> 
> In container orchestration in virtual environments there is a consistent
> usage of double UDP tunneling - specifically geneve. Such setup lack
> support of GRO and GSO for inter VM traffic.
> 
> After commit b430f6c38da6 ("Merge branch 'virtio_udp_tunnel_08_07_2025'
> of https://github.com/pabeni/linux-devel") and the qemu cunter-part, VMs
> are able to send/receive GSO over UDP aggregated packets.
> 
> This series introduces the missing bit for full end-to-end aggregation
> in the above mentioned scenario. Specifically:
> 
> - introduces a new netdev feature set to generalize existing per device
> driver GSO admission check.1
> - adds GSO partial support for the geneve and vxlan drivers
> - introduces and use a geneve option to assist double tunnel GRO
> - adds some simple functional tests for the above.
> 
> The new device features set is not strictly needed for the following
> work, but avoids the introduction of trivial `ndo_features_check` to
> support GSO partial and thus possible performance regression due to the
> additional indirect call. Such feature set could be leveraged by a
> number of existing drivers (intel, meta and possibly wangxun) to avoid
> duplicate code/tests. Such part has been omitted here to keep the series
> small.
> 
> Both GSO partial support and double GRO support have some downsides.
> With the first in place, GSO partial packets will traverse the network
> stack 'downstream' the outer geneve UDP tunnel and will be visible by
> the udp/IP/IPv6 and by netfilter. Currently only H/W NICs implement GSO
> partial support and such packets are visible only via software taps.
> 
> Double UDP tunnel GRO will cook 'GSO partial' like aggregate packets,
> i.e. the inner UDP encapsulation headers set will still carry the
> wire-level lengths and csum, so that segmentation considering such
> headers parts of a giant, constant encapsulation header will yield the
> correct result.
> 
> The correct GSO packet layout is applied when the packet traverse the
> outermost geneve encapsulation.
> 
> Both GSO partial and double UDP encap are disabled by default and must
> be explicitly enabled via, respectively ethtool and geneve device
> configuration.
> 
> Finally note that the GSO partial feature could potentially be applied
> to all the other UDP tunnels, but this series limits its usage to geneve
> and vxlan devices.
> 
> Link: https://netdev.bots.linux.dev/netconf/2024/paolo.pdf [1]

The AI reported concerns look valid, and I'll take care of them in the
next revision.

/P