Re: [PATCH RFC v3 net-next 3/3] samples: bpf: eBPF dropmon example in C

On Wed, Jul 30, 2014 at 10:36 AM, Frank Ch. Eigler [off-list ref] wrote:

quoted

quoted

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:

quoted

[...] 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.

quoted

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.