3 ms·
You just answered your own question.
by hobo_mark 5y ago
You just answered your own question.
- zurn 5y agoOk. So the P4 language is not competing with it, and could be made to compile to ebpf.
- doctorsher 5y agoYou 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.md https://github.com/p4lang/p4c/blob/main/backends/ebpf/README... [1] https://github.com/vmware/p4c-xdp https://github.com/vmware/p4c-xdp [2] https://opennetworking.org/news-and-events/blog/p4c-ubpf-a-new-back-end-for-the-p4-compiler/ https://opennetworking.org/news-and-events/blog/p4c-ubpf-a-n...
- musicale 5y agoIt'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.