Re: [PATCH net-next RFC 00/20] Introducing P4TC

[Jamal Hadi Salim <jhs@mojatatu.com>]

On Fri, Jan 27, 2023 at 5:26 PM <sdf@google.com> wrote:
>
> On 01/27, Jamal Hadi Salim wrote:
> > On Fri, Jan 27, 2023 at 1:26 PM Jiri Pirko <jiri@resnulli.us> wrote:
> > >
> > > Fri, Jan 27, 2023 at 12:30:22AM CET, kuba@kernel.org wrote:
> > > >On Tue, 24 Jan 2023 12:03:46 -0500 Jamal Hadi Salim wrote:
> > > >> There have been many discussions and meetings since about 2015 in
> > regards to
> > > >> P4 over TC and now that the market has chosen P4 as the datapath
> > specification
> > > >> lingua franca
> > > >
> > > >Which market?
> > > >
> > > >Barely anyone understands the existing TC offloads. We'd need strong,
> > > >and practical reasons to merge this. Speaking with my "have suffered
> > > >thru the TC offloads working for a vendor" hat on, not the "junior
> > > >maintainer" hat.
> > >
> > > You talk about offload, yet I don't see any offload code in this RFC.
> > > It's pure sw implementation.
> > >
> > > But speaking about offload, how exactly do you plan to offload this
> > > Jamal? AFAIK there is some HW-specific compiler magic needed to generate
> > > HW acceptable blob. How exactly do you plan to deliver it to the driver?
> > > If HW offload offload is the motivation for this RFC work and we cannot
> > > pass the TC in kernel objects to drivers, I fail to see why exactly do
> > > you need the SW implementation...
>
> > Our rule in TC is: _if you want to offload using TC you must have a
> > s/w equivalent_.
> > We enforced this rule multiple times (as you know).
> > P4TC has a sw equivalent to whatever the hardware would do. We are
> > pushing that
> > first. Regardless, it has value on its own merit:
> > I can run P4 equivalent in s/w in a scriptable (as in no compilation
> > in the same spirit as u32 and pedit),
> > by programming the kernel datapath without changing any kernel code.
>
> Not to derail too much, but maybe you can clarify the following for me:
> In my (in)experience, P4 is usually constrained by the vendor
> specific extensions. So how real is that goal where we can have a generic
> P4@TC with an option to offload? In my view, the reality (at least
> currently) is that there are NIC-specific P4 programs which won't have
> a chance of running generically at TC (unless we implement those vendor
> extensions).

We are going to implement all the PSA/PNA externs. Most of these
programs tend to
be set or ALU operations on headers or metadata which we can handle.
Do you have
any examples of NIC-vendor-specific features that cant be generalized?

> And regarding custom parser, someone has to ask that 'what about bpf
> question': let's say we have a P4 frontend at TC, can we use bpfilter-like
> usermode helper to transparently compile it to bpf (for SW path) instead
> inventing yet another packet parser? Wrestling with the verifier won't be
> easy here, but I trust it more than this new kParser.
>

We dont compile anything, the parser (and rest of infra) is scriptable.

cheers,
jamal