Re: [PATCH net-next v9 0/9] BIG TCP for UDP tunnels

["Alice Mikityanska" <alice.kernel@fastmail.im>]

On Wed, Jul 15, 2026, at 09:11, zebang.li wrote:
> On 10/07/2026 16:42, Alice Mikityanska wrote:
>> From: Alice Mikityanska <alice@isovalent.com>
>> 
>> This series is a follow-up to "BIG TCP without HBH in IPv6", and it adds
>> support for BIG TCP IPv4/IPv6 workloads in vxlan and geneve. Now that
>> IPv6 BIG TCP doesn't require stripping the HBH in all various
>> combinations in tunneled traffic, adding BIG TCP becomes feasible.
>> 
>> Patch 01 adds accessors for the length field in the UDP header, as
>> suggested by Paolo in review. The usage of udp_set_len is then added in
>> the following patches that start using length=0 in BIG TCP UDP packets.
>> 
>> Patches 02-04 close the gaps that prevent BIG TCP packets from going
>> through UDP tunnel code.
>> 
>> Patch 05 validates packets in udp_gro_receive to exclude packets with
>> length=0 from GRO aggregation.
>> 
>> Patch 06 is for proper formatting in tcpdump (set UDP len to 0 rather
>> than a trimmed value on overflow).
>> 
>> Patches 07-08 bump up tso_max_size for VXLAN and GENEVE.
>> 
>> Patch 09 adds selftests.
>> 
>> Thanks all!
>> 
>> v9 changes: Converted the selftest to iptables counters to avoid the
>> issue with tcpdump pcaps taking all space in /tmp.
>> 
>> v8: https://lore.kernel.org/netdev/20260706181941.385672-1-alice.kernel@fastmail.im/
>> 
>> v8 changes: Addressed Paolo's and Jason's review comments. Made the
>> selftest more robust, added checks for SACK and mode with disabled tx
>> checksum offload on lower veth netdevs. Added details to commit
>> messages. Kept skb_segment logic unchanged, because the frags overflow
>> issue is not specific to BIG TCP.
>> 
>> v7: https://lore.kernel.org/netdev/20260611192955.604661-1-alice.kernel@fastmail.im/
>> 
>> v7 changes: Addressed Paolo's comments to properly block malformed
>> packets with UDP length=0 at udp_rcv level.
>> 
>> v6: https://lore.kernel.org/netdev/20260602093931.516281-1-alice.kernel@fastmail.im/
>> 
>> v6 changes: Lowered the packets threshold in the selftest to pass
>> upstream CI on debug kernels, also made it configurable.
>> 
>> v5: https://lore.kernel.org/netdev/20260526161200.1135899-1-alice.kernel@fastmail.im/
>> 
>> v5 changes: Rebased, dropped one of the patches that came in via the net
>> tree, addressed an overflow in nsim_do_psp found by Sashiko.
>> 
>> v4: https://lore.kernel.org/netdev/20260512165648.386518-1-alice.kernel@fastmail.im/
>> 
>> v4 changes: Rebased, addressed Sashiko AI review [1] and Willem's
>> comment about netperf flags.
>> 
>> My comments on Sashiko AI review per patch:
>> 
>> 01: I'd prefer to keep the cases that I haven't tested outside of the
>> scope of this series, which is for VXLAN/GENEVE tunnels, not for ESP.
>> 
>> 02: The patch doesn't have behavioral changes other than fixing the
>> checksum. The final uh->len assignment assigns the actual length, not
>> 64k.
>> 
>> 03: The check can't be loosened, because total_len is also assigned to
>> UDP length. BIG TCP works in the mode without GRO hint option.
>> 
>> 04: Fixed the fallback value for udplen. BIG TCP is fine, it's the
>> uh->len = 0 case, uh->len can't exceed 64k.
>> 
>> 05: In the BIG TCP case, partial GSO splits the SKB in two. If full
>> segmentation is needed, the SKB is split in many MSS-sized SKBs without
>> fragments.
>> 
>> 06: Invalid packets from the wire are addressed in 08.
>> 
>> 07: __udp_gso_segment only handles UDP GSO packets, which can't be
>> bigger than 64k. Kept udp_set_len_short in nf_nat_mangle_udp_packet, as
>> the function doesn't support BIG TCP packets anyway (see
>> mangle_contents).
>> 
>> 08: udp_gro_receive handles packets before aggregation, there are no BIG
>> TCP packets at this point. RFC 768 doesn't say that padded UDP packets
>> are valid. Real jumbograms don't seem to be supported in this path
>> anyway.
>> 
>> 09: The packet goes to skb_udp_tunnel_segment, not __udp_gso_segment.
>> __skb_udp_tunnel_segment handles this case.
>> 
>> 12: Improved process cleanup by killing everything inside netns before
>> deleting them, and by avoiding killing netserver outside of netns.
>> netperf with -r in TCP_STREAM mode works, and the option has the
>> intended effect, but I replaced it with -m. Added dependency check for
>> tcpdump.
>> 
>> [1]: https://sashiko.dev/#/patchset/20260410150943.993350-1-alice.kernel%40fastmail.im
>> 
>> v3: https://lore.kernel.org/netdev/20260410150943.993350-1-alice.kernel@fastmail.im/
>> 
>> v3 changes: Fixed the redirect in the selftest, rebased over my L2TP fix
>> [2] for the syzbot report [3].
>> 
>> [2]: https://lore.kernel.org/netdev/20260403174949.843941-1-alice.kernel@fastmail.im/
>> [3]: https://lore.kernel.org/netdev/69a1dfba.050a0220.3a55be.0026.GAE@google.com/
>> 
>> v2: https://lore.kernel.org/netdev/20260226201600.222044-1-alice.kernel@fastmail.im/
>> 
>> v2 changes: Addressed the review comments: added UDP len helpers,
>> consolidated UDP len sanity checks in patch 08 into one, added
>> selftests. Added fixups to related code (patch 01-03).
>> 
>> v1: https://lore.kernel.org/netdev/20250923134742.1399800-1-maxtram95@gmail.com/
>> 
>> Alice Mikityanska (8):
>>    net: Use helpers to get/set UDP len tree-wide
>>    net: Enable BIG TCP with partial GSO
>>    udp: Support BIG TCP GSO packets where they can occur
>>    udp: Support gro_ipv4_max_size > 65536
>>    udp: Validate UDP length in udp_gro_receive
>>    udp: Set length in UDP header to 0 for big GSO packets
>>    vxlan: Enable BIG TCP packets
>>    selftests: net: Add a test for BIG TCP in UDP tunnels
>> 
>> Daniel Borkmann (1):
>>    geneve: Enable BIG TCP packets
>> 
>>   drivers/infiniband/core/lag.c                 |   2 +-
>>   drivers/infiniband/sw/rxe/rxe_net.c           |   4 +-
>>   drivers/net/amt.c                             |   6 +-
>>   drivers/net/ethernet/intel/i40e/i40e_txrx.c   |   2 +-
>>   drivers/net/ethernet/intel/iavf/iavf_txrx.c   |   2 +-
>>   drivers/net/ethernet/intel/ice/ice_txrx.c     |   2 +-
>>   drivers/net/ethernet/intel/idpf/idpf_txrx.c   |   2 +-
>>   .../marvell/octeontx2/nic/otx2_txrx.c         |   2 +-
>>   .../net/ethernet/mellanox/mlx5/core/en_rx.c   |   4 +-
>>   .../ethernet/mellanox/mlx5/core/en_selftest.c |   2 +-
>>   drivers/net/ethernet/sfc/falcon/selftest.c    |   4 +-
>>   drivers/net/ethernet/sfc/selftest.c           |   4 +-
>>   drivers/net/ethernet/sfc/siena/selftest.c     |   4 +-
>>   drivers/net/ethernet/sfc/tc_encap_actions.c   |   2 +-
>>   .../stmicro/stmmac/stmmac_selftests.c         |   4 +-
>>   drivers/net/geneve.c                          |   4 +-
>>   drivers/net/netconsole.c                      |   2 +-
>>   drivers/net/netdevsim/dev.c                   |   2 +-
>>   drivers/net/netdevsim/psample.c               |   2 +-
>>   drivers/net/netdevsim/psp.c                   |   8 +-
>>   drivers/net/vxlan/vxlan_core.c                |   2 +
>>   drivers/net/wireguard/receive.c               |   2 +-
>>   include/linux/udp.h                           |  27 +++
>>   include/trace/events/icmp.h                   |   2 +-
>>   lib/tests/blackhole_dev_kunit.c               |   2 +-
>>   net/6lowpan/nhc_udp.c                         |  10 +-
>>   net/core/pktgen.c                             |   4 +-
>>   net/core/selftests.c                          |   4 +-
>>   net/core/skbuff.c                             |  10 +-
>>   net/core/tso.c                                |   3 +-
>>   net/ipv4/esp4.c                               |   2 +-
>>   net/ipv4/fou_core.c                           |   2 +-
>>   net/ipv4/ipconfig.c                           |   6 +-
>>   net/ipv4/netfilter/nf_nat_snmp_basic_main.c   |   4 +-
>>   net/ipv4/route.c                              |   2 +-
>>   net/ipv4/udp.c                                |   7 +-
>>   net/ipv4/udp_offload.c                        |  49 ++---
>>   net/ipv4/udp_tunnel_core.c                    |   2 +-
>>   net/ipv6/esp6.c                               |   5 +-
>>   net/ipv6/fou6.c                               |   2 +-
>>   net/ipv6/ip6_udp_tunnel.c                     |   2 +-
>>   net/ipv6/udp.c                                |   7 +-
>>   net/ipv6/udp_offload.c                        |   2 +-
>>   net/l2tp/l2tp_core.c                          |   2 +-
>>   net/netfilter/ipvs/ip_vs_xmit.c               |   2 +-
>>   net/netfilter/nf_conntrack_proto_udp.c        |  15 +-
>>   net/netfilter/nf_log_syslog.c                 |   2 +-
>>   net/netfilter/nf_nat_helper.c                 |   2 +-
>>   net/psp/psp_main.c                            |   2 +-
>>   net/sched/act_csum.c                          |   4 +-
>>   net/xfrm/xfrm_nat_keepalive.c                 |   2 +-
>>   tools/testing/selftests/net/Makefile          |   1 +
>>   .../testing/selftests/net/big_tcp_tunnels.sh  | 188 ++++++++++++++++++
>>   53 files changed, 340 insertions(+), 102 deletions(-)
>>   create mode 100755 tools/testing/selftests/net/big_tcp_tunnels.sh
>> 
>
>
> Hi Alice,
>
> This patch looks promising, but I noticed that it does not include a 
> modification for `skb_gro_receive`.
>
> Currently, for UDP data aggregated via GRO, if the resulting packet 
> size exceeds 65536 (`GRO_LEGACY_MAX_SIZE`), this check will return 
> `-E2BIG`.
>
> To allow UDP GRO aggregation beyond this limit (similar to the existing 
> TCP behavior), we should update the condition to include `IPPROTO_UDP`.

Thanks for the feedback! That's a good idea for future development,
however, I'd like to keep the scope of this effort limited to BIG TCP.
The series is already big enough, and adding UDP GRO might be not as
trivial as it seems. At the very least, it requires adding another
selftest to cover the new paths. In the worst case, it might need more
tweaks in the datapath in case something breaks at later points in the
pipeline. Moreover, since UDP GRO is not transparent for the userspace
(unlike BIG TCP), the userspace might rely on assumptions about max
aggregation size, and this topic needs additional research.

To sum up, it's a good direction for further research, which can be done
independently after merging this series, but I'd rather keep the scope
of this series clear and limited to BIG TCP. Note that the current
version of skb_gro_receive doesn't block tunneled BIG TCP traffic, which
is proved by the selftest and manual testing.

Thanks,
Alice

> I suggest the following modification:
>
> diff --git a/net/core/gro.c b/net/core/gro.c
> index 35f2f708f010..01e56ad629c2 100644
> --- a/net/core/gro.c
> +++ b/net/core/gro.c
> @@ -117,7 +117,7 @@ int skb_gro_receive(struct sk_buff *p, struct 
> sk_buff *skb)
>                 return -E2BIG;
>         if (unlikely(p->len + len >= GRO_LEGACY_MAX_SIZE)) {
> -               if (NAPI_GRO_CB(skb)->proto != IPPROTO_TCP ||
> +               if ((NAPI_GRO_CB(skb)->proto != IPPROTO_TCP && 
> NAPI_GRO_CB(skb)->proto != IPPROTO_UDP) ||
>                     p->encapsulation)
>                         return -E2BIG;
>         }
>
> Thanks,
> zebang