From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751255AbaGBH3r (ORCPT ); Wed, 2 Jul 2014 03:29:47 -0400 Received: from mail-wg0-f52.google.com ([74.125.82.52]:54582 "EHLO mail-wg0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750796AbaGBH3q (ORCPT ); Wed, 2 Jul 2014 03:29:46 -0400 MIME-Version: 1.0 In-Reply-To: References: <1403913966-4927-1-git-send-email-ast@plumgrid.com> <1403913966-4927-12-git-send-email-ast@plumgrid.com> <87tx70496q.fsf@sejong.aot.lge.com> Date: Wed, 2 Jul 2014 00:29:44 -0700 Message-ID: Subject: Re: [PATCH RFC net-next 11/14] tracing: allow eBPF programs to be attached to events From: Alexei Starovoitov To: Namhyung Kim Cc: "David S. Miller" , Ingo Molnar , Linus Torvalds , Steven Rostedt , Daniel Borkmann , Chema Gonzalez , Eric Dumazet , Peter Zijlstra , Arnaldo Carvalho de Melo , Jiri Olsa , Thomas Gleixner , "H. Peter Anvin" , Andrew Morton , Kees Cook , Linux API , Network Development , LKML Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jul 1, 2014 at 11:39 PM, Namhyung Kim wrote: > On Wed, Jul 2, 2014 at 3:14 PM, Alexei Starovoitov wrote: >> >> Can manipulate what at compile time? Entry records of tracepoints are >> hard coded based on the event. For verifier it's easier to treat all >> tracepoint events as they received the same 'struct bpf_context' >> of N arguments then the same program can be attached to multiple >> tracepoint events at the same time. > > I was thinking about perf creates a bpf program for filtering some > events like recording kfree_skb if protocol == xx. So perf can > calculate the offset and size of the protocol field and make > appropriate insns for the filter. When I'm saying 'tracing filter' in patch 11/14, I really mean stap/dtrace-like facility for live debugging, where tracing infra plays a key role. At the end the programs are written in C with annotations and perf orchestrates compilation, insertion, attaching, printing results. Your meaning of 'tracing filter' is canonical: a filter that says whether event should be recorded or not. And it makes sense. When perf sees 'protocol==xx' on command line it can generate ebpf program for it. In such case my earlier proposal for replacing predicate tree walker with ebpf programs in kernel becomes obsolete? If I understood correctly, you're proposing to teach perf to generate ebpf programs for existing command line interface and use it instead of predicate tree. This way predicate tree can be removed, right? In such case programs would need to access event records. > Maybe it needs to pass the event format to the verifier somehow then. The integer fields are easy to verify. dynamic_array part is tricky, since 16-bit offset + 16-bit length accessors are very tracing specific. I need to think it through. > Your scenario looks like just calling a bpf program when it hits a > event. It could use event triggering for that purpose IMHO. Sure. Calling ebpf program can be one of even trigger types. On the other side ebpf programs themselves can replace the whole triggering, filtering, recording code. We can have events that do nothing or call ebpf programs. Then programs walk all necessary data structures, store stuff into a maps, etc Just look at amount of events that perf processes. Some of it can be done in kernel by dynamic program.