On 8/28/15 12:06 AM, Wang Nan wrote:
his patch adds a new trace event to establish infrastruction for bpf to output data to perf. Userspace perf tools can detect and use this event as using the existing tracepoint events.New bpf trace event entry in debugfs: /sys/kernel/debug/tracing/events/bpf/bpf_output_data Userspace perf tools detect the new tracepoint event as: bpf:bpf_output_data [Tracepoint event] Data in ring-buffer of perf events added to this event will be polled out, sample types and other attributes can be adjusted to those events directly without touching the original kprobe events.
Wang, I have 2nd thoughts on this. I've played with it, but global bpf:bpf_output_data event is limiting. I'd like to use this bpf_output_trace_data() helper for tcp estats gathering, but global collector will prevent other similar bpf programs running in parallel. So as a concept I think it's very useful, but we need a way to select which ring-buffer to output data to. proposal A: Can we use ftrace:instances concept and make bpf_output_trace_data() into that particular trace_pipe ? proposal B: bpf_perf_event_read() model is using nice concept of an array of perf_events. Can we perf_event_open a 'new' event that can be mmaped in user space and bpf_output_trace_data(idx, buf, buf_size) into it. Where 'idx' will be an index of FD from perf_even_open of such new event? Thanks! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
