From: Jesper Dangaard Brouer <hawk@kernel.org>
To: Daniel Borkmann <daniel@iogearbox.net>
Cc: Yan Zhai <yan@cloudflare.com>,
Stanislav Fomichev <sdf@google.com>,
Netdev <netdev@vger.kernel.org>, bpf <bpf@vger.kernel.org>,
Alexei Starovoitov <ast@kernel.org>,
kernel-team <kernel-team@cloudflare.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Eric Dumazet <edumazet@google.com>,
"David S. Miller" <davem@davemloft.net>,
Jakub Sitnicki <jakub@cloudflare.com>
Subject: Re: Does skb_metadata_differs really need to stop GRO aggregation?
Date: Tue, 28 Nov 2023 14:06:05 +0100 [thread overview]
Message-ID: <21d05784-3cd7-4050-b66f-bad3eab73f4e@kernel.org> (raw)
In-Reply-To: <92a355bd-7105-4a17-9543-ba2d8ae36a37@kernel.org>
On 11/28/23 13:37, Jesper Dangaard Brouer wrote:
> Hi Daniel,
>
> I'm trying to understand why skb_metadata_differs() needed to block GRO ?
>
> I was looking at XDP storing information in metadata area that also
> survives into SKBs layer. E.g. the RX timestamp.
>
> Then I noticed that GRO code (gro_list_prepare) will not allow
> aggregating if metadata isn't the same in all packets via
> skb_metadata_differs(). Is this really needed?
> Can we lift/remove this limitation?
>
(Answering myself)
I understand/see now, that when an SKB gets GRO aggregated, I will
"lose" access to the metadata information and only have access to the
metadata in the "first" SKB.
Thus, GRO layer still needs this check and it cannot know if the info
was important or not.
I wonder if there is a BPF hook, prior to GRO step, that could allow me
to extract variable metadata and zero it out before GRO step.
> E.g. if I want to store a timestamp, then it will differ per packet.
>
> --Jesper
>
> Git history says it dates back to the original commit that added meta
> pointer de8f3a83b0a0 ("bpf: add meta pointer for direct access") (author
> Daniel).
>
>
> diff --git a/net/core/gro.c b/net/core/gro.c
> index 0759277dc14e..7fb6a6a24288 100644
> --- a/net/core/gro.c
> +++ b/net/core/gro.c
> @@ -341,7 +341,7 @@ static void gro_list_prepare(const struct list_head
> *head,
>
> diffs = (unsigned long)p->dev ^ (unsigned long)skb->dev;
> diffs |= p->vlan_all ^ skb->vlan_all;
> - diffs |= skb_metadata_differs(p, skb);
> + diffs |= skb_metadata_differs(p, skb); // Why?
> if (maclen == ETH_HLEN)
> diffs |= compare_ether_header(skb_mac_header(p),
next prev parent reply other threads:[~2023-11-28 13:06 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-28 12:37 Does skb_metadata_differs really need to stop GRO aggregation? Jesper Dangaard Brouer
2023-11-28 13:06 ` Jesper Dangaard Brouer [this message]
2023-11-28 13:30 ` Daniel Borkmann
2023-11-28 14:39 ` Toke Høiland-Jørgensen
2023-11-29 18:04 ` Edward Cree
2023-11-29 21:52 ` Toke Høiland-Jørgensen
2023-11-29 23:10 ` Daniel Borkmann
2023-11-30 13:55 ` Toke Høiland-Jørgensen
2023-11-30 16:32 ` Daniel Borkmann
2023-11-30 20:35 ` Jesper Dangaard Brouer
2023-11-30 22:00 ` Martin KaFai Lau
2023-12-01 6:20 ` Yan Zhai
2023-12-01 17:09 ` Yan Zhai
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=21d05784-3cd7-4050-b66f-bad3eab73f4e@kernel.org \
--to=hawk@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=jakub@cloudflare.com \
--cc=kernel-team@cloudflare.com \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=sdf@google.com \
--cc=yan@cloudflare.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).