netdev - Re: On the NACKs on P4TC patches

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]

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.