summaryrefslogtreecommitdiffstats
path: root/tools/bpf/bpf_exp.l
diff options
context:
space:
mode:
authorQuentin Monnet <quentin.monnet@netronome.com>2019-01-17 15:27:57 +0000
committerAlexei Starovoitov <ast@kernel.org>2019-01-22 22:15:40 -0800
commitf9499fedf28547b496066b65de9180eaf3a7dc50 (patch)
tree7b7bc8531772b316434b8f78cad55371a8ef6960 /tools/bpf/bpf_exp.l
parentd267cff46753b0e8b2f169ff4a3f1bb40c2387a8 (diff)
downloadlinux-stable-f9499fedf28547b496066b65de9180eaf3a7dc50.tar.gz
linux-stable-f9499fedf28547b496066b65de9180eaf3a7dc50.tar.bz2
linux-stable-f9499fedf28547b496066b65de9180eaf3a7dc50.zip
tools: bpftool: add probes for a network device
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. 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. Signed-off-by: Quentin Monnet <quentin.monnet@netronome.com> Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com> Reviewed-by: Stanislav Fomichev <sdf@google.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Diffstat (limited to 'tools/bpf/bpf_exp.l')
0 files changed, 0 insertions, 0 deletions