From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
To: Richard Gobert <richardbgobert@gmail.com>,
Willem de Bruijn <willemdebruijn.kernel@gmail.com>,
netdev@vger.kernel.org, pabeni@redhat.com,
ecree.xilinx@gmail.com
Cc: davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
horms@kernel.org, corbet@lwn.net, saeedm@nvidia.com,
tariqt@nvidia.com, mbloch@nvidia.com, leon@kernel.org,
dsahern@kernel.org, ncardwell@google.com, kuniyu@google.com,
shuah@kernel.org, sdf@fomichev.me,
aleksander.lobakin@intel.com, florian.fainelli@broadcom.com,
alexander.duyck@gmail.com, linux-kernel@vger.kernel.org,
linux-net-drivers@amd.com
Subject: Re: [PATCH net-next v5 3/5] net: gso: restore ids of outer ip headers correctly
Date: Tue, 16 Sep 2025 11:52:30 -0400 [thread overview]
Message-ID: <willemdebruijn.kernel.39980903d76e0@gmail.com> (raw)
In-Reply-To: <dca173e6-f23d-4f54-8ace-74329439c7da@gmail.com>
Richard Gobert wrote:
> Willem de Bruijn wrote:
> > Richard Gobert wrote:
> >> Currently, NETIF_F_TSO_MANGLEID indicates that the inner-most ID can
> >> be mangled. Outer IDs can always be mangled.
> >>
> >> Make GSO preserve outer IDs by default, with NETIF_F_TSO_MANGLEID allowing
> >> both inner and outer IDs to be mangled.
> >>
> >> This commit also modifies a few drivers that use SKB_GSO_FIXEDID directly.
> >>
> >> Signed-off-by: Richard Gobert <richardbgobert@gmail.com>
> >> Reviewed-by: Edward Cree <ecree.xilinx@gmail.com> # for sfc
> >> ---
> >> .../networking/segmentation-offloads.rst | 22 ++++++++++++-------
> >> .../net/ethernet/mellanox/mlx5/core/en_rx.c | 8 +++++--
> >> drivers/net/ethernet/sfc/ef100_tx.c | 17 ++++++++++----
> >> include/linux/netdevice.h | 9 ++++++--
> >> include/linux/skbuff.h | 9 +++++++-
> >> net/core/dev.c | 5 ++++-
> >> net/ipv4/af_inet.c | 13 +++++------
> >> net/ipv4/tcp_offload.c | 5 +----
> >> 8 files changed, 59 insertions(+), 29 deletions(-)
> >>
> >> diff --git a/Documentation/networking/segmentation-offloads.rst b/Documentation/networking/segmentation-offloads.rst
> >> index 085e8fab03fd..72f69b22b28c 100644
> >> --- a/Documentation/networking/segmentation-offloads.rst
> >> +++ b/Documentation/networking/segmentation-offloads.rst
> >> @@ -43,10 +43,19 @@ also point to the TCP header of the packet.
> >> For IPv4 segmentation we support one of two types in terms of the IP ID.
> >> The default behavior is to increment the IP ID with every segment. If the
> >> GSO type SKB_GSO_TCP_FIXEDID is specified then we will not increment the IP
> >> -ID and all segments will use the same IP ID. If a device has
> >> -NETIF_F_TSO_MANGLEID set then the IP ID can be ignored when performing TSO
> >> -and we will either increment the IP ID for all frames, or leave it at a
> >> -static value based on driver preference.
> >> +ID and all segments will use the same IP ID.
> >> +
> >> +For encapsulated packets, SKB_GSO_TCP_FIXEDID refers only to the outer header.
> >> +SKB_GSO_TCP_FIXEDID_INNER can be used to specify the same for the inner header.
> >> +Any combination of these two GSO types is allowed.
> >> +
> >> +If a device has NETIF_F_TSO_MANGLEID set then the IP ID can be ignored when
> >> +performing TSO and we will either increment the IP ID for all frames, or leave
> >> +it at a static value based on driver preference. For encapsulated packets,
> >> +NETIF_F_TSO_MANGLEID is relevant for both outer and inner headers, unless the
> >> +DF bit is not set on the outer header, in which case the device driver must
> >> +guarantee that the IP ID field is incremented in the outer header with every
> >> +segment.
> >
> > Is this introducing a new device requirement for advertising
> > NETIF_F_TSO_MANGLEID that existing devices may not meet?
> >
>
> No. As I discussed previously with Paolo, existing devices already increment outer
> IDs. It is even a requirement for GSO partial, as already stated in the documentation.
Where is this documented?
> This preserves the current behavior. It just makes it explicit. Actually, we are
> now even explicitly allowing the mangling of outer IDs if the DF-bit is set.
>
> >> #if BITS_PER_LONG > 32
> >> diff --git a/net/core/dev.c b/net/core/dev.c
> >> index 93a25d87b86b..17cb399cdc2a 100644
> >> --- a/net/core/dev.c
> >> +++ b/net/core/dev.c
> >> @@ -3769,7 +3769,10 @@ static netdev_features_t gso_features_check(const struct sk_buff *skb,
> >> features &= ~dev->gso_partial_features;
> >>
> >> /* Make sure to clear the IPv4 ID mangling feature if the
> >> - * IPv4 header has the potential to be fragmented.
> >> + * IPv4 header has the potential to be fragmented. For
> >> + * encapsulated packets, the outer headers are guaranteed to
> >> + * have incrementing IDs if DF is not set so there is no need
> >> + * to clear the IPv4 ID mangling feature.
> >
> > Why is this true. Or, why is it not also true for non-encapsulated or
> > inner headers?
> >
> > The same preconditions (incl on DF) are now tested in inet_gro_flush
> >
>
> This comment is about the IDs that TSO generates, not the IDs that GRO accepts.
> I'll rewrite the comment to make it clearer.
Yes, this exact statement would convert the assertion into an
explanation. Really helps a casual reader.
>
> This statement is true because of the requirement specified above, that device
> drivers must increment the outer IDs if the DF-bit is not set. This means that
> MANGLEID cannot turn incrementing IDs into fixed IDs in the outer header if the
> DF-bit is not set (unless the IDs were already fixed, after the next patch) so
> there is no need to clear NETIF_F_TSO_MANGLEID.
>
> This isn't true for non-encapsulated or inner headers because nothing guarantees
> that MANGLEID won't mangle incrementing IDs into fixed IDs.
>
> >> @@ -471,7 +471,6 @@ INDIRECT_CALLABLE_SCOPE int tcp4_gro_complete(struct sk_buff *skb, int thoff)
> >> const u16 offset = NAPI_GRO_CB(skb)->network_offsets[skb->encapsulation];
> >> const struct iphdr *iph = (struct iphdr *)(skb->data + offset);
> >> struct tcphdr *th = tcp_hdr(skb);
> >> - bool is_fixedid;
> >>
> >> if (unlikely(NAPI_GRO_CB(skb)->is_flist)) {
> >> skb_shinfo(skb)->gso_type |= SKB_GSO_FRAGLIST | SKB_GSO_TCPV4;
> >> @@ -485,10 +484,8 @@ INDIRECT_CALLABLE_SCOPE int tcp4_gro_complete(struct sk_buff *skb, int thoff)
> >> th->check = ~tcp_v4_check(skb->len - thoff, iph->saddr,
> >> iph->daddr, 0);
> >>
> >> - is_fixedid = (NAPI_GRO_CB(skb)->ip_fixedid >> skb->encapsulation) & 1;
> >> -
> >> skb_shinfo(skb)->gso_type |= SKB_GSO_TCPV4 |
> >> - (is_fixedid * SKB_GSO_TCP_FIXEDID);
> >> + (NAPI_GRO_CB(skb)->ip_fixedid * SKB_GSO_TCP_FIXEDID);
> >
> > ip_fixedid can now be 0, 1 (outer), 2 (inner) or 3 (inner and outer).
> >
> > Not all generate a valid SKB_GSO type.
>
> Since SKB_GSO_TCP_FIXEDID_INNER == SKB_GSO_TCP_FIXEDID << 1, all the values
> listed above generate the correct set of SKB_GSO types. This fact is also
> used in inet_gso_segment (SKB_GSO_TCP_FIXEDID << encap).
Oh right. Neat.
That dependency can use a BUILD_BUG_ON.
next prev parent reply other threads:[~2025-09-16 15:52 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-15 11:39 [PATCH net-next v5 0/5] net: gso: restore outer ip ids correctly Richard Gobert
2025-09-15 11:39 ` [PATCH net-next v5 1/5] net: gro: remove is_ipv6 from napi_gro_cb Richard Gobert
2025-09-16 0:01 ` Willem de Bruijn
2025-09-15 11:39 ` [PATCH net-next v5 2/5] net: gro: only merge packets with incrementing or fixed outer ids Richard Gobert
2025-09-16 0:05 ` Willem de Bruijn
2025-09-15 11:39 ` [PATCH net-next v5 3/5] net: gso: restore ids of outer ip headers correctly Richard Gobert
2025-09-16 0:26 ` Willem de Bruijn
2025-09-16 13:46 ` Richard Gobert
2025-09-16 15:52 ` Willem de Bruijn [this message]
2025-09-18 11:56 ` Richard Gobert
2025-09-15 11:39 ` [PATCH net-next v5 4/5] net: gro: remove unnecessary df checks Richard Gobert
2025-09-16 0:32 ` Willem de Bruijn
2025-09-16 13:53 ` Richard Gobert
2025-09-16 15:57 ` Willem de Bruijn
2025-09-18 11:59 ` Richard Gobert
2025-09-15 11:39 ` [PATCH net-next v5 5/5] selftests/net: test ipip packets in gro.sh Richard Gobert
2025-09-16 0:34 ` Willem de Bruijn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=willemdebruijn.kernel.39980903d76e0@gmail.com \
--to=willemdebruijn.kernel@gmail.com \
--cc=aleksander.lobakin@intel.com \
--cc=alexander.duyck@gmail.com \
--cc=corbet@lwn.net \
--cc=davem@davemloft.net \
--cc=dsahern@kernel.org \
--cc=ecree.xilinx@gmail.com \
--cc=edumazet@google.com \
--cc=florian.fainelli@broadcom.com \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=kuniyu@google.com \
--cc=leon@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-net-drivers@amd.com \
--cc=mbloch@nvidia.com \
--cc=ncardwell@google.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=richardbgobert@gmail.com \
--cc=saeedm@nvidia.com \
--cc=sdf@fomichev.me \
--cc=shuah@kernel.org \
--cc=tariqt@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).