On Wed, May 22, 2024 at 5:09 PM Chris Sommers <chris.sommers@xxxxxxxxxxxx> wrote: > > > 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://urldefense.com/v3/__https://github.com/p4tc-dev/pushback-patches__;!!I5pVk4LIGAfnvw!kaZ6EmPxEqGLG8JMw-_L0BgYq48Pe25wj6pHMF6BVei5WsRgwMeLQupmvgvLyN-LgXacKBzzs0-w2zKP2A$). > > > > 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://urldefense.com/v3/__https://lore.kernel.org/netdev/IA0PR17MB7070B51A955FB8595FFBA5FB965E2@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/__;!!I5pVk4LIGAfnvw!kaZ6EmPxEqGLG8JMw-_L0BgYq48Pe25wj6pHMF6BVei5WsRgwMeLQupmvgvLyN-LgXacKBzzs09TFzoQBw$ > > > +1 > > > and it > > > doesn't benefit or solve any problems of the broader networking stack > > > (e.g. expressing or configuring parser graphs in general) > > > > > > > Huh? As a DSL, P4 has already been proven to be an extremely effective and popular way to express parse graphs, stack manipulation, and stateful programming. Yesterday, I used the P4TC dev branch to implement something in one sitting, which includes parsing RoCEv2 network stacks. I just cut and pasted P4 code originally written for a P4 ASIC into a working P4TC example to add functionality. It took mere seconds to compile and launch it, and a few minutes to test it. I know of no other workflow which provides such quick turnaround and is so accessible. I'd like it to be as ubiquitous as eBPF itself. Chris, When you say "it took mere seconds to compile and launch" are you taking into account the ramp up time that it takes to learn P4 and become proficient to do something interesting? Considering that P4 syntax is very different from typical languages than networking programmers are typically familiar with, this ramp up time is non-zero. OTOH, eBPF is ubiquitous because it's primarily programmed in Restricted C-- this makes it easy for many programmers since they don't have to learn a completely new language and so the ramp up time for the average networking programmer is much less for using eBPF. This is really the fundamental problem with DSLs, they require specialized skill sets in a programming language for a narrow use case (and specialized compilers, tool chains, debugging, etc)-- this means a DSL only makes sense if there is no other means to accomplish the same effects using a commodity language with perhaps a specialized library (it's not just in the networking realm, consider the advantages of using CUDA-C instead of a DLS for GPUs). Personally, I don't believe that P4 has yet to be proven necessary for programming a datapath-- for instance we can program a parser in declarative representation in C, https://netdevconf.info/0x16/papers/11/High%20Performance%20Programmable%20Parsers.pdf. So unless P4 is proven necessary, then I'm doubtful it will ever be a ubiquitous way to program the kernel-- it seems much more likely that people will continue to use C and eBPF, and for those users that want to use P4 they can use P4->eBPF compiler. Tom > > > 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 disagree vehemently on the "broadly useful enough" comment. > > > > 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 > Maintainers: I am perplexed and dismayed that this is getting so much pushback. None of the objections, regardless of their merits (or not) seem to outweigh the potential benefits to end-users. I am extremely interested in using P4TC, it adds a lot of value and reuses so much existing Linux infra. The custom extern model is compelling. The control plane CRUDXPS will tie nicely into P4Runtime and TDI. I have an application which needs to run purely in SW - no HW offload, so prior suggestions to wait for it to "approve" this is frustrating. I could use this yesterday. Furthermore, as an active contributor to sonic-dash, where we model the pipeline in P4, I can state that P4TC could be a compelling alternative to bmv2, which is slow, long in the tooth and lacks PNA support. > > I beseech the NACKers to take a deep breath, reevaluate any entrenched positions and consider how much goodness this will add, even if this is not your preference for implementing datapaths. It doesn't have to be. That can and should be decided by the larger community. This could open the door to thousands of creative developers who are comfortable in P4 but not adept in low-level networking code. P4 had a significant impact on democratizing network programming, and that was just on bmv2 and Tofino, which is EOL. Making performant and powerful P4TC ubiquitous on virtually any Linux server could have a similar effect, just like eBPF opened a lot of doors to non-kernel programmers to do interesting things. Be a part of that transformation!
