On Sun, 3 Mar 2024 14:04:11 -0500 Jamal Hadi Salim wrote: > > At > > this point in its lifetime, eBPF had far more examples of real world > > use cases publically available. That being said, there's nothing > > unique about P4 supporting the network calculator. We could just as > > easily write this in eBPF (either plain C or P4) and "offload" it to > > an ARM core on a SmartNIC. > > With current port speeds hitting 800gbps you want to use Arm cores as > your offload engine?;-> Running the generated ebpf on the arm core is > a valid P4 target. i.e there is no contradiction. > Note: P4 is a DSL specialized for datapath definition; it is not a > competition to ebpf, two different worlds. I see ebpf as an > infrastructure tool, nothing more. I wonder how much we're benefiting of calling this thing P4 and how much we should focus on filling in the tech gaps. Exactly like you said, BPF is not competition, but neither does the kernel "support P4", any more than it supports bpftrace and: $ git grep --files-with-matches bpftrace Documentation/bpf/redirect.rst tools/testing/selftests/bpf/progs/test_xdp_attach_fail.c Filling in tech gaps would also help DPP, IDK how much DPP is based or using P4, neither should I have to care, frankly :S
