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,
shenjian15@huawei.com, salil.mehta@huawei.com,
shaojijie@huawei.com, andrew+netdev@lunn.ch,
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, ahmed.zaki@intel.com,
aleksander.lobakin@intel.com, florian.fainelli@broadcom.com,
willemdebruijn.kernel@gmail.com, linux-kernel@vger.kernel.org,
linux-net-drivers@amd.com,
Richard Gobert <richardbgobert@gmail.com>
Subject: Re: [PATCH net-next v2 2/5] net: gro: only merge packets with incrementing or fixed outer ids
Date: Tue, 19 Aug 2025 10:46:01 -0400 [thread overview]
Message-ID: <willemdebruijn.kernel.a8507becb441@gmail.com> (raw)
In-Reply-To: <20250819063223.5239-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
> 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 | 26 +++++++++++---------------
> net/ipv4/tcp_offload.c | 4 +++-
> 2 files changed, 14 insertions(+), 16 deletions(-)
>
> diff --git a/include/net/gro.h b/include/net/gro.h
> index 87c68007f949..e7997a9fb30b 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,18 @@ 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;
>
> - 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);
> + flush = __gro_receive_network_flush(th, th2, p, off - NAPI_GRO_CB(p)->network_offset, false);
> + if (NAPI_GRO_CB(p)->encap_mark)
> + flush |= __gro_receive_network_flush(th, th2, p, off - NAPI_GRO_CB(p)->inner_network_offset, true);
It's a bit unclear what the meaning of inner and outer are in the
unencapsulated (i.e., normal) case. In my intuition outer only exists
if encapsulated, but it seems you reason the other way around: inner
is absent unless encapsulated. I guess they're equivalent, but please
explicitly comment this choice somewhere.
>
> return flush;
> }
> diff --git a/net/ipv4/tcp_offload.c b/net/ipv4/tcp_offload.c
> index be5c2294610e..74f46663eeae 100644
> --- a/net/ipv4/tcp_offload.c
> +++ b/net/ipv4/tcp_offload.c
> @@ -485,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);
>
> + bool is_fixedid = (NAPI_GRO_CB(skb)->ip_fixedid >> skb->encapsulation) & 1;
> +
Variable definition at top of function (or basic block)
> skb_shinfo(skb)->gso_type |= SKB_GSO_TCPV4 |
> - (NAPI_GRO_CB(skb)->ip_fixedid * SKB_GSO_TCP_FIXEDID);
> + (is_fixedid * SKB_GSO_TCP_FIXEDID);
>
> tcp_gro_complete(skb);
> return 0;
> --
> 2.36.1
>
next prev parent reply other threads:[~2025-08-19 14:46 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-19 6:32 [PATCH net-next v2 0/5] net: gso: restore outer ip ids correctly Richard Gobert
2025-08-19 6:32 ` [PATCH net-next v2 1/5] net: gro: remove is_ipv6 from napi_gro_cb Richard Gobert
2025-08-19 8:47 ` Eric Dumazet
2025-08-19 12:26 ` Richard Gobert
2025-08-19 6:32 ` [PATCH net-next v2 2/5] net: gro: only merge packets with incrementing or fixed outer ids Richard Gobert
2025-08-19 14:46 ` Willem de Bruijn [this message]
2025-08-20 0:30 ` Jakub Kicinski
2025-08-20 12:27 ` Richard Gobert
2025-08-20 15:04 ` Jakub Kicinski
2025-08-20 0:30 ` Jakub Kicinski
2025-08-19 6:32 ` [PATCH net-next v2 3/5] net: gso: restore ids of outer ip headers correctly Richard Gobert
2025-08-19 6:32 ` [PATCH net-next v2 4/5] net: gro: remove unnecessary df checks Richard Gobert
2025-08-20 11:24 ` Willem de Bruijn
2025-08-19 6:32 ` [PATCH net-next v2 5/5] selftests/net: test ipip packets in gro.sh Richard Gobert
2025-08-20 11:21 ` Willem de Bruijn
2025-08-20 12:21 ` Richard Gobert
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.a8507becb441@gmail.com \
--to=willemdebruijn.kernel@gmail.com \
--cc=ahmed.zaki@intel.com \
--cc=aleksander.lobakin@intel.com \
--cc=andrew+netdev@lunn.ch \
--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=salil.mehta@huawei.com \
--cc=sdf@fomichev.me \
--cc=shaojijie@huawei.com \
--cc=shenjian15@huawei.com \
--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).