Re: [RFC PATCH v3 00/37] perf tools: introduce 'perf bpf' command to load eBPF programs.

[Alexei Starovoitov <ast@plumgrid.com>]

On 5/19/15 9:40 AM, Arnaldo Carvalho de Melo wrote:
> Em Wed, May 20, 2015 at 01:04:48AM +0900, Namhyung Kim escreveu:
>> On Tue, May 19, 2015 at 10:44:58AM -0300, Arnaldo Carvalho de Melo wrote:
>>> Em Mon, May 18, 2015 at 02:45:58PM -0700, Alexei Starovoitov escreveu:
>>>> On 5/18/15 2:20 PM, Arnaldo Carvalho de Melo wrote:
>>>>>   perf record --event bpf_thing.o
>>>
>>>>> Looks more natural then, as it is an event that will take place when the
>>>>> filter returns true, and in addition to that, it will come with a bunch
>>>>> of variables, etc.
>>>>
>>>> well, I think --event fits a bit less than --filter ;)
>>>> Both not ideal.
>>>
>>> I thought --event was more suited, as it states what is the event, and
>>> when it should happen, i.e. --filter is about reducing the frequency of
>>> something well defined, i.e. an existing --event.
>>
>> If we go with 'perf record' rather than 'perf bpf record', I agree
>> that --event option is more natural than --filter.  The --event option
>> says that it will record - or enable, at least - a (kprobe) event for
>> bpf programs in it and then do something with it. :)
>>
>> Maybe something like this?
>>
>>    perf record --event bpf:/path/to/object
>
> The syntax maybe one of many, say if it sees a ".o" suffix in the even
> name, look if the provided event name is a file and if this file has the
> ELF header, whatever.

agree. 'bpf:' prefix is redundant.
To me the following syntax is fine:
perf record --event bpf_file.o

In the future it can support automatically:
perf record --event bpf_file.c

Wang, thoughts?

>> Oh, this looks like an interesting approach.. are you saying something
>> like below?
>
> No, those are way too many steps :-)
>
> What 'perf script' does? Right now you can ask for a script to run and
> it will both start 'perf record' with the proper events, and then
> "immediately" consume it, piping the output of the 'record' "script" to
> the consumer, that is 'perf script' itself running an interpreter, perl
> or python.

if you're proposing to do something like:
perf script bpf_file.c
that will do event creation, filtering, aggregation, reporting
and printing results, then it's fine.
This is pretty much what I thought 'perf bpf run' will do.

> I.e. the first part, say, failed-syscalls-record, would be done
> internally, loading the bpf object, etc, the second part would be the
> event massaging, but done in a C subset :-)

not sure that's doable. The task (perf) that loaded the program in the
step one should be still alive when 2nd part is running.
For 'perf bpf run' use case, the whole record/report split is
artificial. There is no need for perf.data.
In my mind 'perf bpf run file.c' suppose to quickly compile .c,
hook into kernel, collect and print something, then Ctrl-C of
'perf bpf run' should automatically stop everything.
No perf.data anywhere. It should be quick single step
tool for live debugging.
At the same time 'perf record --event bpf_file.o' plus generic
'perf report' model works very well as well.
They are different use cases.

I guess I'm saying let's not get too much ahead of ourselves ;)
I think Wang's current patchset is close enough to make
'perf record --event bpf_file.o' to be useful.
Let's take this first step.