Björn Töpel <bjorn.topel@xxxxxxxxx> writes: > 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. Yup, think so - SGTM! :) -Toke
