On Fri, Oct 9, 2020 at 12:58 PM Juraj Vijtiuk <juraj.vijtiuk@xxxxxxxxxx> wrote: > > It would be great to hear if anyone has any thoughts on running a set > of BPF programs JITed while other programs are run by the interpreter. > > Something like that would be useful on 32-bit architectures, as the > JIT compiler there doesn't support some instructions, primarily > instructions that work with 64-bit data. As far as I can tell, it is > unlikely that support will be coming soon as it is a general issue for > all 32-bit architectures. Atomic operations like BPF_XADD look > especially problematic regarding support on 32 bit platforms. From > what I managed to see such a conclusion appeared in a few patches > where support for 32-bit JITs was added, for example [0]. > That results in some programs being runnable with BPF JIT enabled, and > some failing during load time, but running successfully without JIT on > 32-bit platforms. > > The only way to run some programs with JIT and some without, that > seems possible right now, is to manually change > /proc/sys/net/core/bpf_jit_enable every time a program is loaded. > Although I've managed to do that and it seems to be working, it seems > pretty hacky and looks like it could cause race conditions if multiple > programs were loaded, especially by independent loaders. I agree, the global file is not flexible enough and can cause problems in production environment. I don't see any reason why we shouldn't allow to decide interpreted vs jitted mode per program during BPF_PROG_LOAD. See kernel/bpf/core.c, bpf_prog's jit_requested field determines whether a program is going to be jitted or not. It should be trivial to allow overriding that during BPF_PROG_LOAD command. We can probably also generalize this to allow to "force-jit" or "force-interpret" by users, which would fail if kernel didn't support requested mode. > > At first glance it seems that if something like this was to be added > to a loader, it would have to either somehow be aware of other BPF > programs being loaded or possibly implement some sort of locking > mechanism which also seems hacky. From what I understand, doing it in > the kernel looks even less promising as bpf_jit_enable is a system > wide setting, and I imagine that changing it to work on a per program > basis would pretty much require a rework of the current design, so > that looks even less promising. > > It looks like the best option right now is to just run everything in > interpreted mode, but I want to make sure that I am not missing > something. If someone has tried doing something similar, it would be > great to know about that. > > Thanks, > Juraj Vijtiuk > > [0] https://lore.kernel.org/netdev/20200305050207.4159-3-luke.r.nels@xxxxxxxxx/
