Re:P4: Open-Source Programming Language for Protocol-Indepen...
by rektide on Wednesday June 23, 2021 @11:46PM
(#27613751)
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.
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.
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.