[DTrace-devel] [PATCH] Add dt_bpf_map_lookup() function to retrieve values from BPF maps
Kris Van Hees
kris.van.hees at oracle.com
Fri Sep 4 00:27:54 PDT 2020
On Thu, Sep 03, 2020 at 11:01:52PM -0700, Eugene Loh wrote:
> Some context here would be good. E.g., why is this being introduced?
> Maybe that's problematic to answer since the patch that will use this
> will depend on a lot of leg work that must first be set up, but a
> unified patch set would be nice. I won't insist on it, though. So, not
> ideal, but so be it.
There is no need to justify the patch, especially since the purpose is quite
obvious (we're adding dt_bpf_map_lookup() as a function) and it gets used in
the very next patch.
> But maybe at least say why the libbpf/bpf.c function
> bpf_map_lookup_elem() is not being used? Could it be? Are you trying
> to wean us off of libbpf? But then that should be its own patch?
The decision to move away from using libbpf was made a long time ago already
so there isn't really any need to mention that in this patch. That will be
obvious when a patch does remove it.
> But at the very least (looking ahead to the next patch), the movement of
> dt_bpf_map_[lookup|update] in "Implement a 'state' BPF map to
> communicate tracing session state" should be moved into this patch
> rather than introducing the new function here in the "wrong" place only
> to fix its location in the next patch. Just get the placement right the
> first time. As it is, the function being introduced here is backed out
> in the next patch. Just put dt_bpf_map_lookup in the right place here,
> moving dt_bpf_map_update while you're at it. Those gymnastics do not
> need to be in the next patch.
Wow - that's quite a paragraph to essentially just say "shouldn't those
functions be placed in the right place here instead of having the next patch
move them"? To which I would answer: yes - I made a mistake generating the
patch (it should have included that move here).
> On 08/27/2020 11:54 AM, Kris Van Hees wrote:
> > Signed-off-by: Kris Van Hees <kris.van.hees at oracle.com>
> > ---
> > libdtrace/dt_bpf.c | 15 +++++++++++++++
> > libdtrace/dt_bpf.h | 1 +
> > 2 files changed, 16 insertions(+)
> >
> > diff --git a/libdtrace/dt_bpf.c b/libdtrace/dt_bpf.c
> > index d6d05dc8..0531a37e 100644
> > --- a/libdtrace/dt_bpf.c
> > +++ b/libdtrace/dt_bpf.c
> > @@ -185,6 +185,21 @@ dt_bpf_gmap_create(dtrace_hdl_t *dtp)
> > return 0;
> > }
> >
> > +/*
> > + * Load the value for the given key in the map referenced by the given fd.
> > + */
> > +int dt_bpf_map_lookup(int fd, const void *key, void *val)
> > +{
> > + union bpf_attr attr;
> > +
> > + memset(&attr, 0, sizeof(attr));
> > + attr.map_fd = fd;
> > + attr.key = (uint64_t)(unsigned long)key;
> > + attr.value = (uint64_t)(unsigned long)val;
> > +
> > + return bpf(BPF_MAP_LOOKUP_ELEM, &attr);
> > +}
> > +
> > /*
> > * Store the (key, value) pair in the map referenced by the given fd.
> > */
> > diff --git a/libdtrace/dt_bpf.h b/libdtrace/dt_bpf.h
> > index c4a4a99c..e87d4653 100644
> > --- a/libdtrace/dt_bpf.h
> > +++ b/libdtrace/dt_bpf.h
> > @@ -23,6 +23,7 @@ extern int perf_event_open(struct perf_event_attr *attr, pid_t pid, int cpu,
> > extern int bpf(enum bpf_cmd cmd, union bpf_attr *attr);
> >
> > extern int dt_bpf_gmap_create(dtrace_hdl_t *);
> > +extern int dt_bpf_map_lookup(int fd, const void *key, void *val);
> > extern int dt_bpf_map_update(int fd, const void *key, const void *val);
> > extern int dt_bpf_load_progs(dtrace_hdl_t *, uint_t);
> >
>
>
> _______________________________________________
> DTrace-devel mailing list
> DTrace-devel at oss.oracle.com
> https://oss.oracle.com/mailman/listinfo/dtrace-devel
More information about the DTrace-devel
mailing list