lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <221bb71f7d2464cd566e4a4110423ea56b173cf6.camel@siemens.com>
Date: Mon, 27 Jan 2025 19:29:35 +0100
From: Florian Bezdeka <florian.bezdeka@...mens.com>
To: Jakub Kicinski <kuba@...nel.org>, Toke
 Høiland-Jørgensen
	 <toke@...hat.com>
Cc: 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, 2025-01-27 at 10:04 -0800, Jakub Kicinski wrote:
> On Fri, 24 Jan 2025 12:45:42 +0100 Toke Høiland-Jørgensen wrote:
> > > > I think there is no simple fix for that. That needs some discussion
> > > > around the "expectations" to the headroom / meta data area in front of
> > > > the actual packet data.  
> > > 
> > > By 'simple' you mean without some new UAPI to signal the size of that
> > > 'reserved area' by the driver? I don't see any other easy way out as well :-/  
> > 
> > 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?

So we have at least two drivers with that problem, igc + nfp. 

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

Powered by Openwall GNU/*/Linux Powered by OpenVZ