On Thu, 23 Nov 2023 17:53:42 +0000 Edward Cree wrote: > The kernel doesn't like to trust offload blobs from a userspace compiler, > because it has no way to be sure that what comes out of the compiler > matches the rules/tables/whatever it has in the SW datapath. > It's also a support nightmare because it's basically like each user > compiling their own device firmware. Practically speaking every high speed NIC runs a huge binary blob of FW. First, let's acknowledge that as reality. Second, there is no equivalent for arbitrary packet parsing in the kernel proper. Offload means take something form the host and put it on the device. If there's nothing in the kernel, we can't consider the new functionality an offload. I understand that "we offload SW functionality" is our general policy, but we should remember why this policy is in place, and not automatically jump to the conclusion. > At least normally with device firmware the driver side is talking to > something with narrow/fixed semantics and went through upstream > review, even if the firmware side is still a black box. We should be buildings things which are useful and open (as in extensible by people "from the street"). With that in mind, to me, a more practical approach would be to try to figure out a common and rigid FW interface for expressing the parsing graph. But that's an interface going from the binary blob to the kernel. > Just to prove I'm not playing favourites: this is *also* a problem with > eBPF offloads like Nanotubes, and I'm not convinced we have a viable > solution yet. BPF offloads are actual offloads. Config/state is in the kernel, you need to pop it out to user space, then prove that it's what user intended.
