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.
>
> 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")).
Quentin
