netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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.

  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).