Thu, Nov 23, 2023 at 06:53:42PM CET, ecree.xilinx@xxxxxxxxx wrote: >On 23/11/2023 16:30, Jamal Hadi Salim wrote: >> I was hoping not to say anything but my fingers couldnt help themselves: >> So "unoffloadable" means there is a binary blob and this doesnt work >> per your design idea of how it should work? >> Not that it cant be implemented (clearly it has been implemented), it >> is just not how _you_ would implement it? All along I thought this was >> an issue with your hardware. > >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. 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. >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. Just for the record, I'm not aware of anyone suggesting p4 eBPF offload in this thread. > >The only way I can see to handle it is something analogous to proof- > carrying code, where the kernel (driver, since the blob is likely to be > wholly vendor-specific) can inspect the binary blob and verify somehow > that (assuming the HW behaves according to its datasheet) it implements > the same thing that exists in SW. >Or simplify the hardware design enough that the compiler can be small > and tight enough to live in-kernel, but that's often impossible. Yeah, that would solve the offloading problem. From what I'm hearing from multiple sides, not going to happen. > >-ed
