Message-ID: <Y9RPsYbi2a9Q/H8h@google.com>
Date:   Fri, 27 Jan 2023 14:26:57 -0800
From:   sdf@...gle.com
To:     Jamal Hadi Salim <hadi@...atatu.com>
Cc:     Jiri Pirko <jiri@...nulli.us>, Jakub Kicinski <kuba@...nel.org>,
        Jamal Hadi Salim <jhs@...atatu.com>, netdev@...r.kernel.org,
        kernel@...atatu.com, deb.chatterjee@...el.com,
        anjali.singhai@...el.com, namrata.limaye@...el.com,
        khalidm@...dia.com, tom@...anda.io, pratyush@...anda.io,
        xiyou.wangcong@...il.com, davem@...emloft.net, edumazet@...gle.com,
        pabeni@...hat.com, vladbu@...dia.com, simon.horman@...igine.com,
        stefanc@...vell.com, seong.kim@....com, mattyk@...dia.com,
        dan.daly@...el.com, john.andy.fingerhut@...el.com
Subject: Re: [PATCH net-next RFC 00/20] Introducing P4TC

On 01/27, Jamal Hadi Salim wrote:
> On Fri, Jan 27, 2023 at 1:26 PM Jiri Pirko <jiri@...nulli.us> wrote:
> >
> > Fri, Jan 27, 2023 at 12:30:22AM CET, kuba@...nel.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).

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.

> To answer your question in regards to what the interfaces "P4
> speaking" hardware or drivers
> are going to be programmed, there are discussions going on right now:
> There is a strong
> leaning towards devlink for the hardware side loading.... The idea
> from the driver side is to
> reuse the tc ndos.
> We have biweekly meetings which are open. We do have Nvidia folks, but
> would be great if
> we can have you there. Let me find the link and send it to you.
> Do note however, our goal is to get s/w first as per tradition of
> other offloads with TC .

> cheers,
> jamal

Powered by blists - more mailing lists