Message-ID: <CAM0EoMmXYL6DYc8UogPpS1W2rXyT0Z8JTewLonb9Eze=ofsYOg@mail.gmail.com>
Date: Wed, 22 May 2024 21:13:04 -0400
From: Jamal Hadi Salim <jhs@...atatu.com>
To: Tom Herbert <tom@...anda.io>
Cc: Chris Sommers <chris.sommers@...sight.com>, Jakub Kicinski <kuba@...nel.org>, 
	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>, 
	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>, Matty Kadosh <mattyk@...dia.com>, bpf <bpf@...r.kernel.org>, 
	"lwn@....net" <lwn@....net>
Subject: DSL vs low level language WAS(Re: On the NACKs on P4TC patches

On Wed, May 22, 2024 at 8:54 PM Tom Herbert <tom@...anda.io> wrote:
>
> On Wed, May 22, 2024 at 5:09 PM Chris Sommers
> <chris.sommers@...sight.com> wrote:
> >
> > > 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://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@IA0PR17MB7070.namprd17.prod.outlook.com/__;!!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

Powered by blists - more mailing lists