Re: [PATCH bpf-next v4 8/9] tools: bpftool: add probes for a network device

[Jesper Dangaard Brouer <brouer@redhat.com>]

On Wed, 16 Jan 2019 14:21:18 +0000
Quentin Monnet <quentin.monnet@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