Linux TC eBPF并发问题：内核运行eBPF实例的限制与锁机制

1. Does running eBPF program instances on multiple CPUs have restrictions similar to Python's GIL? #

No, eBPF has no equivalent of Python's Global Interpreter Lock (GIL). Each CPU core can independently run eBPF program instances in parallel—here's why:

• eBPF programs are JIT-compiled into native machine code for the target architecture, so they execute directly on the CPU without relying on a shared interpreter that enforces global locking.
• The kernel schedules eBPF execution independently per CPU. For example, when attached to per-CPU hooks like network receive queues or tracepoints, each CPU runs its own instance of the program to handle local events.

That said, if your eBPF program accesses shared data structures (like global maps), you'll need to handle synchronization manually to avoid race conditions—but this is a data-sharing concern, not a forced global lock like the GIL.

2. Can eBPF TC programs work simultaneously on multiple CPUs? #

Absolutely. TC (Traffic Control) eBPF programs are built to leverage multi-CPU environments efficiently:

• Modern network stacks use per-CPU receive queues (via features like RPS/RFS) to distribute incoming packets across cores. When you attach a TC program to a network interface, it's automatically associated with each CPU's queue.
• Each packet processed on a given CPU will trigger the TC program on that same CPU, allowing parallel processing of traffic across all available cores.
• You can optimize further by using per-CPU maps in your TC program to eliminate cross-CPU synchronization overhead entirely.

3. How does the kernel implement locking for data structures when eBPF runs the same code on multiple CPUs? #

The kernel provides eBPF-specific synchronization primitives, and the implementation depends on how you access your data:

Per-CPU Maps (Lock-Free) #

The most efficient way to avoid locks is using BPF_MAP_TYPE_PERCPU_ARRAY or BPF_MAP_TYPE_PERCPU_HASH maps. These maps create a separate copy of the data for each CPU core:

• Your eBPF program reads/writes only to the copy assigned to the current CPU, so no locks are needed.
• This is ideal for metrics counters, per-CPU statistics, or any data that doesn't require immediate cross-CPU aggregation.

Spin Locks for Shared Global Maps #

If you must use a global map (like BPF_MAP_TYPE_HASH), eBPF supports bpf_spin_lock() and bpf_spin_unlock():

• Spin locks are lightweight, busy-wait locks designed for short critical sections (since eBPF programs have strict execution time limits).
• They work by disabling preemption on the current CPU while holding the lock, ensuring exclusive access to the shared data.

Read-Write Locks #

For read-heavy workloads, you can use bpf_rw_lock_init(), bpf_read_lock(), bpf_read_unlock(), bpf_write_lock(), and bpf_write_unlock():

• These allow multiple readers to access the data simultaneously, but only one writer at a time—perfect for scenarios where reads are far more frequent than writes.

Kernel Internal Data Structures #

If your eBPF program accesses kernel-owned data structures (like struct sk_buff), the kernel already has its own locking mechanisms. You'll need to follow kernel rules—for example, using skb_lock() when modifying a socket buffer—to avoid race conditions.

Importantly, the kernel doesn't automatically add locks to eBPF-accessed data; it's up to you as the developer to choose the right synchronization primitive based on your use case.

内容的提问来源于stack exchange，提问作者Eric