[...] >>>>> Exactly. Following drawing shows p4 pipeline setup for SW and Hw: >>>>> >>>>> | >>>>> | +--> ebpf engine >>>>> | | >>>>> | | >>>>> | compilerB >>>>> | ^ >>>>> | | >>>>> p4src --> compilerA --> p4ast --TCNL--> cls_p4 --+-> driver -> compilerC >>>>> -> HW >>>>> | >>>>> userspace | kernel >>>>> | >> >> Sorry for jumping into the middle and the delay (plumbers this week). My >> question would be, if the main target is for p4 *offloading* anyway, who >> would use this sw fallback path? Mostly for testing purposes? > > Development and testing purposes, yes. > > >> >> I'm not sure about compilerB here and the complexity that needs to be >> pushed into the kernel along with it. I would assume this would result >> in slower code than what the existing P4 -> eBPF front ends for LLVM >> would generate since it could perform all kind of optimizations there, > > The complexity would be similar to compilerC. For compilerB, > optimizations does not really matter, as it it for testing mainly. > > >> that might not be feasible for doing inside the kernel. Thus, if I'd want >> to do that in sw, I'd just use the existing LLVM facilities instead and >> go via cls_bpf in that case. >> >> What is your compilerA? Is that part of tc in user space? Maybe linked > > It is something that transforms original p4 source to some intermediate > form, easy to be processed by in-kernel compilers. > > >> against LLVM lib, for example? If you really want some sw path, can't tc >> do this transparently from user space instead when it gets a netlink error >> that it cannot get offloaded (and thus switch internally to f_bpf's loader)? > > In real life, user will most probably use p4 for hw programming, but the > sw fallback will be done in bpf directly. In that case, he would use > cls_bfp SKIP_HW > cls_p4 SKIP_SW > > But in order to allow cls_p4 offloading to hw, we need in-kernel > interpreter. That is purpose of compilerB to take agvantage of bpf, but > the in-kernel interpreter could be implemented differently. >
But this is the issue. We openly acknowledge it wont actually be used. We have multiple user space compilers that generate at least half way reasonable ebpf code that is being used in real deployments and works great for testing. This looks like pure overhead to satisfy this hw/sw parity checkbox and I can't see why anyone would use it or even maintain it. Looks like a checkbox and I like to avoid useless work that is likely to bit rot.
