This group is locked. No changes can be made to the group while it is locked.
question about per_cpu maps
Pablo Alvarez
Dear eBPF community
If I understand correctly, per_cpu maps are meant to avoid threading
issues, and for example the need to call BPF_XADD to keep counters safe.
There is something I am unclear about:
- Is it possible for a BPF program to be preempted by another BPF
program on the same CPU?
If this is the case, it seems that the following scenario could arise:
BPF program 1 on cpu 0 reads a counter and is preempted before
incrementing it
BPF program 2 on cpu 0 reads the same counter, increments it, and finishes
BPF program 1 on cpu 0 increments the counter
At which point both programs would have read the same value for the
counter, with possible problems ensuing.
Is this a valid scenario? Am I missing something about how the per_cpu
maps are intended to be used?
Thanks
Pablo Alvarez
If I understand correctly, per_cpu maps are meant to avoid threading
issues, and for example the need to call BPF_XADD to keep counters safe.
There is something I am unclear about:
- Is it possible for a BPF program to be preempted by another BPF
program on the same CPU?
If this is the case, it seems that the following scenario could arise:
BPF program 1 on cpu 0 reads a counter and is preempted before
incrementing it
BPF program 2 on cpu 0 reads the same counter, increments it, and finishes
BPF program 1 on cpu 0 increments the counter
At which point both programs would have read the same value for the
counter, with possible problems ensuing.
Is this a valid scenario? Am I missing something about how the per_cpu
maps are intended to be used?
Thanks
Pablo Alvarez