[DTrace-devel] BPF_F_CURRENT_CPU

Kris Van Hees kris.van.hees at oracle.com
Fri May 29 10:10:50 PDT 2020


On Wed, May 13, 2020 at 07:24:16AM -0700, Eugene Loh wrote:
> On 05/13/2020 12:01 AM, Kris Van Hees wrote:
> 
> > On Wed, May 13, 2020 at 01:40:19AM -0400, Kris Van Hees wrote:
> >> Cc: to the dtrace-devel list because it is an important discussion.
> >>
> >> On Tue, May 12, 2020 at 06:53:31PM -0700, Eugene Loh wrote:
> >>> In our BPF function prologue, we call a BPF helper function to get the
> >>> current CPU, then convert to 32-bit, then store to the stack.  In the
> >>> epilogue, we retrieve that value to pass to bpf_perf_event_output().
> >>>
> >>> Wouldn't it be simpler just to pass BPF_F_CURRENT_CPU to
> >>> bpf_perf_event_output()?  Or will we want the current CPU on the stack
> >>> anyhow for other reasons (e.g., built-in variable)?
> >> Yes, you are right.  When I wrote that code originally, I had more uses for
> >> the current cpu index (e.g. obtaining scratch memory to construct the output
> >> record) and indeed inlined resolving of built-in variables.  And since I had
> >> it anyway I never even looked to see if there was a mode for
> >> bpf_perf_event_output() to output to the buffer for the current cpu without
> >> needing to explicitly specify it.
> >>
> >> Since you found this convenient way to not needing to know the cpu index and
> >> since we actually do not have any other need for it anymore (the builtin
> >> variable need to be handled different anyway because it provides a struct of
> >> data rather than just the cpu index), it would be a good idea to rework that
> >> code to no longer retrieve and store the cpu index.  That also frees up a
> >> little bit of space in the dt_bpf_context.
> > Correcting myself here...  the cpu index is not stored in dt_bpf_context,
> > but is (as you mention) stored on the stack.  It is part of the dt_program
> > stack frame layout, so it can get dropped from there.
> >
> >> Do you want to tackle that reworking?
> Sure.  I'm happy to.

Actually, I had to make some other changes in this code (well, more like a
pretty significant rewrite) so I merged this change into it already.  See my
upcoming patch concerning using builtin variables in a predicate yielding the
program getting rejected by the BPF verifier.

	Kris



More information about the DTrace-devel mailing list