{inet,ipv6}_gro_receive functions perform flush checks (ttl, flags,
iph->id, ...) against all packets in a loop. These flush checks are
relevant only to tcp flows, and as such they're used to determine whether
the packets can be merged later in tcp_gro_receive.
These checks are not relevant to UDP packets. Furthermore, they need to be
done only once in tcp_gro_receive and only against the found p skb, since
they only affect flush and not same_flow.
Levaraging the previous commit in the series, in which correct network
header offsets are saved for both outer and inner network headers -
allowing these checks to be done only once, in tcp_gro_receive. As a
result, NAPI_GRO_CB(p)->flush is not used at all. In addition - flush_id
checks are more declerative and contained in inet_gro_flush, thus removing
the need for flush_id in napi_gro_cb.
This results in less parsing code for UDP flows and non-loop flush tests
for TCP flows.
For example, running 40 IP/UDP netperf connections:
./super_netperf.sh 40 -H 1.1.1.2 -t UDP_STREAM -l 120
Running perf top for 90s we can see that relatively less time is spent
on inet_gro_receive when GRO is not coalescing UDP:
net-next:
1.26% [kernel] [k] inet_gro_receive
patch applied:
0.85% [kernel] [k] inet_gro_receive
udpgro_bench.sh single connection GRO improvement:
net-next:
0.76% [kernel] [k] inet_gro_receive
patch applied:
0.61% [kernel] [k] inet_gro_receive
Signed-off-by: Richard Gobert <richardbgobert@gmail.com>
---
include/net/gro.h | 9 ++----
net/core/gro.c | 3 --
net/ipv4/af_inet.c | 36 ---------------------
net/ipv4/tcp_offload.c | 72 ++++++++++++++++++++++++++++++++++--------
net/ipv6/ip6_offload.c | 11 -------
5 files changed, 62 insertions(+), 69 deletions(-)
diff --git a/include/net/gro.h b/include/net/gro.h
index 9d1389269509..34e50f77f744 100644
--- a/include/net/gro.h
+++ b/include/net/gro.h
@@ -35,15 +35,15 @@ struct napi_gro_cb {
/* This is non-zero if the packet cannot be merged with the new skb. */
u16 flush;
- /* Save the IP ID here and check when we get to the transport layer */
- u16 flush_id;
-
/* Number of segments aggregated. */
u16 count;
/* Used in ipv6_gro_receive() and foo-over-udp and esp-in-udp */
u16 proto;
+ /* used to support CHECKSUM_COMPLETE for tunneling protocols */
+ __wsum csum;
+
/* Used in napi_gro_cb::free */
#define NAPI_GRO_FREE 1
#define NAPI_GRO_FREE_STOLEN_HEAD 2
@@ -84,9 +84,6 @@ struct napi_gro_cb {
u8 is_flist:1;
);
- /* used to support CHECKSUM_COMPLETE for tunneling protocols */
- __wsum csum;
-
/* L3 offsets */
union {
struct {
diff --git a/net/core/gro.c b/net/core/gro.c
index 2b42138f816c..128d7b9c8dfb 100644
--- a/net/core/gro.c
+++ b/net/core/gro.c
@@ -332,8 +332,6 @@ static void gro_list_prepare(const struct list_head *head,
list_for_each_entry(p, head, list) {
unsigned long diffs;
- NAPI_GRO_CB(p)->flush = 0;
-
if (hash != skb_get_hash_raw(p)) {
NAPI_GRO_CB(p)->same_flow = 0;
continue;
@@ -473,7 +471,6 @@ static enum gro_result dev_gro_receive(struct napi_struct *napi, struct sk_buff
sizeof(u32))); /* Avoid slow unaligned acc */
*(u32 *)&NAPI_GRO_CB(skb)->zeroed = 0;
NAPI_GRO_CB(skb)->flush = skb_has_frag_list(skb);
- NAPI_GRO_CB(skb)->is_atomic = 1;
NAPI_GRO_CB(skb)->count = 1;
if (unlikely(skb_is_gso(skb))) {
NAPI_GRO_CB(skb)->count = skb_shinfo(skb)->gso_segs;
diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
index c6bb21c27aee..5b74c6d2ed8b 100644
--- a/net/ipv4/af_inet.c
+++ b/net/ipv4/af_inet.c
@@ -1512,7 +1512,6 @@ struct sk_buff *inet_gro_receive(struct list_head *head, struct sk_buff *skb)
list_for_each_entry(p, head, list) {
struct iphdr *iph2;
- u16 flush_id;
if (!NAPI_GRO_CB(p)->same_flow)
continue;
@@ -1529,43 +1528,8 @@ struct sk_buff *inet_gro_receive(struct list_head *head, struct sk_buff *skb)
NAPI_GRO_CB(p)->same_flow = 0;
continue;
}
-
- /* All fields must match except length and checksum. */
- NAPI_GRO_CB(p)->flush |=
- (iph->ttl ^ iph2->ttl) |
- (iph->tos ^ iph2->tos) |
- ((iph->frag_off ^ iph2->frag_off) & htons(IP_DF));
-
- NAPI_GRO_CB(p)->flush |= flush;
-
- /* We need to store of the IP ID check to be included later
- * when we can verify that this packet does in fact belong
- * to a given flow.
- */
- flush_id = (u16)(id - ntohs(iph2->id));
-
- /* This bit of code makes it much easier for us to identify
- * the cases where we are doing atomic vs non-atomic IP ID
- * checks. Specifically an atomic check can return IP ID
- * values 0 - 0xFFFF, while a non-atomic check can only
- * return 0 or 0xFFFF.
- */
- if (!NAPI_GRO_CB(p)->is_atomic ||
- !(iph->frag_off & htons(IP_DF))) {
- flush_id ^= NAPI_GRO_CB(p)->count;
- flush_id = flush_id ? 0xFFFF : 0;
- }
-
- /* If the previous IP ID value was based on an atomic
- * datagram we can overwrite the value and ignore it.
- */
- if (NAPI_GRO_CB(skb)->is_atomic)
- NAPI_GRO_CB(p)->flush_id = flush_id;
- else
- NAPI_GRO_CB(p)->flush_id |= flush_id;
}
- NAPI_GRO_CB(skb)->is_atomic = !!(iph->frag_off & htons(IP_DF));
NAPI_GRO_CB(skb)->flush |= flush;
/* Note : No need to call skb_gro_postpull_rcsum() here,
diff --git a/net/ipv4/tcp_offload.c b/net/ipv4/tcp_offload.c
index fde800179b2e..c165e72555e1 100644
--- a/net/ipv4/tcp_offload.c
+++ b/net/ipv4/tcp_offload.c
@@ -178,6 +178,55 @@ struct sk_buff *tcp_gso_segment(struct sk_buff *skb,
return segs;
}
+static int inet_gro_flush(const struct iphdr *iph, const struct iphdr *iph2,
+ struct sk_buff *p, u32 outer)
+{
+ const u32 id = ntohl(*(__be32 *)&iph->id);
+ const u32 id2 = ntohl(*(__be32 *)&iph2->id);
+ const int flush_id = ntohs(id >> 16) - ntohs(id2 >> 16);
+ const u16 count = NAPI_GRO_CB(p)->count;
+ const u32 df = id & IP_DF;
+ u32 is_atomic;
+ int flush;
+
+ /* All fields must match except length and checksum. */
+ flush = (iph->ttl ^ iph2->ttl) | (iph->tos ^ iph2->tos) | (df ^ (id2 & IP_DF));
+
+ /* 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 incremdfenting ID.
+ */
+ if (count == 1) {
+ is_atomic = df && flush_id == 0;
+ NAPI_GRO_CB(p)->is_atomic = is_atomic;
+ } else {
+ is_atomic = df && NAPI_GRO_CB(p)->is_atomic;
+ }
+
+ /* Ignore outer IP ID value if based on atomic datagram. */
+ outer = (outer && df) - 1;
+ is_atomic--;
+
+ return flush | ((flush_id ^ (count & is_atomic)) & outer);
+}
+
+static int ipv6_gro_flush(const struct ipv6hdr *iph, const struct ipv6hdr *iph2)
+{
+ /* <Version:4><Traffic_Class:8><Flow_Label:20> */
+ __be32 first_word = *(__be32 *)iph ^ *(__be32 *)iph2;
+
+ /* Flush if Traffic Class fields are different. */
+ return (first_word & htonl(0x0FF00000)) |
+ (__force __be32)(iph->hop_limit ^ iph2->hop_limit);
+}
+
+static int gro_network_flush(const void *nh, const void *nh2,
+ struct sk_buff *p, u32 outer)
+{
+ return (((struct iphdr *)nh)->version == 6) ? ipv6_gro_flush(nh, nh2) :
+ inet_gro_flush(nh, nh2, p, outer);
+}
+
struct sk_buff *tcp_gro_receive(struct list_head *head, struct sk_buff *skb)
{
struct sk_buff *pp = NULL;
@@ -190,6 +239,7 @@ struct sk_buff *tcp_gro_receive(struct list_head *head, struct sk_buff *skb)
unsigned int mss = 1;
unsigned int hlen;
unsigned int off;
+ bool encap_mark;
int flush = 1;
int i;
@@ -232,9 +282,7 @@ struct sk_buff *tcp_gro_receive(struct list_head *head, struct sk_buff *skb)
goto out_check_final;
found:
- /* Include the IP ID check below from the inner most IP hdr */
- flush = NAPI_GRO_CB(p)->flush;
- flush |= (__force int)(flags & TCP_FLAG_CWR);
+ flush = (__force int)(flags & TCP_FLAG_CWR);
flush |= (__force int)((flags ^ tcp_flag_word(th2)) &
~(TCP_FLAG_CWR | TCP_FLAG_FIN | TCP_FLAG_PSH));
flush |= (__force int)(th->ack_seq ^ th2->ack_seq);
@@ -242,16 +290,14 @@ struct sk_buff *tcp_gro_receive(struct list_head *head, struct sk_buff *skb)
flush |= *(u32 *)((u8 *)th + i) ^
*(u32 *)((u8 *)th2 + i);
- /* When we receive our second frame we can made a decision on if we
- * continue this flow as an atomic flow with a fixed ID or if we use
- * an incrementing ID.
- */
- if (NAPI_GRO_CB(p)->flush_id != 1 ||
- NAPI_GRO_CB(p)->count != 1 ||
- !NAPI_GRO_CB(p)->is_atomic)
- flush |= NAPI_GRO_CB(p)->flush_id;
- else
- NAPI_GRO_CB(p)->is_atomic = false;
+ encap_mark = NAPI_GRO_CB(skb)->encap_mark;
+ for (i = 0; i <= encap_mark; i++) {
+ const u16 diff = off - NAPI_GRO_CB(skb)->network_offsets[i];
+
+ flush |= gro_network_flush((void *)th - diff,
+ (void *)th2 - diff,
+ p, i != encap_mark);
+ }
mss = skb_shinfo(p)->gso_size;
diff --git a/net/ipv6/ip6_offload.c b/net/ipv6/ip6_offload.c
index d9d3a6bed510..b1850c20d799 100644
--- a/net/ipv6/ip6_offload.c
+++ b/net/ipv6/ip6_offload.c
@@ -288,19 +288,8 @@ INDIRECT_CALLABLE_SCOPE struct sk_buff *ipv6_gro_receive(struct list_head *head,
nlen - sizeof(struct ipv6hdr)))
goto not_same_flow;
}
- /* flush if Traffic Class fields are different */
- NAPI_GRO_CB(p)->flush |= !!((first_word & htonl(0x0FF00000)) |
- (__force __be32)(iph->hop_limit ^ iph2->hop_limit));
- NAPI_GRO_CB(p)->flush |= flush;
-
- /* If the previous IP ID value was based on an atomic
- * datagram we can overwrite the value and ignore it.
- */
- if (NAPI_GRO_CB(skb)->is_atomic)
- NAPI_GRO_CB(p)->flush_id = 0;
}
- NAPI_GRO_CB(skb)->is_atomic = true;
NAPI_GRO_CB(skb)->flush |= flush;
skb_gro_postpull_rcsum(skb, iph, nlen);
--
2.36.1Richard Gobert wrote:
> {inet,ipv6}_gro_receive functions perform flush checks (ttl, flags,
> iph->id, ...) against all packets in a loop. These flush checks are
> relevant only to tcp flows, and as such they're used to determine whether
> the packets can be merged later in tcp_gro_receive.
>
> These checks are not relevant to UDP packets.
These are network protocol coalescing invariants. Why would they be
limited to certain transport protocols only?
> Furthermore, they need to be
> done only once in tcp_gro_receive and only against the found p skb, since
> they only affect flush and not same_flow.
>
> Levaraging the previous commit in the series, in which correct network
> header offsets are saved for both outer and inner network headers -
> allowing these checks to be done only once, in tcp_gro_receive. As a
> result, NAPI_GRO_CB(p)->flush is not used at all. In addition - flush_id
> checks are more declerative and contained in inet_gro_flush, thus removing
declarative
> the need for flush_id in napi_gro_cb.
>
> Signed-off-by: Richard Gobert <richardbgobert@gmail.com>
> ---
> +static int inet_gro_flush(const struct iphdr *iph, const struct iphdr *iph2,
> + struct sk_buff *p, u32 outer)
> +{
> + const u32 id = ntohl(*(__be32 *)&iph->id);
> + const u32 id2 = ntohl(*(__be32 *)&iph2->id);
> + const int flush_id = ntohs(id >> 16) - ntohs(id2 >> 16);
> + const u16 count = NAPI_GRO_CB(p)->count;
> + const u32 df = id & IP_DF;
> + u32 is_atomic;
> + int flush;
> +
> + /* All fields must match except length and checksum. */
> + flush = (iph->ttl ^ iph2->ttl) | (iph->tos ^ iph2->tos) | (df ^ (id2 & IP_DF));
> +
> + /* 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 incremdfenting ID.
> + */
Comment became garbled on move: incrementing
> + if (count == 1) {
> + is_atomic = df && flush_id == 0;
> + NAPI_GRO_CB(p)->is_atomic = is_atomic;
> + } else {
> + is_atomic = df && NAPI_GRO_CB(p)->is_atomic;
> + }
> +
> + /* Ignore outer IP ID value if based on atomic datagram. */
> + outer = (outer && df) - 1;
> + is_atomic--;
> +
> + return flush | ((flush_id ^ (count & is_atomic)) & outer);
> +}
Willem de Bruijn wrote:
> Richard Gobert wrote:
>> {inet,ipv6}_gro_receive functions perform flush checks (ttl, flags,
>> iph->id, ...) against all packets in a loop. These flush checks are
>> relevant only to tcp flows, and as such they're used to determine whether
>> the packets can be merged later in tcp_gro_receive.
>>
>> These checks are not relevant to UDP packets.
>
> These are network protocol coalescing invariants. Why would they be
> limited to certain transport protocols only?
Thanks for the review, I'll fix the typos.
I replied to Eric's comment about the relevancy of these checks for UDP.
On Sat, Mar 9, 2024 at 4:35 PM Richard Gobert <richardbgobert@gmail.com> wrote:
>
> {inet,ipv6}_gro_receive functions perform flush checks (ttl, flags,
> iph->id, ...) against all packets in a loop. These flush checks are
> relevant only to tcp flows, and as such they're used to determine whether
> the packets can be merged later in tcp_gro_receive.
>
> These checks are not relevant to UDP packets.
I do not think this claim is true.
Incoming packets -> GRO -> GSO -> forwarded packets
The {GRO,GSO} step must be transparent, GRO is not LRO.
Eric Dumazet wrote:
> On Sat, Mar 9, 2024 at 4:35 PM Richard Gobert <richardbgobert@gmail.com> wrote:
>>
>> {inet,ipv6}_gro_receive functions perform flush checks (ttl, flags,
>> iph->id, ...) against all packets in a loop. These flush checks are
>> relevant only to tcp flows, and as such they're used to determine whether
>> the packets can be merged later in tcp_gro_receive.
>>
>> These checks are not relevant to UDP packets.
>
> I do not think this claim is true.
>
> Incoming packets -> GRO -> GSO -> forwarded packets
>
> The {GRO,GSO} step must be transparent, GRO is not LRO.
Sorry, I should rephrase myself. The patch preserves the
current logic in GRO. These L3 checks (ttl, flags, etc.) are written to
NAPI_GRO_CB(p)->{flush,flush_id}, and NAPI_GRO_CB(skb)->is_atomic - and
all of these are currently used only in tcp_gro_receive.
Richard Gobert wrote:
> Eric Dumazet wrote:
> > On Sat, Mar 9, 2024 at 4:35 PM Richard Gobert <richardbgobert@gmail.com> wrote:
> >>
> >> {inet,ipv6}_gro_receive functions perform flush checks (ttl, flags,
> >> iph->id, ...) against all packets in a loop. These flush checks are
> >> relevant only to tcp flows, and as such they're used to determine whether
> >> the packets can be merged later in tcp_gro_receive.
> >>
> >> These checks are not relevant to UDP packets.
> >
> > I do not think this claim is true.
> >
> > Incoming packets -> GRO -> GSO -> forwarded packets
> >
> > The {GRO,GSO} step must be transparent, GRO is not LRO.
>
> Sorry, I should rephrase myself. The patch preserves the
> current logic in GRO. These L3 checks (ttl, flags, etc.) are written to
> NAPI_GRO_CB(p)->{flush,flush_id}, and NAPI_GRO_CB(skb)->is_atomic - and
> all of these are currently used only in tcp_gro_receive.
That was perhaps an oversight when adding UDP GRO?
Simply because the flush is determined in the innermost callback.
Willem de Bruijn wrote:
> Richard Gobert wrote:
>> Eric Dumazet wrote:
>>> On Sat, Mar 9, 2024 at 4:35 PM Richard Gobert <richardbgobert@gmail.com> wrote:
>>>>
>>>> {inet,ipv6}_gro_receive functions perform flush checks (ttl, flags,
>>>> iph->id, ...) against all packets in a loop. These flush checks are
>>>> relevant only to tcp flows, and as such they're used to determine whether
>>>> the packets can be merged later in tcp_gro_receive.
>>>>
>>>> These checks are not relevant to UDP packets.
>>>
>>> I do not think this claim is true.
>>>
>>> Incoming packets -> GRO -> GSO -> forwarded packets
>>>
>>> The {GRO,GSO} step must be transparent, GRO is not LRO.
>>
>> Sorry, I should rephrase myself. The patch preserves the
>> current logic in GRO. These L3 checks (ttl, flags, etc.) are written to
>> NAPI_GRO_CB(p)->{flush,flush_id}, and NAPI_GRO_CB(skb)->is_atomic - and
>> all of these are currently used only in tcp_gro_receive.
>
> That was perhaps an oversight when adding UDP GRO?
>
> Simply because the flush is determined in the innermost callback.
It might have been an oversight. From what I have seen it's only relevant
to GRO's UDP fraglist path (it was added in 9fd1ff5d ("udp: Support UDP
fraglist GRO/GSO.")). That's the only UDP path that calls skb_gro_receive -
which may alter the forwarded packets and make GRO/GSO not transparent.
AFAIU NAPI_GRO_CB(p)->flush value is not overwritten in encapsulation - it
is determined by both outer and inner callbacks.
I tried to preserve the current behaviour in GRO - if we want to change
this behaviour I'll gladly do it, although I'd prefer to address it in a
different patch series. What do you think?
Thanks
Richard Gobert wrote:
> Willem de Bruijn wrote:
> > Richard Gobert wrote:
> >> Eric Dumazet wrote:
> >>> On Sat, Mar 9, 2024 at 4:35 PM Richard Gobert <richardbgobert@gmail.com> wrote:
> >>>>
> >>>> {inet,ipv6}_gro_receive functions perform flush checks (ttl, flags,
> >>>> iph->id, ...) against all packets in a loop. These flush checks are
> >>>> relevant only to tcp flows, and as such they're used to determine whether
> >>>> the packets can be merged later in tcp_gro_receive.
> >>>>
> >>>> These checks are not relevant to UDP packets.
> >>>
> >>> I do not think this claim is true.
> >>>
> >>> Incoming packets -> GRO -> GSO -> forwarded packets
> >>>
> >>> The {GRO,GSO} step must be transparent, GRO is not LRO.
> >>
> >> Sorry, I should rephrase myself. The patch preserves the
> >> current logic in GRO. These L3 checks (ttl, flags, etc.) are written to
> >> NAPI_GRO_CB(p)->{flush,flush_id}, and NAPI_GRO_CB(skb)->is_atomic - and
> >> all of these are currently used only in tcp_gro_receive.
> >
> > That was perhaps an oversight when adding UDP GRO?
> >
> > Simply because the flush is determined in the innermost callback.
>
> It might have been an oversight. From what I have seen it's only relevant
> to GRO's UDP fraglist path (it was added in 9fd1ff5d ("udp: Support UDP
> fraglist GRO/GSO.")). That's the only UDP path that calls skb_gro_receive -
> which may alter the forwarded packets and make GRO/GSO not transparent.
>
> AFAIU NAPI_GRO_CB(p)->flush value is not overwritten in encapsulation - it
> is determined by both outer and inner callbacks.
Thanks for the context
> I tried to preserve the current behaviour in GRO - if we want to change
> this behaviour I'll gladly do it, although I'd prefer to address it in a
> different patch series. What do you think?
Yes, it's entirely reasonable to leave that out of this series.
© 2016 - 2026 Red Hat, Inc.