On Wed, May 22, 2024 at 8:54 PM Tom Herbert <tom@xxxxxxxxxx> wrote: > > 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 cant stop the distraction of this thread becoming a discussion on the merits of DSL vs a lower level language (and I know you are not a P4 fan) but please change the subject so we dont loose the main focus which is a discussion on the patches. I have done it for you. Chris if you wish to respond please respond under the new thread subject. cheers, jamal cheers, jamal
