Re: [PATCH net-next v8 00/15] Introducing P4TC

[Edward Cree <ecree.xilinx@gmail.com>]

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.

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.

-ed