p4c-xdp

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

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,