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: <20240522151933.6f422e63@kernel.org>
Date: Wed, 22 May 2024 15:19:33 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Jamal Hadi Salim <jhs@...atatu.com>
Cc: Paolo Abeni <pabeni@...hat.com>, Alexei Starovoitov
 <alexei.starovoitov@...il.com>, Network Development
 <netdev@...r.kernel.org>, "Chatterjee, Deb" <deb.chatterjee@...el.com>,
 Anjali Singhai Jain <anjali.singhai@...el.com>, "Limaye, Namrata"
 <namrata.limaye@...el.com>, tom Herbert <tom@...anda.io>, Marcelo Ricardo
 Leitner <mleitner@...hat.com>, "Shirshyad, Mahesh"
 <Mahesh.Shirshyad@....com>, "Osinski, Tomasz" <tomasz.osinski@...el.com>,
 Jiri Pirko <jiri@...nulli.us>, Cong Wang <xiyou.wangcong@...il.com>, "David
 S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, Vlad
 Buslov <vladbu@...dia.com>, Simon Horman <horms@...nel.org>, Khalid Manaa
 <khalidm@...dia.com>, Toke Høiland-Jørgensen
 <toke@...hat.com>, Victor Nogueira <victor@...atatu.com>, Pedro Tammela
 <pctammela@...atatu.com>, "Jain, Vipin" <Vipin.Jain@....com>, "Daly, Dan"
 <dan.daly@...el.com>, Andy Fingerhut <andy.fingerhut@...il.com>, Chris
 Sommers <chris.sommers@...sight.com>, Matty Kadosh <mattyk@...dia.com>, bpf
 <bpf@...r.kernel.org>, lwn@....net
Subject: Re: On the NACKs on P4TC patches

Hi Jamal!

On Tue, 21 May 2024 08:35:07 -0400 Jamal Hadi Salim wrote:
> At that point(v16) i asked for the series to be applied despite the
> Nacks because, frankly, the Nacks have no merit. Paolo was not
> comfortable applying patches with Nacks and tried to mediate. In his
> mediation effort he asked if we could remove eBPF - and our answer was
> no because after all that time we have become dependent on it and
> frankly there was no technical reason not to use eBPF.

I'm not fully clear on who you're appealing to, and I may be missing
some points. But maybe it will be more useful than hurtful if I clarify
my point of view.

AFAIU BPF folks disagree with the use of their subsystem, and they
point out that P4 pipelines can be implemented using BPF in the first
place.
To which you reply that you like (a highly dated type of) a netlink
interface, and (handwavey) ability to configure the data path SW or 
HW via the same interface.

AFAICT there's some but not very strong support for P4TC, and it
doesn't benefit or solve any problems of the broader networking stack
(e.g. expressing or configuring parser graphs in general)

So from my perspective, the submission is neither technically strong
enough, nor broadly useful enough to consider making questionable precedents
for, i.e. to override maintainers on how their subsystems are extended.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ