Message-ID: <4a029386-a03d-41d0-aaf6-0d5e7a6af389@redhat.com>
Date: Tue, 3 Feb 2026 10:51:26 +0100
From: Paolo Abeni <pabeni@...hat.com>
To: Alice Mikityanska <alice.projects@...tmail.im>,
 Daniel Borkmann <daniel@...earbox.net>, "David S. Miller"
 <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>,
 Jakub Kicinski <kuba@...nel.org>, Xin Long <lucien.xin@...il.com>,
 Willem de Bruijn <willemdebruijn.kernel@...il.com>,
 David Ahern <dsahern@...nel.org>, Nikolay Aleksandrov <razor@...ckwall.org>
Cc: Shuah Khan <shuah@...nel.org>, Stanislav Fomichev <stfomichev@...il.com>,
 netdev@...r.kernel.org, Alice Mikityanska <alice@...valent.com>
Subject: Re: [PATCH net-next v4 00/12] BIG TCP without HBH in IPv6

On 2/3/26 9:59 AM, Alice Mikityanska wrote:
> From: Alice Mikityanska <alice@...valent.com>
> 
> Resubmitting to add one more patch for bng_en. No other changes in code.
> 
> This series is part 1 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: https://lore.kernel.org/netdev/20260113212655.116122-1-alice.kernel@fastmail.im/
> 
> v2 changes:
> 
> Split the series into two parts. Address the review comments in part 2
> (details follow with part 2).
> 
> v3: https://lore.kernel.org/netdev/20260202192338.2373930-1-alice.projects@fastmail.im/
> 
> v3 changes:
> 
> No code changes. Added Paolo's ACK. Tcpdump patches have been merged and
> unblocked the series:
> 
> https://github.com/the-tcpdump-group/tcpdump/pull/1329
> 
> v4 changes:
> 
> Added one more patch for bng_en, because it started using
> ipv6_hopopt_jumbo_remove in the meanwhile. Added Eric's Reviewed-by.

It's a pity you resubmitted before the 24h grace period without any
request to do so. That usually causes a request to wait for 1w before
the next revision.

Moreover the current one does not apply cleanly to net-next.

Still I think it would be for the better to be able to include this
series in the upcoming the merge window, and I guess I'm not alone with
such hope.

So please wait at least 48h (be accurate about the time) before the next
revision.

Thanks,

Paolo

p.s. this is my (very lenient) take, other maintainers could ask for a
different/longer pause.

Powered by blists - more mailing lists