Re: [PATCH net-next v2 00/11] BIG TCP without HBH in IPv6

[Paolo Abeni <pabeni@redhat.com>]

On 1/13/26 10:26 PM, Alice Mikityanska wrote:
> From: Alice Mikityanska <alice@isovalent.com>
> 
> This series is part 1 of v2 of "BIG TCP for UDP tunnels". Due to the
> number of patches, I'm splitting it into two logical parts:
> 
> * Remove hop-by-hop header for BIG TCP IPv6 to align with BIG TCP IPv4.
> * Fix up things that prevent BIG TCP from working with UDP tunnels.
> 
> The current BIG TCP IPv6 code inserts a hop-by-hop extension header with
> 32-bit length of the packet. When the packet is encapsulated, and either
> the outer or the inner protocol is IPv6, or both are IPv6, there will be
> 1 or 2 HBH headers that need to be dealt with. The issues that arise:
> 
> 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, also taking into
> account all combinations of IPv4/IPv6 inner/outer protocols.
> 
> 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. Removing HBH from BIG TCP would allow to simplify the
> implementation significantly, and align it with BIG TCP IPv4, which has
> been a long-standing goal.
> 
> v1: https://lore.kernel.org/netdev/20250923134742.1399800-1-maxtram95@gmail.com/
> 
> v2 changes:
> 
> Split the series into two parts. Address the review comments in part 2
> (details follow with part 2).
> 
> P.S. Author had her name changed since v1; it's the same person.

I went through the series as careful as I could and it looks good to me
- actually it cleans up the GRO/GSO nicely.

Acked-by: Paolo Abeni <pabeni@redhat.com>

Still I think we need the tcpdump part being available before merging
the code; AFAICS the related PR has moved forward a bit since v1 here:

https://github.com/the-tcpdump-group/tcpdump/pull/1329
https://github.com/the-tcpdump-group/tcpdump/pull/1396

But it's not ready yet.

/P