diff options
author | Andrii Nakryiko <[email protected]> | 2020-07-21 23:45:55 -0700 |
---|---|---|
committer | Alexei Starovoitov <[email protected]> | 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 <[email protected]>
Signed-off-by: Alexei Starovoitov <[email protected]>
Link: https://lore.kernel.org/bpf/[email protected]
Diffstat (limited to 'tools/testing/selftests/bpf/prog_tests/queue_stack_map.c')
0 files changed, 0 insertions, 0 deletions