Date:   Sun, 29 Jan 2023 20:30:17 -0800
From:   John Fastabend <john.fastabend@...il.com>
To:     Jamal Hadi Salim <jhs@...atatu.com>,
        John Fastabend <john.fastabend@...il.com>
Cc:     Willem de Bruijn <willemb@...gle.com>,
        Stanislav Fomichev <sdf@...gle.com>,
        Jamal Hadi Salim <hadi@...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

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?

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