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: <PH0PR11MB5830FC4C6958D616A22D4428D8F42@PH0PR11MB5830.namprd11.prod.outlook.com>
Date: Tue, 4 Feb 2025 13:46:18 +0000
From: "Song, Yoong Siang" <yoong.siang.song@...el.com>
To: "Fijalkowski, Maciej" <maciej.fijalkowski@...el.com>
CC: "David S . Miller" <davem@...emloft.net>, Eric Dumazet
	<edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni
	<pabeni@...hat.com>, Simon Horman <horms@...nel.org>, Willem de Bruijn
	<willemb@...gle.com>, "Bezdeka, Florian" <florian.bezdeka@...mens.com>,
	Donald Hunter <donald.hunter@...il.com>, Jonathan Corbet <corbet@....net>,
	Bjorn Topel <bjorn@...nel.org>, "Karlsson, Magnus"
	<magnus.karlsson@...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>, Faizal Rahim
	<faizal.abdul.rahim@...ux.intel.com>, Choong Yong Liang
	<yong.liang.choong@...ux.intel.com>, "Bouska, Zdenek"
	<zdenek.bouska@...mens.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: [PATCH bpf-next v7 4/5] igc: Refactor empty packet insertion into
 a reusable function

On Tuesday, February 4, 2025 8:36 PM, Fijalkowski, Maciej <maciej.fijalkowski@...el.com> wrote:
>On Tue, Feb 04, 2025 at 12:07:21PM +0100, Song, Yoong Siang wrote:

[...]

>>
>> "insert an empty packet" is a launch time trick to send a packet in
>> next Qbv cycle. The design is, the driver will still sending the
>> packet, even the empty packet insertion trick is fail (unable to
>> allocate). The intention of this patch set is to enable launch time
>> on XDP zero-copy data path, so I try not to change the original
>> behavior of launch time.
>>
>> btw, do you think driver should drop the packet if something went
>> wrong with the launch time, like launch time offload not enabled,
>> launch time over horizon, empty packet insertion fail, etc?
>> If yes, then maybe i can submit another patch to change the behavior
>> of launch time and we can continue to discuss there.
>
>That's rather a question to you since I am no TSN expert here :P
>the alloc skbs failures would rather be a minor thing but anyways it
>didn't look correct from a first glance to silently ignore this behavior
>if rest of the logic relies on this. I won't be insisting on any changes
>here but it's something you could consider to change maybe.

I got plan to refactor the launch time configuration, but that requires
more discussion, so I prefer to submit another separate patch for it.
I will keep the launch time configuration the original way, so that
this patch set have least impact to non XDP path.

>
>The real question is in 5/5, regarding the cleaning of these empty descs
>from ZC path.
>

Sure, I replied to your comments in 5/5. Let's continue the discussion there.

Thanks & Regards
Siang

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ