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]
Message-ID: <CAM0EoMmFrp5X5OzMbum5i_Bjng7Bhtk1YvWpacW6FV6Oy-3avg@mail.gmail.com>
Date: Wed, 22 May 2024 19:03:24 -0400
From: Jamal Hadi Salim <jhs@...atatu.com>
To: Jakub Kicinski <kuba@...nel.org>
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

On Wed, May 22, 2024 at 6:19 PM Jakub Kicinski <kuba@...nel.org> wrote:
>
> 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.

It's not what I "like" , rather it is a requirement to support both
s/w and h/w offload. The TC model is the traditional approach to
deploy these models. I addressed the same comment you are making above
in #1a and #1b  (https://github.com/p4tc-dev/pushback-patches).

OTOH, "BPF folks disagree with the use of their subsystem" is a
problematic statement. Is BPF infra for the kernel community or is it
something the ebpf folks can decide, at their whim, to allow who they
like to use or not. We are not changing any BPF code. And there's
already a case where the interfaces are used exactly as we used them
in the conntrack code i pointed to in the page (we literally copied
that code). Why is it ok for conntrack code to use exactly the same
approach but not us?

> AFAICT there's some but not very strong support for P4TC,

I dont agree. Paolo asked this question and afaik Intel, AMD (both
build P4-native NICs) and the folks interested in the MS DASH project
responded saying they are in support. Look at who is being Cced. A lot
of these folks who attend biweekly discussion calls on P4TC. Sample:
https://lore.kernel.org/netdev/IA0PR17MB7070B51A955FB8595FFBA5FB965E2@IA0PR17MB7070.namprd17.prod.outlook.com/

> and it
> doesn't benefit or solve any problems of the broader networking stack
> (e.g. expressing or configuring parser graphs in general)
>

I am not sure where the parser thing comes from - the parser is
generated as eBPF.

> 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.

I believe as a community nobody should just have the power to nack
things just because - as i stated in the page, not even Linus. That
code doesnt touch anything to do with eBPF maintainers (meaning things
they have to fix when an issue shows up) neither does it "extend" as
you state any ebpf code and it is all part of the networking
subsystem. Sure,  anybody has the right to nack but  I contend that
nacks should be based on technical reasons. I have listed all the
objections in that page and how i have responded to them over time.
Someone needs to look at those objectively and say if they are valid.
The arguement made so far(By Paolo and now by you)  is "we cant
override maintainers on how their subsystems are used" then we are in
uncharted territory, thats why i am asking for arbitration.

cheers,
jamal