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.