Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755659AbaG3Sx6 (ORCPT ); Wed, 30 Jul 2014 14:53:58 -0400 Received: from mail-wg0-f44.google.com ([74.125.82.44]:40728 "EHLO mail-wg0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755499AbaG3Sx4 (ORCPT ); Wed, 30 Jul 2014 14:53:56 -0400 MIME-Version: 1.0 In-Reply-To: <20140730173638.GB8745@redhat.com> References: <1406000723-4872-1-git-send-email-ast@plumgrid.com> <1406000723-4872-4-git-send-email-ast@plumgrid.com> <20140730173638.GB8745@redhat.com> Date: Wed, 30 Jul 2014 11:53:54 -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 10:36 AM, Frank Ch. Eigler wrote: >> > What kind of locking/serialization is provided by the ebpf runtime >> > over shared variables such as my_map? >> >> it's traditional rcu scheme. > > OK, that protects the table structure, but: > >> [...] 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'. > > ... so concurrency control over shared values is left up to the > programmer. yes. It has to be flexible and fast. One of our main use cases is network analytics where a lot of packets are going through ebpf programs, so every cycle counts. Mandatory locks in critical path are not acceptable. If we add locks they will be optional. >> 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. > > OK, I hope that works out. I've been told that dtrace does something > similiar (!) by eschewing protection on global variables such as > strings. In their case it's less bad than it sounds because they are > used to offloading computation to userspace or to store only > thread-local state, and accept the corollary limitations on control. interesting. btw, things like global variables, per-cpu storage are potential ebpf features. So far they're 'nice to have' instead of 'mandatory'. The maps are powerful enough to do the same: Global storage is map of one element. Per-cpu storage is map of num_cpu elements. -- 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/