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

Marat Khalili qm2k21 at gmail.com
Sat Oct 24 16:10:13 CEST 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.



More information about the dev mailing list