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

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.

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

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.

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

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.