netdev - Re: [PATCH net-next 00/17] BIG TCP for UDP tunnels

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: <811b3df7-b008-4331-842a-eeff54b96874@redhat.com>
Date: Thu, 25 Sep 2025 16:26:21 +0200
From: Paolo Abeni <pabeni@...hat.com>
To: Maxim Mikityanskiy <maxtram95@...il.com>,
 Daniel Borkmann <daniel@...earbox.net>, "David S. Miller"
 <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>,
 Jakub Kicinski <kuba@...nel.org>,
 Willem de Bruijn <willemdebruijn.kernel@...il.com>,
 David Ahern <dsahern@...nel.org>, Nikolay Aleksandrov <razor@...ckwall.org>
Cc: netdev@...r.kernel.org, tcpdump-workers@...ts.tcpdump.org,
 Guy Harris <gharris@...ic.net>, Michael Richardson <mcr@...delman.ca>,
 Denis Ovsienko <denis@...ienko.info>, Xin Long <lucien.xin@...il.com>,
 Maxim Mikityanskiy <maxim@...valent.com>
Subject: Re: [PATCH net-next 00/17] BIG TCP for UDP tunnels

On 9/23/25 3:47 PM, Maxim Mikityanskiy wrote:
> From: Maxim Mikityanskiy <maxim@...valent.com>
> 
> This series consists adds support for BIG TCP IPv4/IPv6 workloads for vxlan
> and geneve. It consists of two parts:
> 
> 01-11: Remove hop-by-hop header for BIG TCP IPv6 to align with BIG TCP IPv4
> 12-17: Fix up things that prevent BIG TCP from working with tunnels.

What about splitting the series in 2, so that both chunks are below the
formal 15 patches limit and you can more easily add test-cases?

> There are a few places that make assumptions about skb->len being
> smaller than 64k and/or that store it in 16-bit fields, trimming the
> length. The first step to enable BIG TCP with VXLAN and GENEVE tunnels
> is to patch those places to handle bigger lengths properly (patches
> 12-17). This is enough to make IPv4 in IPv4 work with BIG TCP, but when
> either the outer or the inner protocol is IPv6, the current BIG TCP code
> inserts a hop-by-hop extension header that stores the actual 32-bit
> length of the packet. This additional hop-by-hop header turns out to be
> problematic for encapsulated cases, because:
> 
> 1. The drivers don't strip it, and they'd all need to know the structure
> of each tunnel protocol in order to strip it correctly.
> 
> 2. Even if (1) is implemented, it would be an additional performance
> penalty per aggregated packet.
> 
> 3. The skb_gso_validate_network_len check is skipped in
> ip6_finish_output_gso when IP6SKB_FAKEJUMBO is set, but it seems that it
> would make sense to do the actual validation, just taking into account
> the length of the HBH header. When the support for tunnels is added, it
> becomes trickier, because there may be one or two HBH headers, depending
> on whether it's IPv6 in IPv6 or not.
> 
> At the same time, having an HBH header to store the 32-bit length is not
> strictly necessary, as BIG TCP IPv4 doesn't do anything like this and
> just restores the length from skb->len. The same thing can be done for
> BIG TCP IPv6 (patches 01-11). Removing HBH from BIG TCP would allow to
> simplify the implementation significantly, and align it with BIG TCP IPv4.
> 
> A trivial tcpdump PR for IPv6 is pending here [0]. While the tcpdump
> commiters seem actively contributing code to the repository, it
> appears community PRs are stuck for a long time (?). We checked
> with Xin Long with regards to BIG TCP IPv4, and it turned out only
> GUESS_TSO was added to the Fedora distro spec file CFLAGS definition
> back then. In any case we have Cc'ed Guy Harris et al (tcpdump maintainer/
> committer) here just in case to see if he could help out with unblocking [0].

@tcpdump crew: any feedback on the mentioned PR would be very
appreciated, thanks!

Paolo