On Wed, May 22, 2024 at 7:30 PM Chris Sommers <chris.sommers@xxxxxxxxxxxx> wrote: > > > On Wed, May 22, 2024 at 8:54 PM Tom Herbert <mailto:tom@xxxxxxxxxx> wrote: > > > > > > On Wed, May 22, 2024 at 5:09 PM Chris Sommers > > > <mailto:chris.sommers@xxxxxxxxxxxx> wrote: > > > > > > > > > On Wed, May 22, 2024 at 6:19 PM Jakub Kicinski <mailto: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? > > Hi Tom, thanks for the dialog. To answer your question, it took seconds to compile and deploy, not learn P4. Adding the parsing for several headers took minutes. If you want to compare learning curve, learning to write P4 code and let the framework handle all the painful low-level Linux details is way easier than trying to learn how to write c code for Linux networking. It’s not even close. I’ve written C for 40 years, P4 for 7 years, and dabbled in eBPF so I can attest to the ease of learning and using P4. I’ve onboarded and mentored engineers who barely knew C, to develop complex networking products using P4, and built the automation APIs (REST, gRPC) to manage them. One person can develop an entire commercial product by themselves in months. P4 has expanded the reach of programmers such that both HW and SW engineers can easily learn P4 and become pretty adept at it. I would not expect even experienced c programmers to be able to master Linux internals very quickly. Writing a P4-TC program and injecting it via tc was like magic the first time. > > >> 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. > > I think your statement about “typical network programmers” overlooks the fact that since P4 was introduced, it has been taught in many universities to teach networking and possibly enabled a whole new breed of “network engineers” who can solve real problems without even knowing C programming. Without P4 they might never have gone this route. A class in network stack programming using c would have so many prerequisites to even get to parsing, compared to P4, where it could be demonstrated in one lesson. These “networking programmers” are not typical by your standards, but there are many such. They have just as much claim to the title "network programmer” as a C programmer. Similarly, an assembly language programmer is no less than a C or Python programmer. People writing P4 are usually focused on applications, and it is very useful and productive for that. Why should someone have to learn low-level C or eBPF to solve their problem? Hio Chris, You're comparing learning a completely new language versus programming in a subset of an established language, they're really not comparable. When one programs in Restricted-C they just need to understand what features of C are supported. > > > > > > > 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). > > A pretty strong opinion, but DSLs arise to fill a need and P4 did so. It's still going strong. > > >> 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://urldefense.com/v3/__https://netdevconf.info/0x16/papers/11/High*20Performance*20Programmable*20Parsers.pdf__;JSUl!!I5pVk4LIGAfnvw!m9zrSDvddfzSt_sMBjOEvqw31RzAwWlEDM4ah5IJ2kqsmq6XtPIVJd-1_ZoGWBXKLyda77RYLvGR83Ginw$. > > CPL (slide11) looks like a DSL wrapped in JSON to me. “Solution: Common Parser Language (CPL); Parser representation in declarative .json” So I am confused. It is either a new language a.k.a. DSL, or it's not. Nothing against it, I'm sure it is great, but let's call it what it is. Correct, it's not a new language. We've since renamed it Common Parser Representation. > We already have parser representations in declarative p4. And it's used and known worldwide. And has a respectable specification, any users and working groups. And it's formally provable (https://github.com/verified-network-toolchain/petr4) > > > > > > > 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. > > “ubiquitous way to program the kernel” – is not my goal. I don’t even want to know about the kernel when I am writing p4 - it's just a means to an end. I want to manipulate packets on a Linux host. P4DPDK, P4-eBPF, P4-TC – all let me do that. I LOVE the fact that P4-TC would be available in every Linux distro once upstreamed. It would solve so many deployment issues, benefit from regression testing, etc. So much goodness > > " and for those users that want to use P4 they can use P4->eBPF compiler." -I'd really like to choose for myself and not have someone make that choice for me. P4-TC checks all the boxes for me. Sure, but this is a lot of kernel code and that will require support and maintenance. It needs to be justified, and the fact that someone wants it just to have a choice is, frankly, not much of a justification. I think a justification needs to start with "Why isn't P4->eBPF sufficient?" (the question has been raised several times, but it still doesn't seem like there's a strong answer). Tom > > Thanks for the point of view, it's healthy to debate. > Cheers, > Chris > > > > > > > > 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 >
