[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <e4d81c37-ad4d-40fc-80ff-dc047f772b5c@redhat.com>
Date: Tue, 20 Jan 2026 10:17:55 +0100
From: Paolo Abeni <pabeni@...hat.com>
To: Alice Mikityanska <alice.kernel@...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 v2 00/11] BIG TCP without HBH in IPv6
On 1/13/26 10:26 PM, Alice Mikityanska wrote:
> From: Alice Mikityanska <alice@...valent.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@...hat.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
Powered by blists - more mailing lists