On 11/07, Quentin Monnet wrote:
2018-11-07 12:32 UTC-0800 ~ Jakub Kicinski jakub.kicinski@netronome.com
On Wed, 7 Nov 2018 20:08:53 +0000, Quentin Monnet wrote:
err = bpf_obj_pin(bpf_program__fd(prog), pinfile);if (err) {p_err("failed to pin program %s",bpf_program__title(prog, false));goto err_close_obj;}I don't have the same opinion as Jakub for pinning :). I was hoping we could also load additional programs (for tail calls) for non-flow_dissector programs. Could this be an occasion to update the code in that direction?
Do you mean having the bpftool construct an array for tail calling automatically when loading an object? Or do a "mass pin" of all programs in an object file?
I'm not convinced about this strategy of auto assembling a tail call array by assuming that a flow dissector object carries programs for protocols in order (apart from the main program which doesn't have to be first, for some reason).
Not constructing the prog array, I don't think this should be the role of bpftool either. Much more a "mass pin", so that you have a link to each program loaded from the object file and can later add them to a prog array map with subsequent calls to bpftool.
I agree, constructing the jmp_table is a bit fragile with all the dependencies on the order of the progs. I'll drop that and will send a v2 that pins all the programs from the obj file instead and offloads jmp_table construction to the user. So the supposed use case would be something like the following:
bpftool prog load bpf_flow.o /sys/fs/bpf/flow type flow_dissector bpftool map update pinned /sys/fs/bpf/flow/jmp_table \ key ... value pinned /sys/fs/bpf/flow/<PROTO>/0 bpftool map update ... bpftool prog attach pinned /sys/fs/bpf/flow/flow_dissector/0 flow_dissector