On 11/07, Quentin Monnet wrote:
> 2018-11-07 12:32 UTC-0800 ~ Jakub Kicinski <jakub.kicinski@xxxxxxxxxxxxx>
> > 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
