All of lore.kernel.org
 help / color / mirror / Atom feed
From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
To: Richard Gobert <richardbgobert@gmail.com>,  netdev@vger.kernel.org
Cc: davem@davemloft.net,  edumazet@google.com,  kuba@kernel.org,
	 pabeni@redhat.com,  horms@kernel.org,  corbet@lwn.net,
	 saeedm@nvidia.com,  tariqt@nvidia.com,  mbloch@nvidia.com,
	 leon@kernel.org,  ecree.xilinx@gmail.com,  dsahern@kernel.org,
	 ncardwell@google.com,  kuniyu@google.com,  shuah@kernel.org,
	 sdf@fomichev.me,  aleksander.lobakin@intel.com,
	 florian.fainelli@broadcom.com,  willemdebruijn.kernel@gmail.com,
	 alexander.duyck@gmail.com,  linux-kernel@vger.kernel.org,
	 linux-net-drivers@amd.com,
	 Richard Gobert <richardbgobert@gmail.com>
Subject: Re: [PATCH net-next v4 2/5] net: gro: only merge packets with incrementing or fixed outer ids
Date: Tue, 02 Sep 2025 14:08:34 -0400	[thread overview]
Message-ID: <willemdebruijn.kernel.277f254610c6e@gmail.com> (raw)
In-Reply-To: <20250901113826.6508-3-richardbgobert@gmail.com>

Richard Gobert wrote:
> Only merge encapsulated packets if their outer IDs are either
> incrementing or fixed, just like for inner IDs and IDs of non-encapsulated
> packets.
> 
> Add another ip_fixedid bit for a total of two bits: one for outer IDs (and
> for unencapsulated packets) and one for inner IDs.
> 
> This commit preserves the current behavior of GSO where only the IDs of the
> inner-most headers are restored correctly.
> 
> Signed-off-by: Richard Gobert <richardbgobert@gmail.com>
> ---
>  include/net/gro.h      | 30 +++++++++++++++---------------
>  net/ipv4/tcp_offload.c |  5 ++++-
>  2 files changed, 19 insertions(+), 16 deletions(-)
> 
> diff --git a/include/net/gro.h b/include/net/gro.h
> index 87c68007f949..322c5517f508 100644
> --- a/include/net/gro.h
> +++ b/include/net/gro.h
> @@ -75,7 +75,7 @@ struct napi_gro_cb {
>  		u8	is_fou:1;
>  
>  		/* Used to determine if ipid_offset can be ignored */
> -		u8	ip_fixedid:1;
> +		u8	ip_fixedid:2;
>  
>  		/* Number of gro_receive callbacks this packet already went through */
>  		u8 recursion_counter:4;
> @@ -442,29 +442,26 @@ static inline __wsum ip6_gro_compute_pseudo(const struct sk_buff *skb,
>  }
>  
>  static inline int inet_gro_flush(const struct iphdr *iph, const struct iphdr *iph2,
> -				 struct sk_buff *p, bool outer)
> +				 struct sk_buff *p, bool inner)
>  {
>  	const u32 id = ntohl(*(__be32 *)&iph->id);
>  	const u32 id2 = ntohl(*(__be32 *)&iph2->id);
>  	const u16 ipid_offset = (id >> 16) - (id2 >> 16);
>  	const u16 count = NAPI_GRO_CB(p)->count;
>  	const u32 df = id & IP_DF;
> -	int flush;
>  
>  	/* All fields must match except length and checksum. */
> -	flush = (iph->ttl ^ iph2->ttl) | (iph->tos ^ iph2->tos) | (df ^ (id2 & IP_DF));
> -
> -	if (flush | (outer && df))
> -		return flush;
> +	if ((iph->ttl ^ iph2->ttl) | (iph->tos ^ iph2->tos) | (df ^ (id2 & IP_DF)))
> +		return true;
>  
>  	/* When we receive our second frame we can make a decision on if we
>  	 * continue this flow as an atomic flow with a fixed ID or if we use
>  	 * an incrementing ID.
>  	 */
>  	if (count == 1 && df && !ipid_offset)
> -		NAPI_GRO_CB(p)->ip_fixedid = true;
> +		NAPI_GRO_CB(p)->ip_fixedid |= 1 << inner;
>  
> -	return ipid_offset ^ (count * !NAPI_GRO_CB(p)->ip_fixedid);
> +	return ipid_offset ^ (count * !(NAPI_GRO_CB(p)->ip_fixedid & (1 << inner)));
>  }
>  
>  static inline int ipv6_gro_flush(const struct ipv6hdr *iph, const struct ipv6hdr *iph2)
> @@ -479,7 +476,7 @@ static inline int ipv6_gro_flush(const struct ipv6hdr *iph, const struct ipv6hdr
>  
>  static inline int __gro_receive_network_flush(const void *th, const void *th2,
>  					      struct sk_buff *p, const u16 diff,
> -					      bool outer)
> +					      bool inner)
>  {
>  	const void *nh = th - diff;
>  	const void *nh2 = th2 - diff;
> @@ -487,19 +484,22 @@ static inline int __gro_receive_network_flush(const void *th, const void *th2,
>  	if (((struct iphdr *)nh)->version == 6)
>  		return ipv6_gro_flush(nh, nh2);
>  	else
> -		return inet_gro_flush(nh, nh2, p, outer);
> +		return inet_gro_flush(nh, nh2, p, inner);
>  }
>  
>  static inline int gro_receive_network_flush(const void *th, const void *th2,
>  					    struct sk_buff *p)
>  {
> -	const bool encap_mark = NAPI_GRO_CB(p)->encap_mark;
>  	int off = skb_transport_offset(p);
>  	int flush;
> +	int diff;
>  
> -	flush = __gro_receive_network_flush(th, th2, p, off - NAPI_GRO_CB(p)->network_offset, encap_mark);
> -	if (encap_mark)
> -		flush |= __gro_receive_network_flush(th, th2, p, off - NAPI_GRO_CB(p)->inner_network_offset, false);
> +	diff = off - NAPI_GRO_CB(p)->network_offset;
> +	flush = __gro_receive_network_flush(th, th2, p, diff, false);
> +	if (NAPI_GRO_CB(p)->encap_mark) {
> +		diff = off - NAPI_GRO_CB(p)->inner_network_offset;
> +		flush |= __gro_receive_network_flush(th, th2, p, diff, true);
> +	}

nit: this diff introduction is not needed. The patch is easier to
parse without the change. Even if line length will (still) be longer.

>  
>  	return flush;
>  }
> diff --git a/net/ipv4/tcp_offload.c b/net/ipv4/tcp_offload.c
> index e6612bd84d09..1949eede9ec9 100644
> --- a/net/ipv4/tcp_offload.c
> +++ b/net/ipv4/tcp_offload.c
> @@ -471,6 +471,7 @@ 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;
> @@ -484,8 +485,10 @@ 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 |
> -			(NAPI_GRO_CB(skb)->ip_fixedid * SKB_GSO_TCP_FIXEDID);
> +			(is_fixedid * SKB_GSO_TCP_FIXEDID);

Similar to how gro_receive_network_flush is called from both transport
layers, TCP and UDP, this is needed in udp_gro_complete_segment too?

Existing equivalent block is entirely missing there.

The deeper issue is that this is named TCP_FIXEDID, but in reality it
is IPV4_FIXEDID and applies to all transport layer protocols on top.

Perhaps not to fix in this series. But a limitation of USO in the
meantime.

>  
>  	tcp_gro_complete(skb);
>  	return 0;
> -- 
> 2.36.1
> 



  reply	other threads:[~2025-09-02 18:08 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-01 11:38 [PATCH net-next v4 0/5] net: gso: restore outer ip ids correctly Richard Gobert
2025-09-01 11:38 ` [PATCH net-next v4 1/5] net: gro: remove is_ipv6 from napi_gro_cb Richard Gobert
2025-09-02 17:56   ` Willem de Bruijn
2025-09-01 11:38 ` [PATCH net-next v4 2/5] net: gro: only merge packets with incrementing or fixed outer ids Richard Gobert
2025-09-02 18:08   ` Willem de Bruijn [this message]
2025-09-15  8:46     ` Richard Gobert
2025-09-01 11:38 ` [PATCH net-next v4 3/5] net: gso: restore ids of outer ip headers correctly Richard Gobert
2025-09-01 21:15   ` Edward Cree
2025-09-02 18:22   ` Willem de Bruijn
2025-09-15  9:02     ` Richard Gobert
2025-09-01 11:38 ` [PATCH net-next v4 4/5] net: gro: remove unnecessary df checks Richard Gobert
2025-09-02 18:27   ` Willem de Bruijn
2025-09-15  9:11     ` Richard Gobert
2025-09-01 11:38 ` [PATCH net-next v4 5/5] selftests/net: test ipip packets in gro.sh Richard Gobert
2025-09-02 18: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.277f254610c6e@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.