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

[Paolo Abeni <pabeni@redhat.com>]

On 1/19/26 4:09 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]
> ---
> v3 -> v4:
>   - better mangleid handling in patch 1
>   - use xfail_on_slow in patch 10
> v3: https://lore.kernel.org/netdev/cover.1768410519.git.pabeni@redhat.com/
> 
> v2 -> v3:
>   - addressed AI-reported possible UaF
> v2: https://lore.kernel.org/netdev/cover.1768250796.git.pabeni@redhat.com/
> 
> v1 -> v2:
>   - addressed AI and checker feedback
>   - more stable self-tests
>   - avoid GRO cells for double encap GSO pkts
> v1: https://lore.kernel.org/netdev/cover.1764056123.git.pabeni@redhat.com/#t
> 
> Paolo Abeni (10):
>   net: introduce mangleid_features
>   geneve: expose gso partial features for tunnel offload
>   vxlan: expose gso partial features for tunnel  offload
>   geneve: add netlink support for GRO hint
>   geneve: constify geneve_hlen()
>   geneve: pass the geneve device ptr to geneve_build_skb()
>   geneve: add GRO hint output path
>   geneve: extract hint option at GRO stage
>   geneve: use GRO hint option in the RX path
>   selftests: net: tests for add double tunneling GRO/GSO

It looks like the last 3 patches did not land on the ML. I have no idea
about the root cause. I'll wait a bit more and I'll resend the whole series.

/P