On 12/08/15 at 09:45pm, Alexei Starovoitov wrote: > definetely not 1, not 2 and hardly 3. > bpf verifier in 2k lines does full code analysis with all branches, > memory accesses and so on, so it's not hard to understand _intent_ > of the program by any HW backend. > I agree with John that it's not trivial to convert bpf program into > parse graph that intel asic understands, but it's not hard either. > fpga based nic/switch can convert a program into parallel gates. > netronom nic can JIT it into their instruction set. > Programmable switch asics can equally understand intent of the > program and convert it into their firmware. > The easiest would be arm-based nics. > In all cases HW will not be able to convert all possible programs, > but it's not a limitation of instruction set. That's why 1 and 2 > above doesn't really apply. > Different explanation of the above: > think of bpf as intermediate representation. When C or some other > language is used to describe what dataplane suppose to do > the compiler generates bpf==IR which is later compiled by hw specific > backend into target. That target can be fpga, asic, npu, etc. > Some backends will be simple and small enough to stay completely > within kernel. Some backends (like fpga) would need to > call_usermodehelper() or similar, since netlist compilation is > tedious and slow process.
Trying to summarize that, the definition of a BPF program in the context of this discussion is: a BPF program of which the driver or firmware/NIC can understand the original intent. Unless the NIC can JIT, this implies reverse engineering the control flow into a declarative model. So if the goal is to make the intent available to the hardware in a format which both the kernel and the hardware can draw the same conclusions from, wouldn't something like P4 + BPF derived from P4 be a possibly better fit? There is discussion on stateful P4 processing now. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
