Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755357AbaG3RRW (ORCPT ); Wed, 30 Jul 2014 13:17:22 -0400 Received: from mail-wi0-f174.google.com ([209.85.212.174]:38647 "EHLO mail-wi0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754454AbaG3RRV (ORCPT ); Wed, 30 Jul 2014 13:17:21 -0400 MIME-Version: 1.0 In-Reply-To: References: <1406000723-4872-1-git-send-email-ast@plumgrid.com> <1406000723-4872-4-git-send-email-ast@plumgrid.com> Date: Wed, 30 Jul 2014 10:17:17 -0700 Message-ID: Subject: Re: [PATCH RFC v3 net-next 3/3] samples: bpf: eBPF dropmon example in C From: Alexei Starovoitov To: "Frank Ch. Eigler" Cc: "David S. Miller" , Ingo Molnar , Linus Torvalds , Andy Lutomirski , 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 Wed, Jul 30, 2014 at 8:45 AM, Frank Ch. Eigler wrote: > For the record, this is not entirely accurate as to dtrace. dtrace > delegates aggregation and most reporting to userspace. Also, > systemtap is "short and deterministic" even for aggregations & nice > graphs, but since it limits its storage & cpu consumption, its > arrays/reports cannot get super large. My understanding of systemtap is that the whole .stp script is converted to C, compiled as .ko and loaded, so all map walking and prints are happening in the kernel. Similarly for ktap which has special functions in kernel to print histograms. I thought dtrace printf are also happening from the kernel. What is the trick they use to know which pieces of dtrace script should be run in user space? In ebpf examples there are two C files: one for kernel with ebpf isa and one for userspace as native. I thought about combining them, but couldn't figure out a clean way of doing it. >> [...] >> +SEC("events/skb/kfree_skb") >> +int bpf_prog2(struct bpf_context *ctx) >> +{ >> +[...] >> + value = bpf_map_lookup_elem(&my_map, &loc); >> + if (value) >> + (*(long *) value) += 1; >> + else >> + bpf_map_update_elem(&my_map, &loc, &init_val); >> + return 0; >> +} > > What kind of locking/serialization is provided by the ebpf runtime > over shared variables such as my_map? it's traditional rcu scheme. Programs are running under rcu_read_lock(), so that bpf_map_lookup_elem() can return pointer to map value which won't disappear while program is running. In-kernel map implementation needs to use rcu style to match ebpf program assumptions. map implementation is enforcing the limit to the number of elements. I didn't post 'array' type of map yet. bpf_map_lookup in this implementation will just return 'base + index' pointer. Regardless of type of map the same ebpf program running on different cpus may lookup the same 'key' and receive the same map value pointer. In such case concurrent write access to map value can be done with bpf_xadd instruction, though using normal read/write is also allowed. In some cases the speed of racy var++ is preferred over 'lock xadd'. There are no lock/unlock function helpers available to ebpf programs, since program may terminate early with div by zero for example, so in-kernel lock helper implementation would be complicated and slow. It's possible to do, but for the use cases so far there is no need. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/