Re: BPF Concurrency

Andrii Nakryiko

On Fri, May 22, 2020 at 1:07 PM Kanthi P <Pavuluri.kanthi@...> wrote:


I’ve been reading that hash map’s update element is atomic and also that we can use BPF_XADD to make the entire map update atomically.

But I think that doesn’t guarantee that these updates are thread safe, meaning one cpu core can overwrite other core’s update.

Is there a clean way of keeping them thread safe. Unfortunately I can’t use per-cpu maps as I need global counters.

And spin locks sounds a costly operation. Can you please throw some light?
Stating that spin locks are costly without empirical data seems
premature. What's the scenario? What's the number of CPUs? What's the
level of contention? Under light contention, spin locks in practice
would be almost as fast as atomic increments. Under heavy contention,
spin locks would probably be even better than atomics because they
will not waste as much CPU, as a typical atomic retry loop would.

But basically, depending on your use case (which you should probably
describe to get a better answer), you can either:
- do atomic increment/decrement if you need to update a counter (see
examples in kernel selftests using __sync_fetch_and_add);
- use map with bpf_spin_lock (there are also examples in selftests).



Join { to automatically receive all group messages.