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

[Alexei Starovoitov <ast@plumgrid.com>]

On 5/18/15 2:20 PM, Arnaldo Carvalho de Melo wrote:
> Em Mon, May 18, 2015 at 02:05:35PM -0700, Alexei Starovoitov escreveu:
>> On 5/18/15 1:44 PM, Arnaldo Carvalho de Melo wrote:
>>>
>>> perf record --filter, to pass a filter to tracepoints, if I could
>>> instead of a filter expression pass, say, filter_bpf.o, that would seem
>>> natural for me, i.e. no new option, just an alternative type of filter,
>>> one way more powerful.
>> ...
>>> I'd say keep it in --filter, that noticing it is a bpf object would
>>> dtrt:
>>>
>>>    perf record --filter bpf_thing.o usleep 1
>>>
>>
>> agree. make sense.
>> The only thing is that such bpf program defines both event and filter.
>> Existing --filter applies to --event, whereas this bpf_thing.o does both
>> and likely kprob-ing multiple events underneath.
>> I guess '--filter' still fits. Just need to document it clearly.
>
> Humm, unsure then, because it is not a filter anymore, i.e. it is both a
> filter and event selector :-\
>
> I was thinking more like, hey, for an existing event, i.e. a place in
> the kernel where it will collect something, collect if this filter
> returns true. That would fit the existing --filter semantic.
>
>   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.
May be --bpfobj would be a better flag, since it's a clean slate.
Short version '-b' is also unused :)

> And if that is the case, then what is the difference from a kprobe
> event? I.e. for the existing tooling it wouldn't matter how this event
> was set up, as long as it was available via tracefs, etc. I.e. it would
> be completely similar to a tracepoint, kprobe, uprobe, etc, i.e. first
> set it up, expose its internals via tracefs, no changes to perf.

the main difference that programs are not static as kprobes.
bpf maps, programs need to be dynamically created and loaded and they
will cease to exist as soon as process that holds FDs exits. So it
matches perf_event_open model which is FD based as well.
And that's only filtering like usage. Where 'perf report' facilities
are reused. For 'kernel debugging', 'latency heatmaps' use cases some
new visualizations in perf will be needed. That's where
'perf bpf command' fits.