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

[Stephen Hemminger <stephen@networkplumber.org>]

On Sat, 28 Jan 2023 13:17:35 -0800
Tom Herbert <tom@herbertland.com> wrote:

> On Fri, Jan 27, 2023 at 5:34 PM Singhai, Anjali
> <anjali.singhai@intel.com> wrote:
> >
> > P4 is definitely the language of choice for defining a Dataplane in HW for IPUs/DPUs/FNICs and Switches. As a vendor I can definitely say that the smart devices implement a very programmable ASIC as each customer Dataplane defers quite a bit and P4 is the language of choice for specifying the Dataplane definitions. A lot of customer deploy proprietary protocols that run in HW and there is no good way right now in kernel to support these proprietary protcols. If we enable these protocol in the kernel it takes a huge effort and they don’t evolve well.
> > Being able to define in P4 and offload into HW using tc mechanism really helps in supporting the customer's Dataplane and protcols without having to wait months and years to get the kernel updated. Here is a link to our IPU offering that is P4 programmable  
> 
> Anjali,
> 
> P4 may be the language of choice for programming HW datapath, however
> it's not the language of choice for programming SW datapaths-- that's
> C over XDP/eBPF. And while XDP/eBPF also doesn't depend on kernel
> updates, it has a major advantage over P4 in that it doesn't require
> fancy hardware either.
> 
> Even at full data center deployment of P4 devices, there will be at
> least an order of magnitude more deployment of SW programmed
> datapaths; and unless someone is using P4 hardware, there's zero value
> in rewriting programs in P4 instead of C. IMO, we will never see
> networking developers moving to P4 en masse-- P4 will always be a
> niche market relative to the programmable datapath space and the skill
> sets required to support serious scalable deployment. That being said,
> there will be a nontrivial contingent of users who need to run the
> same programs in both SW and HW environments. Expecting them to
> maintain two very different code bases to support two disparate models
> is costly and prohibitive to them. So for their benefit, we need a
> solution to reconcile these two models. P4TC is one means to
> accomplish that.
> 
> We want to consider both the permutations: 1) compile C code to run in
> P4 hardware 2) compile P4 to run in SW. If we establish a common IR,
> then we can generalize the problem: programmer writes their datapath
> in the language of their choosing (P4, C, Python, Rust, etc.), they
> compile the program to whatever backend they are using (HW, SW,
> XDP/eBPF, etc.). The P4TC CLI serves as one such IR as there's nothing
> that prevents someone from compiling a program from another language
> to the CLI (for instance, we've implemented the compiler to output the
> parser CLI from PANDA-C). The CLI natively runs in kernel SW, and with
> the right hooks could be offloaded to HW-- not just P4 hardware but
> potentially other hardware targets as well.

Rather than more kernel network software, if instead this was
targeting userspace or eBPF for the SW version; then there would
be less exposed security risk and also less long term technical debt
here.