On Wed, Jan 22, 2025 at 1:53 PM Slava Imameev <slava.imameev@xxxxxxxxxxxxxxx> wrote: > > BPF programs designated as dynamically loaded can be loaded and > attached independently after the initial bpf_object loading and > attaching. > > These programs can also be reloaded and reattached multiple times, > enabling more flexible management of a resident BPF program set. > > A key motivation for this feature is to reduce load times for > utilities that include hundreds of BPF programs. When the selection > of a resident BPF program set cannot be determined at the time of > bpf_object loading and attaching, all BPF programs would otherwise > need to be marked as autoload, leading to unnecessary overhead. > This patch addresses that inefficiency. Can you elaborate on why it's impossible to determine which BPF programs should be loaded before BPF object load step? In general, I'm not too excited about these complications, it's error-prone enough with just normal autoload (true/false) logic and various interactions between different features. Adding the third "may be loaded much later" state just doesn't seem worth the complexit. Also, for subsequent submissions, please make sure you have [PATCH bpf-next] subject prefix. > > Signed-off-by: Slava Imameev <slava.imameev@xxxxxxxxxxxxxxx> > --- > tools/lib/bpf/libbpf.c | 144 +++++++++++++++-- > tools/lib/bpf/libbpf.h | 5 +- > tools/lib/bpf/libbpf.map | 2 + > .../selftests/bpf/prog_tests/dynamicload.c | 145 ++++++++++++++++++ > .../selftests/bpf/prog_tests/load_type.c | 61 ++++++++ > .../selftests/bpf/progs/test_dynamicload.c | 31 ++++ > .../selftests/bpf/progs/test_load_type.c | 8 + and let's keep selftests in a separate patch from kernel and/or libbpf changes > 7 files changed, 385 insertions(+), 11 deletions(-) > create mode 100644 tools/testing/selftests/bpf/prog_tests/dynamicload.c > create mode 100644 tools/testing/selftests/bpf/progs/test_dynamicload.c > [...]
