[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20250127112045.7e3997fc@kernel.org>
Date: Mon, 27 Jan 2025 11:20:45 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: Florian Bezdeka <florian.bezdeka@...mens.com>
Cc: Toke Høiland-Jørgensen <toke@...hat.com>,
Stanislav Fomichev <stfomichev@...il.com>, "Song, Yoong Siang"
<yoong.siang.song@...el.com>, "Bouska, Zdenek" <zdenek.bouska@...mens.com>,
"David S . Miller" <davem@...emloft.net>, Eric Dumazet
<edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>, Simon Horman
<horms@...nel.org>, Willem de Bruijn <willemb@...gle.com>, Donald Hunter
<donald.hunter@...il.com>, Jonathan Corbet <corbet@....net>, Bjorn Topel
<bjorn@...nel.org>, "Karlsson, Magnus" <magnus.karlsson@...el.com>,
"Fijalkowski, Maciej" <maciej.fijalkowski@...el.com>, Jonathan Lemon
<jonathan.lemon@...il.com>, Andrew Lunn <andrew+netdev@...n.ch>, Alexei
Starovoitov <ast@...nel.org>, Daniel Borkmann <daniel@...earbox.net>,
Jesper Dangaard Brouer <hawk@...nel.org>, John Fastabend
<john.fastabend@...il.com>, "Damato, Joe" <jdamato@...tly.com>, Stanislav
Fomichev <sdf@...ichev.me>, Xuan Zhuo <xuanzhuo@...ux.alibaba.com>, Mina
Almasry <almasrymina@...gle.com>, Daniel Jurgens <danielj@...dia.com>,
Andrii Nakryiko <andrii@...nel.org>, Eduard Zingerman <eddyz87@...il.com>,
Mykola Lysenko <mykolal@...com>, Martin KaFai Lau <martin.lau@...ux.dev>,
Song Liu <song@...nel.org>, Yonghong Song <yonghong.song@...ux.dev>, KP
Singh <kpsingh@...nel.org>, Hao Luo <haoluo@...gle.com>, Jiri Olsa
<jolsa@...nel.org>, Shuah Khan <shuah@...nel.org>, Alexandre Torgue
<alexandre.torgue@...s.st.com>, Jose Abreu <joabreu@...opsys.com>, Maxime
Coquelin <mcoquelin.stm32@...il.com>, "Nguyen, Anthony L"
<anthony.l.nguyen@...el.com>, "Kitszel, Przemyslaw"
<przemyslaw.kitszel@...el.com>, "netdev@...r.kernel.org"
<netdev@...r.kernel.org>, "linux-kernel@...r.kernel.org"
<linux-kernel@...r.kernel.org>, "linux-doc@...r.kernel.org"
<linux-doc@...r.kernel.org>, "bpf@...r.kernel.org" <bpf@...r.kernel.org>,
"linux-kselftest@...r.kernel.org" <linux-kselftest@...r.kernel.org>,
"linux-stm32@...md-mailman.stormreply.com"
<linux-stm32@...md-mailman.stormreply.com>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>, "intel-wired-lan@...ts.osuosl.org"
<intel-wired-lan@...ts.osuosl.org>, "xdp-hints@...-project.net"
<xdp-hints@...-project.net>
Subject: Re: [xdp-hints] Re: [PATCH bpf-next v6 4/4] igc: Add launch time
support to XDP ZC
On Mon, 27 Jan 2025 19:29:35 +0100 Florian Bezdeka wrote:
> > > Yeah, I don't think we can impose UAPI restrictions on the metadata area
> > > at this point. I guess the best we can do is to educate users that they
> > > should call the timestamp kfunc before they modify the metadata?
> >
> > I may be misunderstanding the discussion, but I think the answer
> > is that the driver must be fixed. The metadata-in-prepend problem
> > also exists for simple adjust head use case, so it existed since
> > early days of BPF. The driver should copy out (or parse) the metadata
> > before it invokes the XDP prog. The nfp driver does that.
>
> That would have to happen for each packet, without affecting ZC
> performance. How can that be achieved?
Are you asking how we can make it not affect performance?
We should really see some benchmarks before we say that it is okay
to sacrifice correctness..
> So we have at least two drivers with that problem, igc + nfp.
To be clear nfp copies the HW metadata out before calling XDP.
So XDP program can do whatever it wants to the space before the packet.
> My main point: Enabling and implementing ZC (zero copy) mode at one
> hand, but then starting to copy the meta data for each packet doesn't
> sound reasonable.
🤷️
Powered by blists - more mailing lists