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.
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.
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.
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.
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.
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.
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].
> 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.
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.
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.
