Message-ID: <CAAFAkD-Uq5Zt5YgP2SwC8_vyBdJgP+_9Y_h=g+bPzxbHRSW5zw@mail.gmail.com>
Date:   Sat, 28 Jan 2023 08:41:01 -0500
From:   Jamal Hadi Salim <hadi@...atatu.com>
To:     Stanislav Fomichev <sdf@...gle.com>
Cc:     Jamal Hadi Salim <jhs@...atatu.com>, Jiri Pirko <jiri@...nulli.us>,
        Jakub Kicinski <kuba@...nel.org>, 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 Fri, Jan 27, 2023 at 7:48 PM Stanislav Fomichev <sdf@...gle.com> wrote:
>
> On Fri, Jan 27, 2023 at 3:27 PM Jamal Hadi Salim <jhs@...atatu.com> wrote:
> >
> > On Fri, Jan 27, 2023 at 5:26 PM <sdf@...gle.com> wrote:
> > >
> > > 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:

[..]
> > > 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?
>
> I don't think I can share more without giving away something that I
> shouldn't give away :-)

Fair enough.

> But IIUC, and I might be missing something, it's totally within the
> standard for vendors to differentiate and provide non-standard
> 'extern' extensions.
> I'm mostly wondering what are your thoughts on this. If I have a p4
> program depending on one of these externs, we can't sw-emulate it
> unless we also implement the extension. Are we gonna ask NICs that
> have those custom extensions to provide a SW implementation as well?
> Or are we going to prohibit vendors to differentiate that way?
>

It will dilute the value to prohibit any extern.
What you referred to as "differentiation" is most of the time just
implementation
differences i.e someone may use a TCAM vs SRAM or some specific hw
to implement crypto foobar; however, the "signature" of the extern is
no different
in its abstraction than an action. IOW, an Input X would produce an output Y in
an extern regardless of the black box implementation.
I understand the cases where some vendor may have some ASIC features that
noone else cares about and that said functions can be exposed as externs.
We really dont want these to be part of kernel proper.

In our templating above would mean using the command abstraction to
create the extern.

There are three threads:
1) PSA/PNA externs like crc, checksums, hash etc. Those are part of P4TC as
template commands. They are defined in the generic spec, they are not
vendor specific
and for almost all cases there's already kernel code that implements their
features. So we will make them accessible to P4 programs.
Vendor specific - we dont want them to be part of P4TC and we provide two
ways to address them.
2) We can emulate them without offering the equivalent functionality just so
someone can load a P4 program. This will work with P4TC as is today
but it means for that extern you dont have functional equivalence to hardware.
3) Commands, to be specific for externs can be written as kernel modules.
It's not my favorite option since we want everything to be scriptable but it
is an option available.

cheers,
jamal




> > > 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.
>
> As I've replied to Tom, that seems like a technicality. BPF programs
> can also be scriptable with some maps/tables. Or it can be made to
> look like "scriptable" by recompiling it on every configuration change
> and updating it on the fly. Or am I missing something?
>
> Can we have a P4TC frontend and whenever configuration is updated, we
> upcall into userspace to compile this whatever p4 representation into
> whatever bpf bytecode that we then run. No new/custom/scriptable
> parsers needed.
>
> > cheers,
> > jamal

Powered by blists - more mailing lists