On Tue, Jun 08, 2021 at 08:17:00PM +0200, Jiri Olsa wrote: > On Tue, Jun 08, 2021 at 08:42:32AM -0700, Alexei Starovoitov wrote: > > On Sat, Jun 5, 2021 at 4:11 AM Jiri Olsa <jolsa@xxxxxxxxxx> wrote: > > > > > > Adding support to attach multiple functions to tracing program > > > by using the link_create/link_update interface. > > > > > > Adding multi_btf_ids/multi_btf_ids_cnt pair to link_create struct > > > API, that define array of functions btf ids that will be attached > > > to prog_fd. > > > > > > The prog_fd needs to be multi prog tracing program (BPF_F_MULTI_FUNC). > > > > > > The new link_create interface creates new BPF_LINK_TYPE_TRACING_MULTI > > > link type, which creates separate bpf_trampoline and registers it > > > as direct function for all specified btf ids. > > > > > > The new bpf_trampoline is out of scope (bpf_trampoline_lookup) of > > > standard trampolines, so all registered functions need to be free > > > of direct functions, otherwise the link fails. > > > > Overall the api makes sense to me. > > The restriction of multi vs non-multi is too severe though. > > The multi trampoline can serve normal fentry/fexit too. > > so multi trampoline gets called from all the registered functions, > so there would need to be filter for specific ip before calling the > standard program.. single cmp/jnz might not be that bad, I'll check You mean reusing the same multi trampoline for all IPs and regenerating it with a bunch of cmp/jnz checks? There should be a better way to scale. Maybe clone multi trampoline instead? IPs[1-10] will point to multi. IP[11] will point to a clone of multi that serves multi prog and fentry/fexit progs specific for that IP.
