Date:   Mon, 11 Mar 2019 23:03:10 -0700
From:   Brendan Gregg <bgregg@...flix.com>
To:     Kris Van Hees <kris.van.hees@...cle.com>
Cc:     Alexei Starovoitov <alexei.starovoitov@...il.com>,
        netdev@...r.kernel.org, bpf@...r.kernel.org,
        Daniel Borkmann <daniel@...earbox.net>
Subject: Re: [PATCH 0/2] bpf: context casting for tail call and gtrace prog type

On Mon, Mar 11, 2019 at 8:24 PM Kris Van Hees <kris.van.hees@...cle.com> wrote:
>
> On Mon, Mar 11, 2019 at 06:29:55PM -0700, Brendan Gregg wrote:
> > On Mon, Mar 11, 2019 at 7:21 AM Kris Van Hees <kris.van.hees@...cle.com> wrote:
> > >
> > > On Thu, Mar 07, 2019 at 01:30:37PM -0800, Alexei Starovoitov wrote:
> > > > On Tue, Mar 05, 2019 at 09:03:57PM -0500, Kris Van Hees wrote:
> > [...]
> > > > > But being able to do things like this without
> > > > > needing to touch the context of any other BPF program type is a great benefit
> > > > > to offer tracing tools, as far as I see it.
> > > >
> > > > I still don't understand what you're referring to by 'things like this'
> > > > that somehow will be possible in the future, but not possible today.
> > > > Could you please give concrete example?
> > >
> > > My apologies for not being clear.  I am referring to the features of the
> > > gtrace context in terms of containing task information, and output buffers
> > > to be used in BPF programs triggered from various probe sources (kprobe,
> > > tracepoints, ...)  I would not want to suggest making changes to all the
> > > different program contexts in order to support tracing needs because that
> > > would be wrong.  Doing it in a central place makes it a lot easier to maintain
> > > without impacting other program types, etc.
> > >
> > > Of course, yes, bpf_probe_read() and bpf_perf_event_output() can be used
> > > to implement a lot of what existing tracing tools like DTrace can do, if you
> > > write them based on that.  One limitations I am obviously working with is
> > > that DTrace already exists and has existed for a long time.  And while it is
> > > 100% available as open source, it involves a pretty involved set of patches to
> > > be applied to the kernel to be able to use it which is just not ideal.  Hence
> > > the goal to make it available by re-using as much of the existing features in
> > > Linux as possible, while still maintaining the same level of functionality in
> > > DTrace.  That means we need to fill the gaps - and from where I am sitting,
> > > the ways to do that might as well be of use to others (if they want to).
> > >
> > > If phrasing things in the context of DTrace would make the conversation easier
> > > I certainly don;t mind doing that, but I really don't want to limit my patches
> > > to supporting just DTrace (even if right now it might be the only tracer using
> > > it).
> >
> > As a concrete example, can you point to one of my own published DTrace
> > tools that BPF can't do? These were created to solve many real
> > production issues, and make good use cases. I've been porting them
> > over to BPF (bcc and bpftrace) without too much problem, and I can't
> > think of a single one that I couldn't port over today.
>
> I am unclear how pointing at one of your published DTrace tools would
> contribute to this discussion.  Surely the scope of use cases is not limited
> to the DTrace scripts you published?
>
> Either way, one of the features that I make use of is speculative tracing.

The subject was a concrete example. I don't think I used speculative
tracing in any of my scripts. Can you pick a better example of
something BPF can't do?

> And yes, even that could be handled with some ugly workarounds but my intent
> is to implement things in a more clean way rather than depending on a bunch
> of workarounds to make it somewhat work.
>
> > There's a few minor things that I'm currently doing workarounds for,
> > like ppid, but that should be satisfied with a few more helpers. And
> > if it's really niche, then BTF sounds like a good solution.
>
> Of course, we can always add more helpers to get to information that is
> needed, but that is hardly a practical solution in the long run, and at
> Plumbers 2019 it was already indicated that just adding helpers to get to
> more information about tasks is not the route people want to take.
>
> > If your ultimate goal is to have a command called "dtrace" that runs D
> > programs, to support your existing users, then I'd add a lex/yacc pair
> > to bpftrace and have it emit a dtrace binary.
>
> My goal is not to have a command called dtarce that somehow simply provides
> some form of support for dtrace scripts in some legacy support model.  My
> goal is to make DTrace available on Linux based on existing kernel features
> (and contirbuting extra features where needed, in a collaborative manner).

If bpftrace builds a dtrace binary that runs D code, then you just did
make DTrace available on Linux.

And without changing the kernel.

Brendan

-- 
Brendan Gregg, Senior Performance Architect, Netflix

Powered by blists - more mailing lists