On 2021-01-20 16:11, Toke Høiland-Jørgensen wrote:
Björn Töpel <bjorn.topel@xxxxxxxxx> writes:
On 2021-01-20 14:25, Björn Töpel wrote:
On 2021-01-20 13:52, Toke Høiland-Jørgensen wrote:
Björn Töpel <bjorn.topel@xxxxxxxxx> writes:
From: Björn Töpel <bjorn.topel@xxxxxxxxx>
Add detection for kernel version, and adapt the BPF program based on
kernel support. This way, users will get the best possible performance
from the BPF program.
Please do explicit feature detection instead of relying on the kernel
version number; some distro kernels are known to have a creative notion
of their own version, which is not really related to the features they
actually support (I'm sure you know which one I'm referring to ;)).
Right. For a *new* helper, like bpf_redirect_xsk, we rely on rejection
from the verifier to detect support. What about "bpf_redirect_map() now
supports passing return value as flags"? Any ideas how to do that in a
robust, non-version number-based scheme?
Just so that I understand this correctly. Red^WSome distro vendors
backport the world, and call that franken kernel, say, 3.10. Is that
interpretation correct? My hope was that wasn't the case. :-(
Yup, indeed. All kernels shipped for the entire lifetime of RHEL8 think
they are v4.18.0... :/
I don't think we're the only ones doing it (there are examples in the
embedded world as well, for instance, and not sure about the other
enterprise distros), but RHEL is probably the most extreme example.
We could patch the version check in the distro-supplied version of
libbpf, of course, but that doesn't help anyone using upstream versions,
and given the prevalence of vendoring libbpf, I fear that going with the
version check will just result in a bad user experience...
Ok! Thanks for clearing that out!
Would it make sense with some kind of BPF-specific "supported
features" mechanism? Something else with a bigger scope (whole
kernel)?
Heh, in my opinion, yeah. Seems like we'll finally get it for XDP, but
for BPF in general the approach has always been probing AFAICT.
For the particular case of arguments to helpers, I suppose the verifier
could technically validate value ranges for flags arguments, say. That
would be nice as an early reject anyway, but I'm not sure if it is
possible to add after-the-fact without breaking existing programs
because the verifier can't prove the argument is within the valid range.
And of course it doesn't help you with compatibility with
already-released kernels.
Hmm, think I have a way forward. I'll use BPF_PROG_TEST_RUN.
If the load fail for the new helper, fallback to bpf_redirect_map(). Use
BPF_PROG_TEST_RUN to make sure that "action via flags" passes.
That should work for you guys as well, right? I'll take a stab at it.
Björn
