On Wed, May 22, 2024 at 6:19 PM Jakub Kicinski <kuba@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/ > 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
