From: Juraj Vijtiuk <juraj.vijtiuk@sartura.hr>
To: bpf <bpf@vger.kernel.org>
Cc: Luka Perkov <luka.perkov@sartura.hr>,
David Marcinkovic <david.marcinkovic@sartura.hr>
Subject: Running JITed and interpreted programs simultaneously
Date: Fri, 9 Oct 2020 20:40:01 +0200 [thread overview]
Message-ID: <CAOjtDRXzkwG84UCUVw0J_WmRt585OhOSjuWbdenYFNFinsSG0Q@mail.gmail.com> (raw)
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.
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@gmail.com/
next reply other threads:[~2020-10-09 18:38 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-09 18:40 Juraj Vijtiuk [this message]
2020-10-13 22:05 ` Running JITed and interpreted programs simultaneously Andrii Nakryiko
2020-10-19 10:20 ` Juraj Vijtiuk
2020-10-19 12:58 ` Daniel Borkmann
2020-10-19 18:26 ` Andrii Nakryiko
2020-10-19 22:02 ` Alexei Starovoitov
2020-10-20 20:56 ` Juraj Vijtiuk
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAOjtDRXzkwG84UCUVw0J_WmRt585OhOSjuWbdenYFNFinsSG0Q@mail.gmail.com \
--to=juraj.vijtiuk@sartura.hr \
--cc=bpf@vger.kernel.org \
--cc=david.marcinkovic@sartura.hr \
--cc=luka.perkov@sartura.hr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).