On Wed, 16 Jan 2019 14:21:18 +0000
Quentin Monnet <quentin.mon...@netronome.com> wrote:
> bpftool gained support for probing the current system in order to see
> what program and map types, and what helpers are available on that
> system. This patch adds the possibility to pass an interface index to
> libbpf (and hence to the kernel) when trying to load the programs or to
> create the maps, in order to see what items a given network device can
> support.
>
> A new keyword "dev <ifname>" can be used as an alternative to "kernel"
> to indicate that the given device should be tested. If no target ("dev"
> or "kernel") is specified bpftool defaults to probing the kernel.
>
> Sample output:
>
> # bpftool -p feature probe dev lo
> {
> "syscall_config": {
> "have_bpf_syscall": true
> },
> "program_types": {
> "have_sched_cls_prog_type": false,
> "have_xdp_prog_type": false
> },
> ...
> }
>
> As the target is a network device, /proc/ parameters and kernel
> configuration are NOT dumped. Availability of the bpf() syscall is
> still probed, so we can return early if that syscall is not usable
> (since there is no point in attempting the remaining probes in this
> case).
>
> Among the program types, only the ones that can be offloaded are probed.
Do you imagine we (later) can use this probe dev interface for probing
e.g. what XDP actions a given driver supports? and e.g. if driver have
data_meta support.
Use-case: I've very interested in finding a solution for probing for
XDP_REDIRECT support, as Suricata need this information, so it can
choose to fallback to offloading elefant flows via TC-cls_bpf (if
XDP_REDIRECT is not avail).
> All map types are probed, as there is no specific rule telling which one
> could or could not be supported by a device in the future. All helpers
> are probed (but only for offload-able program types).
>
> Caveat: as bpftool does not attempt to attach programs to the device at
> the moment, probes do not entirely reflect what the device accepts:
> typically, for Netronome's nfp, results will announce that TC cls
> offload is available even if support has been deactivated (with e.g.
> ethtool -K eth1 hw-tc-offload off).
>
> v2:
> - All helpers are probed, whereas previous version would only probe the
> ones compatible with an offload-able program type. This is because we
> do not keep a default compatible program type for each helper anymore.
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
