Date:   Mon, 30 Jan 2023 11:13:10 +0100
From:   Jiri Pirko <jiri@...nulli.us>
To:     John Fastabend <john.fastabend@...il.com>
Cc:     Jamal Hadi Salim <jhs@...atatu.com>,
        Willem de Bruijn <willemb@...gle.com>,
        Stanislav Fomichev <sdf@...gle.com>,
        Jamal Hadi Salim <hadi@...atatu.com>,
        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

Mon, Jan 30, 2023 at 05:30:17AM CET, john.fastabend@...il.com wrote:
>Jamal Hadi Salim wrote:
>> On Sun, Jan 29, 2023 at 12:39 AM John Fastabend
>> <john.fastabend@...il.com> wrote:
>> >
>> > Willem de Bruijn wrote:
>> > > On Sat, Jan 28, 2023 at 10:10 AM Jamal Hadi Salim <jhs@...atatu.com> wrote:
>> > > >
>> >
>> > [...]
>> >
>> >
>> > Also there already exists a P4 backend that targets BPF.
>> >
>> >  https://github.com/p4lang/p4c
>> 
>> There's also one based on rust - does that mean we should rewrite our
>> code in rust?
>> Joking aside - rust was a suggestion made at a talk i did. I ended up
>> adding a slide for the next talk which read:
>> 
>> Title: So... how is this better than KDE?
>>   Attributed to Rusty Russell
>>      Who attributes it to Cort Dougan
>>       s/KDE/[rust/ebpf/dpdk/vpp/ovs]/g
>> 
>> We have very specific goals - of which the most important is met by
>> what works today and we are reusing that.
>
>OK, I may have missed your goals I read the cover letter and merely
>scanned the patches. But, seeing we've chatted about this before
>let me put my critique here.
>
>P4TC as a software datapath:
>
>1. We can already run P4 in software with P4C which compiles into an
>   existing BPF implementations, nothing new needed. If we object
>   to p4c implementation there are others (VMWare has one for XDP)
>   or feel free to write any other DSL or abstraction over BPF.
>
>2. 'tc' layer is not going to be as fast as XDP so without an XDP
>   implementation we can't get best possible implementation.
>
>3. Happy to admit I don't have data, but I'm not convinced a match
>   action pipeline is an ideal implementation for software. It is
>   done specifically in HW to facilitate CAMs/TCAMs and other special
>   logic blocks that do not map well to general purpose CPU. BPF or
>   other insn are better abstraction for software.
>
>So I struggle to find upside as a purely software implementation.
>If you took an XDP P4 backend and then had this implementation
>showing performance or some other vector where a XDP implementation
>underperformed that would be interesting. Then either we would have
>good reason to try another datapath or 
>
>P4TC as a hardware datapath:
>
>1. We don't have a hardware/driver implementation to review so its
>   difficult to even judge if this is a good idea or not.
>
>2. I imagine most hardware can not create TCAMs/CAMs out of
>   nothing. So there is a hard problem that I believe is not
>   addressed here around how user knows their software blob
>   can ever be offloaded at all. How you move to new hw and
>   the blob can continue to work so and an so forth.
>
>3. FPGA P4 implementations as far as I recall can use P4 to build
>   the pipeline up front. But, once its built its not like you
>   would (re)build it or (re)configure it on the fly. But the workflow
>   doesn't align with how I understand these patches.
>
>4. Has any vendor with a linux driver (maybe not even in kernel yet)
>   open sourced anything that resembles a P4 pipeline? Without
>   this its again hard to understand what is possible and what
>   vendors will let users do.
>
>P4TC as SW/HW running same P4:
>
>1. This doesn't need to be done in kernel. If one compiler runs
>   P4 into XDP or TC-BPF that is good and another compiler runs
>   it into hw specific backend. This satisifies having both
>   software and hardware implementation.
>
>Extra commentary: I agree we've been chatting about this for a long
>time but until some vendor (Intel?) will OSS and support a linux
>driver and hardware with open programmable parser and MAT. I'm not
>sure how we get P4 for Linux users. Does it exist and I missed it?


John, I think that your summary is quite accurate. Regarding SW
implementation, I have to admit I also fail to see motivation to have P4
specific datapath instead of having XDP/eBPF one, that could run P4
compiled program. The only motivation would be that if somehow helps to
offload to HW. But can it?

Regarding HW implementation. I believe that every HW implementation is
very specific and to find some common intermediate kernel uAPI is
probably not possible (correct me if I'm wrong, that that is the
impression I'm getting from all parties). Then the only option is to
allow userspace to insert HW-speficic blob that is an output of
per-vendor P4 compilator.

Now is this blob uAPI channel possible to be introduced? How it should
look like? How to enforce limitations so it is not exploited for other
purposes as a kernel bypass?



>
>Thanks,
>John
>
>> 
>> cheers,
>> jamal
>> 
>> > So as a SW object we can just do the P4 compilation step in user
>> > space and run it in BPF as suggested. Then for hw offload we really
>> > would need to see some hardware to have any concrete ideas on how
>> > to make it work.
>> >
>> 
>> 
>> > Also P4 defines a runtime API so would be good to see how all that
>> > works with any proposed offload.
>
>Yep agree with your other comment not really important can be built
>on top of Netlink or BPF today.

Powered by blists - more mailing lists