Hi Quentin,
Thanks for your feedback.
On 2022-02-16 11:47:33 +0000, Quentin Monnet wrote:
> 2022-02-16 11:37 UTC+0100 ~ Niklas Söderlund <niklas.soderlund@xxxxxxxxxxxx>
> > Hi Quentin and Andrii,
> >
> > Sorry for late reply.
> >
> > On 2022-02-03 10:24:57 +0000, Quentin Monnet wrote:
> >> Thanks for the Cc. This feature was added for Netronome's SmartNICs
> >> and I don't work with them anymore, so no objection from me (if
> >> anything, that's one more incentive to finalise the new versioning
> >> scheme and have this change under a new major version number!).
> >>
> >> +Cc Simon, David: Hi! If you folks are still using bpftool to probe
> >> eBPF-related features supported by the NICs, we'll have to move the
> >> probes to bpftool.
>
> (I'm realising we forgot to remove the documentation for the "dev NAME"
> option from the documentation, by the way.)
>
> >
> > We do use this feature and it is something we would like to keep.
> >
> > Do I understand the situation correctly that in order to keep the
> > functionality in bpftool the functionality of bpf_probe_prog_type(),
> > bpf_probe_map_type() and bpf_probe_helper() needs to me moved from
> > libbpf to bpftool and used if probing an NIC's features (ifindex
> > provided) while using the new libbpf functions if not? And the reason
> > for this being that libbpf going forward will not support probing of NIC
> > features?
>
> This is correct. Given that the SmartNICs do not support as many
> features as the kernel, it should be simpler versions of the probes in
> bpftool, dedicated to probing the NIC; for probing the system, it should
> keep using libbpf's probes which have a better chance to remain up-to-date.
I agree, I will see what I can do. If you submit a patch to update the
documentation in-between could you please CC me so I can restore it
together with the feature later on.
>
> >
> > Is this something that can be added to this series as to avoid a release
> > where this feature is missing?
> >
>
> This series has already been merged into bpf-next (this is commit
> 1a56c18e6c2e). I'm afraid there will be a bpftool version without the
> feature, because we just updated and bumped bpftool's version number on
> top of that :/ (9910a74d6ebf ("bpftool: Update versioning scheme, align
> on libbpf's version number")).
Do you think it would make sens to add a Fixes tag to a patch restoring
the feature so in case it miss v5.18 it can be backported easily?
>
> Quentin
--
Regards,
Niklas Söderlund
