On Tue, Jul 21, 2026 at 5:53 AM Andrew Lunn <[email protected]> wrote: > > On Mon, Jul 20, 2026 at 10:05:33PM +0200, Natalie Vock wrote: > > On 7/19/26 19:58, Taehee Yoo wrote: > > > Add the AMD GCN (gfx9/gfx10) instruction encoder used to build the GPU > > > shaders that knod dispatches, plus a matching disassembler used for > > > debugging the generated code. > > > > Is it really necessary to have a full-on compiler and disassembler in the > > kernel driver? This patch is massive and I'm wondering how much benefit it > > really provides. Is there really no way to move GPU compilation out of the > > kernel, one way or another? Could you get acceptable perf with a static > > shader that interprets BPF programs at runtime? Such a shader can be > > compiled beforehand and just embedded into the kernel - there's prior art > > there with the CWSR trap handler in amdkfd. > > > > In case you really, really need to compile the BPF to native ISA, could you > > still have userspace take care of that in one way or another? > > There was a long and painful discussion about P4, and offloading it to > hardware. The proponents of that wanted to do the compilation stage in > user space to produce a binary blob, but it was hard to prove that the > P4 passed to the kernel for software processing, and the binary blob > passed to the hardware actually where the same. It opened up the path > for closed source P4 where the kernel never got to see the actual P4 > code. So it was not really offload, but kernel bypass. > > So having a compiler in the kernel is probably the correct way to go, > if you want to be friendly to open source. > > The other option is to get the GPU to do the compilation itself, so > you pass BPF byte codes to the GPU and it generates its own native > code. I've no idea if that is possible, but clang can target OpenMP, > so maybe it is possible to move this compiler into the GPU? >
Hi Natalie and Andrew, Thank you both for the review and suggestions. We tried running a BPF interpreter on the GPU using OpenCL in an early prototype. The interpreter overhead dominated because each BPF instruction required many native GPU instructions, so the performance was not practical. Since this was only an early feasibility prototype, we do not have benchmark data suitable for a meaningful comparison. Based on that result, we chose to compile BPF directly into native GPU instructions. Moving compilation to userspace would also raise the problem Andrew described: the kernel could no longer easily establish that the verified BPF program and the submitted GPU binary are equivalent. We have not tried compiling on the GPU itself, but that may be worth investigating separately. The disassembler is only used for debugging the generated GPU instructions and is not required for execution. We can leave it out of the initial series and submit it separately if needed. Regards, Hoyeon Lee > Andrew
