bpf, xdp: Maintain info on attached XDP BPF programs in net_device
authorAndrii Nakryiko <andriin@fb.com>
Wed, 22 Jul 2020 06:45:55 +0000 (23:45 -0700)
committerAlexei Starovoitov <ast@kernel.org>
Sun, 26 Jul 2020 03:37:02 +0000 (20:37 -0700)
commit7f0a838254bdd9114b978ef2541a6ce330307e9e
tree91a5c1e3ae5eb01a82dca026224a4a5e2190ca71
parent6cc7d1e8e9e06d45f9d1a39a5f465288d7cd8f9a
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
include/linux/netdevice.h
net/core/dev.c
net/core/rtnetlink.c