P4: Open-Source Programming Language for Protocol-Independent Packet Processing(p4.org)
p4.org
P4: Open-Source Programming Language for Protocol-Independent Packet Processing
https://p4.org/
20 comments
IIRC p4 is losing ground to ebpf, right?
P4 and eBPF are not really competing in the same space. eBPF/XDP is a virtual kernel machine that you can program in restricted C. P4 is a language that specifies how a device should process packets. So P4 is compiled down into a target (for example, a switch or NIC), which then executes the code as specified by the programmer. The nice part about P4, compared to just working with the devices, is that it establishes a standard reference format for administration and control of packet processing. For example, Google is using P4 to test their switches (they talk about it in their keynote in this workshop [0]).
The eBPF/XDP VM could be one of these P4 targets. You can write a P4 specification that is converted into eBPF byte code which is then loaded and executed. The reference P4 compiler even has a eBPF[1] and an XDP[2] back end. However, those are currently not well maintained. Another problem is that the code generated from P4 is not as efficient as manually crafted eBPF byte code. With a little care this is all easily solvable.
Disclaimer: I work in this space.
[0]: https://opennetworking.org/2021-p4-workshop-content/
[1]: https://github.com/p4lang/p4c/tree/main/backends/ebpf
[2]: https://github.com/vmware/p4c-xdp
The eBPF/XDP VM could be one of these P4 targets. You can write a P4 specification that is converted into eBPF byte code which is then loaded and executed. The reference P4 compiler even has a eBPF[1] and an XDP[2] back end. However, those are currently not well maintained. Another problem is that the code generated from P4 is not as efficient as manually crafted eBPF byte code. With a little care this is all easily solvable.
Disclaimer: I work in this space.
[0]: https://opennetworking.org/2021-p4-workshop-content/
[1]: https://github.com/p4lang/p4c/tree/main/backends/ebpf
[2]: https://github.com/vmware/p4c-xdp
[deleted]
1. it's not gaining mindshare as quickly! last month's cilium 1.10 release for example mentioned ebpf 17 times. you can dig up a dozen new ebpf stories a week if you look around, probably. anyone with a bunch of random nodes can be using ebpf, & well. anyone wanting to do new tricks in the kernel can be using ebpf, & quickly, to try.
2. I'm not sure the horse race mentality helps. p4 generally helps complex fancy hardware get programmed to be extra effective. it's not as generally applicable, it feels like today, as ebpf, even within the packet processing subconcerms of ebpf (which is now really the kernels generic programmabilitu mechanism, not necessarily only for packets). but that doesn't change how vital & critical it is that we have ways to program & use that switch hardware, we need those switches, we need ways to program them. ebpf does not do that job. Linux systems don't have dozens of TBps of throughput, hardware does & it needs programming.
I'd love to see p4 be a more effective competitor to ebpf, to have more presence & visibility & be better understood & more used by more systems researchers. but right now these are not really competitors, p4 is in a totally different realm. and it doesn't have many competitors.
to that end, I'd forgotten about this but the reference p4 compiler has a ebpf backend target, https://github.com/p4lang/p4c/blob/main/backends/ebpf/README...
which makes me feel like it's better control and systems to drive p4, that are easier to adopt, that is core to it getting broader interest, pickup, research interest.
2. I'm not sure the horse race mentality helps. p4 generally helps complex fancy hardware get programmed to be extra effective. it's not as generally applicable, it feels like today, as ebpf, even within the packet processing subconcerms of ebpf (which is now really the kernels generic programmabilitu mechanism, not necessarily only for packets). but that doesn't change how vital & critical it is that we have ways to program & use that switch hardware, we need those switches, we need ways to program them. ebpf does not do that job. Linux systems don't have dozens of TBps of throughput, hardware does & it needs programming.
I'd love to see p4 be a more effective competitor to ebpf, to have more presence & visibility & be better understood & more used by more systems researchers. but right now these are not really competitors, p4 is in a totally different realm. and it doesn't have many competitors.
to that end, I'd forgotten about this but the reference p4 compiler has a ebpf backend target, https://github.com/p4lang/p4c/blob/main/backends/ebpf/README...
which makes me feel like it's better control and systems to drive p4, that are easier to adopt, that is core to it getting broader interest, pickup, research interest.
It's a baffling idea that these are competing for the same market, but maybe ebpf is going new places?
[edit to be more clear: I thought P4 is aimed at a much narrower, higher performance use-case than ebpf].
[edit to be more clear: I thought P4 is aimed at a much narrower, higher performance use-case than ebpf].
Presumably it's quite a bit cheaper (and more power efficient) to build a 6.4 terabit P4/Tofino switch vs. building a 6.4 terabit switch with eBPF on x86, ARM, or even NPUs. P4 can also enable an SDN control channel, P4runtime, that uses gRPC.
One nice thing about P4 is that it is a machine-executable (and potentially verifiable) specification for how switching ASICs should work.
One nice thing about P4 is that it is a machine-executable (and potentially verifiable) specification for how switching ASICs should work.
Does ebpf have a programming language? I've seen blog posts about writing ebpf programs with Zig, Rust, C++, C at least.
You just answered your own question.
Ok. So the P4 language is not competing with it, and could be made to compile to ebpf.
You are exactly right. In fact, there are a number of approaches in this space: p4c-ebpf [0], p4c-xdp [1], and p4c-ubpf [2].
[0] https://github.com/p4lang/p4c/blob/main/backends/ebpf/README... [1] https://github.com/vmware/p4c-xdp [2] https://opennetworking.org/news-and-events/blog/p4c-ubpf-a-n...
[0] https://github.com/p4lang/p4c/blob/main/backends/ebpf/README... [1] https://github.com/vmware/p4c-xdp [2] https://opennetworking.org/news-and-events/blog/p4c-ubpf-a-n...
It's a potential competitor to eBPF/C/etc. on CPUs, NPUs, and Smart NICs.
It's nice that the same P4 program can potentially be compiled for high-speed ASICs, NPUs, Smart NICs and CPUs.
I think P4 could potentially have been developed as a subset of C, and that might have been a good thing? On the other hand, having customized language features for header parsing, state machines, etc. can be convenient for both language users and compiler writers who are targeting switching ASICs. It may also make formal analysis more convenient.
It's nice that the same P4 program can potentially be compiled for high-speed ASICs, NPUs, Smart NICs and CPUs.
I think P4 could potentially have been developed as a subset of C, and that might have been a good thing? On the other hand, having customized language features for header parsing, state machines, etc. can be convenient for both language users and compiler writers who are targeting switching ASICs. It may also make formal analysis more convenient.
P4 pretty much died together with Barefoot Networks
Barefoot didn't die -- they were acquired by Intel, who has continued to invest in it with the development and introduction of Tofino 2.[0] Moreover, P4 is not/was not Barefoot alone; to take an example that's relevant to us, the P4 application working group working on the In-band Network Telemetry Dataplane Specification[1] includes participation from Alibaba, Arista, CableLabs, Cisco Systems, Dell, Intel, Marvell, Netronome, and VMware.
Disclosure: We are using both Intel Tofino 2 and P4 at Oxide and we (obviously?) think it's pretty interesting.
[0] https://www.servethehome.com/intel-tofino2-next-gen-programm...
[1] https://github.com/p4lang/p4-applications/blob/master/docs/I...
Disclosure: We are using both Intel Tofino 2 and P4 at Oxide and we (obviously?) think it's pretty interesting.
[0] https://www.servethehome.com/intel-tofino2-next-gen-programm...
[1] https://github.com/p4lang/p4-applications/blob/master/docs/I...
I would expect to see Intel pushing P4 heavily over the next year. P4 will almost certainly be involved in the roadmap for their recently released IPU (a SmartNIC needs some type of programmable substrate). Also, their data platforms group had been recruiting heavily around the Barefoot Networks / P4 angle. AND, just this morning, Pat Gelsinger announced the data platforms group is being split into two groups —- one of which (the Network and Edge group) to be headed by Nick McKeown, former chairman and cofounder of Barefoot Networks, as senior vice president [0].
[0] https://www.lightreading.com/5g/intels-reorg-puts-nick-mckeo...
[0] https://www.lightreading.com/5g/intels-reorg-puts-nick-mckeo...
Quick quote[1] on what a SmartNIC is:
> The Silicom FPGA SmartNIC N5010 features an Intel Stratix 10 DX FPGA with integrated high bandwidth memory (HBM) and Intel Ethernet 800 series adapter.
4x100G. Double slot.
There's also a C5000X platform, with I believe only one board out right now, which is again an FPGA based add-on card, 2x25G, and also has an on-card Xeon-D processor.
Just a little reminder here at the end, AMD is still trying to get it's acquisition of the biggest FPGA company on the planet Xilinx to go through. And my general assessment of P4: P4 definitely is a strong contender for a tech which can get these fancy awesome transciever-heavy FPGAs to see more adoption.
[1] https://www.hpcwire.com/off-the-wire/intel-announced-two-new...
> The Silicom FPGA SmartNIC N5010 features an Intel Stratix 10 DX FPGA with integrated high bandwidth memory (HBM) and Intel Ethernet 800 series adapter.
4x100G. Double slot.
There's also a C5000X platform, with I believe only one board out right now, which is again an FPGA based add-on card, 2x25G, and also has an on-card Xeon-D processor.
Just a little reminder here at the end, AMD is still trying to get it's acquisition of the biggest FPGA company on the planet Xilinx to go through. And my general assessment of P4: P4 definitely is a strong contender for a tech which can get these fancy awesome transciever-heavy FPGAs to see more adoption.
[1] https://www.hpcwire.com/off-the-wire/intel-announced-two-new...
Are these the jobs based in Israel?
Primarily based out of Santa Clara, California. All of the Santa Clara roles on this page [0] are in the Barefoot Switching Division (BXD) of the Data Platforms Group. It makes sense given the Barefoot Networks headquarters were in Santa Clara.
[0] https://jobs.intel.com/page/show/US-Connectivity-Jobs
[0] https://jobs.intel.com/page/show/US-Connectivity-Jobs
You can probably remove Netronome from the list. They stopped developing/supporting P4 and mostly dead. They tried to switch to ebpf but I don't think they succeeded. Sad story
It does kinda look like Tofino 2 was delayed two years by the acquisition, eerily reminiscent of the FM6000 delay that cost Fulcrum all of its market share. Tofino 3 should probably be sampling by now.
What does tooling / debugging for p4 look like? How do you inspect what happens inside a p4 dataplane?
Context: I work on a L4 load balancer written in ebpf / XDP. Debugging that is still too hard even thought it's all software and open source.
Context: I work on a L4 load balancer written in ebpf / XDP. Debugging that is still too hard even thought it's all software and open source.