From: "Toke Høiland-Jørgensen" <toke@redhat.com>
To: Edward Cree <ecree.xilinx@gmail.com>,
Daniel Borkmann <daniel@iogearbox.net>,
Jesper Dangaard Brouer <hawk@kernel.org>
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: Wed, 29 Nov 2023 22:52:28 +0100 [thread overview]
Message-ID: <87plzsi5wj.fsf@toke.dk> (raw)
In-Reply-To: <0b0c6538-92a5-3041-bc48-d7286f1b873b@gmail.com>
Edward Cree <ecree.xilinx@gmail.com> writes:
> On 28/11/2023 14:39, Toke Høiland-Jørgensen wrote:
>> I'm not quite sure what should be the semantics of that, though. I.e.,
>> if you are trying to aggregate two packets that have the flag set, which
>> packet do you take the value from? What if only one packet has the flag
>> set? Or should we instead have a "metadata_xdp_only" flag that just
>> prevents the skb metadata field from being set entirely? Or would both
>> be useful?
>
> Sounds like what's actually needed is bpf progs inside the GRO engine
> to implement the metadata "protocol" prepare and coalesce callbacks?
Hmm, yes, I guess that would be the most general solution :)
-Toke
next prev parent reply other threads:[~2023-11-29 21:52 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
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 [this message]
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=87plzsi5wj.fsf@toke.dk \
--to=toke@redhat.com \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=ecree.xilinx@gmail.com \
--cc=edumazet@google.com \
--cc=hawk@kernel.org \
--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 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.