Is there a limit to how much instances of an eBPF programs the kernel can run simultaneously on several CPUs (similar to the python GIL problem)
In particular can eBPF tc programs work on multiple CPU simultaneously?
How is locking of kernel datastructures done by eBPF when it is running the same code on multiple CPUs?
In particular can eBPF tc programs work on multiple CPU simultaneously?
Yes (see details below).
How is locking of kernel datastructures done by eBPF when it is running the same code on multiple CPUs?
Concurrent accesses to maps in BPF are protected by the RCU mechanism. However, there is currently no way to protect concurrent code in BPF programs themselves. So, for example, a BPF program running on a first core may update a value between the lookup and update calls of the same program running on a second core.
In some cases, to improve performance, you can use per-CPU maps (e.g., per-CPU arrays and per-CPU hashmaps). In that case, the API for lookups, updates, and deletes stays the same, but each core actually has its own copy of the map's values. This means that, for example, if you are incrementing a counter in a map, each core will see its own counter and you'll have to aggregate their values in userspace to get the total counter. Of course, this might not always fit your use case.
