On Tue, Jan 21, 2020 at 04:37:31PM +0100, Toke Høiland-Jørgensen wrote: > Alexei Starovoitov <ast@xxxxxxxxxx> writes: > > > The last few month BPF community has been discussing an approach to call > > chaining, since exiting bpt_tail_call() mechanism used in production XDP > > programs has plenty of downsides. The outcome of these discussion was a > > conclusion to implement dynamic re-linking of BPF programs. Where rootlet XDP > > program attached to a netdevice can programmatically define a policy of > > execution of other XDP programs. Such rootlet would be compiled as normal XDP > > program and provide a number of placeholder global functions which later can be > > replaced with future XDP programs. BPF trampoline, function by function > > verification were building blocks towards that goal. The patch 1 is a final > > building block. It introduces dynamic program extensions. A number of > > improvements like more flexible function by function verification and better > > libbpf api will be implemented in future patches. > > This is great, thank you! I'll go play around with it; couldn't spot > anything obvious from eye-balling the code, except that yeah, it does > need a more flexible libbpf api :) > > One thing that's not obvious to me: How can userspace tell which > programs replace which functions after they are loaded? Is this put into > prog_tags in struct bpf_prog_info, or? good point. Would be good to extend bpf_prog_info. Since prog-to-prog connection is unidirectional the bpf_prog_info of extension prog will be able to say which original program it's replacing. bpftool prog show will be able to print all this data. I think fenry/fexit progs would need the same bpf_prog_info extension. attach_prog_id + attach_btf_id would be enough. In the mean time I can try to hack drgn script to do the same.
