Message-ID: <CAM0EoMkiN7oXVcQo8WEY_ddFr2X-Fzb9+cU2VaLFJ4aXZgZJbA@mail.gmail.com>
Date: Sat, 3 Jun 2023 10:42:42 -0400
From: Jamal Hadi Salim <jhs@...atatu.com>
To: Marcelo Ricardo Leitner <mleitner@...hat.com>
Cc: netdev@...r.kernel.org, deb.chatterjee@...el.com, anjali.singhai@...el.com, 
	namrata.limaye@...el.com, jiri@...nulli.us, xiyou.wangcong@...il.com, 
	davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org, pabeni@...hat.com, 
	tom@...anda.io, p4tc-discussions@...devconf.info, vladbu@...dia.com, 
	simon.horman@...igine.com, khalidm@...dia.com, toke@...hat.com, 
	Mahesh.Shirshyad@....com, Vipin.Jain@....com, tomasz.osinski@...el.com, 
	mattyk@...dia.com, dan.daly@...el.com, john.andy.fingerhut@...el.com
Subject: Re: [PATCH RFC net-next 00/28 v2] Introducing P4TC

On Fri, Jun 2, 2023 at 6:48 PM Marcelo Ricardo Leitner
<mleitner@...hat.com> wrote:
>
> On Wed, May 17, 2023 at 07:02:25AM -0400, Jamal Hadi Salim wrote:
> > We are seeking community feedback on P4TC patches.
>
> This was the first time I read these patches. I don't have much to
> comment on it overall yet.

Thanks for all the effort you put in - those were excellent comments.

> >
> > Apologies, I know this is a large number of patches but it is the best we could
> > do so as not to miss the essence of the work.
> > Please do note that > 50% of LOC are testcases. I should have emphasized
> > this last time to improve the quality of the discussions, but mea culpa.
>
> And much of the LOC that are not testcases, are for the CRUD
> implementations. P4 is not simpe and allowing such simple
> manipulations of all those types to the user comes at a cost and I
> don't see a way around that.

Yes, the core is much less code. Note: Our goal is to _never_ make any
kernel code changes (or user space for that matter), sans bugs. So
CRUD where you have <CMD> <NOUN/PATH> [Optional data] semantics is a
major part of that architecture and netlink helps us a lot so we dont
have to reinvent the infrastructure. So that code is needed to ensure
that.

> The scripts seem long and complex, but they can be structured and are
> human readable. I like how one is able to inspect the datapath no
> matter how it was configured (from a p4 program or manually built).
> This helps a lot with the supportability of solutions based on it.

Yeah, that is part of the dilemma we have with adding ebpf support -
loosing that simpler operational approach. In mode 1 (where only the
parser is ebpf) it is still there and i think this is what you mean by
the scripts being long and complex. A human should still be able to
create them even though in this case they are generated by a compiler.
In mode 2 the template scripts get simpler but the dependency on ebpf
and loss of operational simplicity is stronger.
See for example
https://github.com/p4tc-dev/p4tc-v2-examples/blob/main/model1/1table/exact/redirect_l2_pna_1t_exact.template
vs https://github.com/p4tc-dev/p4tc-v2-examples/blob/main/model2/1table/exact/redirect_l2_pna_1t_exact.template
I really like the scriptable version we posted in the first RFC for
the operational simplicity (honestly still conflicted on whether we
should totally remove it but we are trying to meet the ebpf people in
the middle).

> One thing that I hate about u32 is that it is like perl^W^Wwrite-only.
> It is as flexible as u32, but making sense out of those matches is a
> nightmare.

We are doing much much better than u32 or pedit despite taking the
inspiration from them ;-> Usability for sure is highly improved in
comparison to those two.

> The approach here keeps the flexibility, while not
> becoming as complex and slow moving as flower and yet, understandable
> by humans. A promising in between the two extreme approaches that we
> have in tc today.

yes. This is in many ways a big improvement over the flower approach
and builds on the lessons from flower deployment.

Thanks again Marcelo for taking the time.

cheers,
jamal

Powered by blists - more mailing lists