diff options
author | Andrii Nakryiko <andriin@fb.com> | 2020-07-21 23:45:55 -0700 |
---|---|---|
committer | Alexei Starovoitov <ast@kernel.org> | 2020-07-25 20:37:02 -0700 |
commit | 7f0a838254bdd9114b978ef2541a6ce330307e9e (patch) | |
tree | 91a5c1e3ae5eb01a82dca026224a4a5e2190ca71 /tools/testing/selftests/bpf/prog_tests/queue_stack_map.c | |
parent | 6cc7d1e8e9e06d45f9d1a39a5f465288d7cd8f9a (diff) |
bpf, xdp: Maintain info on attached XDP BPF programs in net_device
Instead of delegating to drivers, maintain information about which BPF
programs are attached in which XDP modes (generic/skb, driver, or hardware)
locally in net_device. This effectively obsoletes XDP_QUERY_PROG command.
Such re-organization simplifies existing code already. But it also allows to
further add bpf_link-based XDP attachments without drivers having to know
about any of this at all, which seems like a good setup.
XDP_SETUP_PROG/XDP_SETUP_PROG_HW are just low-level commands to driver to
install/uninstall active BPF program. All the higher-level concerns about
prog/link interaction will be contained within generic driver-agnostic logic.
All the XDP_QUERY_PROG calls to driver in dev_xdp_uninstall() were removed.
It's not clear for me why dev_xdp_uninstall() were passing previous prog_flags
when resetting installed programs. That seems unnecessary, plus most drivers
don't populate prog_flags anyways. Having XDP_SETUP_PROG vs XDP_SETUP_PROG_HW
should be enough of an indicator of what is required of driver to correctly
reset active BPF program. dev_xdp_uninstall() is also generalized as an
iteration over all three supported mode.
Signed-off-by: Andrii Nakryiko <andriin@fb.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Link: https://lore.kernel.org/bpf/20200722064603.3350758-3-andriin@fb.com
Diffstat (limited to 'tools/testing/selftests/bpf/prog_tests/queue_stack_map.c')
0 files changed, 0 insertions, 0 deletions