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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8602c88c98fd722db8e164a1520c56aebfa64db7.camel@siemens.com>
Date: Mon, 04 Dec 2023 12:54:56 +0100
From: Florian Bezdeka <florian.bezdeka@...mens.com>
To: Jesper Dangaard Brouer <hawk@...nel.org>, Song Yoong Siang
 <yoong.siang.song@...el.com>, "David S . Miller" <davem@...emloft.net>,
 Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, Paolo
 Abeni <pabeni@...hat.com>, Jonathan Corbet <corbet@....net>, Bjorn Topel
 <bjorn@...nel.org>, Magnus Karlsson <magnus.karlsson@...el.com>, Maciej
 Fijalkowski <maciej.fijalkowski@...el.com>, Jonathan Lemon
 <jonathan.lemon@...il.com>, Alexei Starovoitov <ast@...nel.org>, Daniel
 Borkmann <daniel@...earbox.net>, John Fastabend <john.fastabend@...il.com>,
 Stanislav Fomichev <sdf@...gle.com>, Lorenzo Bianconi <lorenzo@...nel.org>,
 Tariq Toukan <tariqt@...dia.com>, Willem de Bruijn <willemb@...gle.com>,
 Maxime Coquelin <mcoquelin.stm32@...il.com>, Andrii Nakryiko
 <andrii@...nel.org>, 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>
Cc: netdev@...r.kernel.org, linux-kernel@...r.kernel.org, 
 linux-doc@...r.kernel.org, bpf@...r.kernel.org, xdp-hints@...-project.net, 
 linux-stm32@...md-mailman.stormreply.com,
 linux-arm-kernel@...ts.infradead.org,  linux-kselftest@...r.kernel.org
Subject: Re: [xdp-hints] Re: [PATCH bpf-next v3 2/3] net: stmmac: add Launch
 Time support to XDP ZC

On Mon, 2023-12-04 at 11:36 +0100, Jesper Dangaard Brouer wrote:
> On 12/3/23 17:51, Song Yoong Siang wrote:
> > This patch enables Launch Time (Time-Based Scheduling) support to XDP zero
> > copy via XDP Tx metadata framework.
> > 
> > Signed-off-by: Song Yoong Siang<yoong.siang.song@...el.com>
> > ---
> >   drivers/net/ethernet/stmicro/stmmac/stmmac.h      |  2 ++
> 
> As requested before, I think we need to see another driver implementing 
> this.
> 
> I propose driver igc and chip i225.

igc support would be really nice and highly appreciated. There are a
lot of tests running here with that chip (i225/i226) / driver (igc)
combination. Let me know if we can support somehow, testing included.

> 
> The interesting thing for me is to see how the LaunchTime max 1 second
> into the future[1] is handled code wise. One suggestion is to add a 
> section to Documentation/networking/xsk-tx-metadata.rst per driver that 
> mentions/documents these different hardware limitations.  It is natural 
> that different types of hardware have limitations.  This is a close-to 
> hardware-level abstraction/API, and IMHO as long as we document the 
> limitations we can expose this API without too many limitations for more 
> capable hardware.
> 
>   [1] 
> https://github.com/xdp-project/xdp-project/blob/master/areas/tsn/code01_follow_qdisc_TSN_offload.org#setup-code-driver-igb
> 
> This stmmac driver and Intel Tiger Lake CPU must also have some limit on 
> how long into the future it will/can schedule packets?
> 
> 
> People from xdp-hints list must make their voice hear if they want i210 
> and igb driver support, because it have even-more hardware limitations, 
> see [1] (E.g. only TX queue 0 and 1 supports LaunchTime). BUT I know 
> some have this hardware in production and might be motivated to get a 
> functioning driver with this feature?

i210 support would be nice, that would allow us to compare some test
setups with different NICs. In addition it would simplify some test
setups. For now, IMHO igc is more important.

> 
> --Jesper


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ