[PATCH v2 2/9] bpf: document ethdev callback threading limitations

Konstantin Ananyev konstantin.v.ananyev at yandex.ru
Sun Oct 25 08:50:31 CET 2026




>
> On 19/10/2026 22:10, Konstantin Ananyev wrote:
>>> Document the data plane limitation in the file docstring of
>>> rte_bpf_ethdev.h: packet callback execution expects only one
>>> thread per port/queue pair at a time, making concurrent bursts
>>> (such as with RTE_ETH_TX_OFFLOAD_MT_LOCKFREE, shared RX queues,
>>> or multi-threaded software PMDs) unsupported.
>> Not sure what do you mean by:
>> 'shared RX queues' and 'multi-threaded software PMDs'. Can you 
>> probably clarify?
>
> I mean any hypothetical solutions that call rx/tx burst concurrently 
> from multiple threads or processes. To avoid confusion, will just 
> leave only an RTE_ETH_TX_OFFLOAD_MT_LOCKFREE example in the next version.
>
>
>>> diff --git a/lib/bpf/rte_bpf_ethdev.h b/lib/bpf/rte_bpf_ethdev.h
>>> index 686fda8d94..cf3b4048f0 100644
>>> --- a/lib/bpf/rte_bpf_ethdev.h
>>> +++ b/lib/bpf/rte_bpf_ethdev.h
>>> @@ -10,8 +10,12 @@
>>>    *
>>>    * API to install BPF filter as RX/TX callbacks for eth devices.
>>>    * Note that right now:
>>> - * - it is not MT safe, i.e. it is not allowed to do load/unload 
>>> for the
>>> - *   same port/queue from different threads in parallel.
>>> + * - in the data plane, it expects only one thread per port/queue 
>>> pair at a time.
>>> + *   Calling RX/TX burst functions concurrently on the same queue 
>>> (e.g. when using
>>> + *   RTE_ETH_TX_OFFLOAD_MT_LOCKFREE, shared RX queues, or 
>>> multi-threaded
>>> + *   software PMDs) is not supported.
>>> + * - in the control plane, it is not MT safe, i.e. it is not 
>>> allowed to do
>>> + *   load/unload for the same port/queue from different threads in 
>>> parallel.
>> AFAIK, all CP ethdev API is not MT-safe.
>> Not sure there is a reason to put it here again.
>> If you believe it is, then probably worth to mention that it follows 
>> ethdev CP API convention.
>
> I actually think the CP is safe now due to the spinlock, but I was 
> wary of removing this pre-existing phrase. Since you support removing 
> it, I will remove it.

Ah yes, I even forgot that there is a spin-lock :)
Then yes, CP is MT safe too.





More information about the dev mailing list