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.
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.
[+] [-] star-trek-fleet|4 years ago|reply
[+] [-] fruffy|4 years ago|reply
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
[+] [-] rektide|4 years ago|reply
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.
[+] [-] glangdale|4 years ago|reply
[edit to be more clear: I thought P4 is aimed at a much narrower, higher performance use-case than ebpf].
[+] [-] musicale|4 years ago|reply
One nice thing about P4 is that it is a machine-executable (and potentially verifiable) specification for how switching ASICs should work.
[+] [-] zurn|4 years ago|reply
[+] [-] towergratis|4 years ago|reply
[+] [-] bcantrill|4 years ago|reply
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...