From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6F60B387376 for ; Mon, 19 Jan 2026 15:09:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768835395; cv=none; b=b/sMoD9hSQP7DXR1jDbdjCLwN9YtZ7hLRLnE1ExxEBlkxEW9PL772tdVSQlkcHphM0P5AsUj7mkN1AR20arD4oGpkXtecwyUeY3/vbDLnVceSpwCTK4bQ3mwDVCeSWwi3uFs06MJM67LrGgjbNthSo4PBIYHkeXCNAEmFzsHFDc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768835395; c=relaxed/simple; bh=i21ZAavZEiaMF0I2WSKTxVx1JM2vf3qFC1DujkWpRxM=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=ut4RSky+eWOa6NvrGtOnYrrkZIw4yBY9RQju3myLdrggLWN3S1gB2Bd800fpSbttdv018kgp3kRr7xP+9gy8Mih/yr/6C+BOonXZaH0yoqy1MQxYcvC5yee9Q9hlQhT+n/dG/X1/9EjaZ5RdLUc1X1J4bW4+rrp589otLop859I= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=SZU9mmU8; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="SZU9mmU8" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1768835393; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=HvvwsZg9OJT+YgieidGw02/J1Hpk54QokqRuZ34MdTY=; b=SZU9mmU8aHj8kQ3vYg1gnhiwBG77Sds8jwiZFiAVfrHXrHw25qnDW1fCDWxyA2bjnmNyPg Vwss9EkjmVOzL2IfftkeivIlkO+hAWsVGalje4ABIivqbsKIzH0mweTUJHnyIkOxdz7iIJ HxWPhzc48IFi451vtaFUlObo5UD92M4= Received: from mx-prod-mc-08.mail-002.prod.us-west-2.aws.redhat.com (ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-142-6JkBUByFONCnzr3518CImQ-1; Mon, 19 Jan 2026 10:09:50 -0500 X-MC-Unique: 6JkBUByFONCnzr3518CImQ-1 X-Mimecast-MFC-AGG-ID: 6JkBUByFONCnzr3518CImQ_1768835389 Received: from mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.12]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id A8B14180045C; Mon, 19 Jan 2026 15:09:48 +0000 (UTC) Received: from gerbillo.redhat.com (unknown [10.44.32.246]) by mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 964A219560A2; Mon, 19 Jan 2026 15:09:43 +0000 (UTC) From: Paolo Abeni To: netdev@vger.kernel.org Cc: "David S. Miller" , Eric Dumazet , Jakub Kicinski , Simon Horman , Donald Hunter , Andrew Lunn , Shuah Khan , Willem de Bruijn , sdf@fomichev.me, petrm@nvidia.com, razor@blackwall.org, idosch@nvidia.com Subject: [PATCH v4 net-next 00/10] geneve: introduce double tunnel GSO/GRO support Date: Mon, 19 Jan 2026 16:09:22 +0100 Message-ID: Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 3.0 on 10.30.177.12 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 Documentation/netlink/specs/rt-link.yaml | 3 + drivers/net/geneve.c | 557 ++++++++++++++++-- drivers/net/vxlan/vxlan_core.c | 16 +- include/linux/netdevice.h | 5 +- include/net/udp_tunnel.h | 32 + include/uapi/linux/if_link.h | 1 + net/core/dev.c | 8 +- tools/testing/selftests/net/Makefile | 1 + tools/testing/selftests/net/config | 1 + .../testing/selftests/net/double_udp_encap.sh | 393 ++++++++++++ 10 files changed, 978 insertions(+), 39 deletions(-) create mode 100755 tools/testing/selftests/net/double_udp_encap.sh -- 2.52.0