From: Marat Khalili <qm2k21@gmail.com>
To: Konstantin Ananyev <konstantin.v.ananyev@yandex.ru>,
Konstantin Ananyev <konstantin.ananyev@huawei.com>
Cc: dev@dpdk.org, stephen@networkplumber.org
Subject: Re: [PATCH v2 2/9] bpf: document ethdev callback threading limitations
Date: Sat, 24 Oct 2026 15:10:13 +0100 [thread overview]
Message-ID: <0309fc87-3912-41b1-8b38-7aa581bf07e3@gmail.com> (raw)
In-Reply-To: <e5ff5f2b-de4c-48a7-bc0d-3a7392bb6e1a@yandex.ru>
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.
next prev parent reply other threads:[~2026-10-24 14:10 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-11 18:21 [PATCH 0/9] bpf: clean up and document ethdev callback synchronization Marat Khalili
2026-10-11 18:21 ` [PATCH 1/9] bpf: document packet callback unload sequence Marat Khalili
2026-10-11 18:21 ` [PATCH 2/9] bpf: document ethdev callback threading limitations Marat Khalili
2026-10-11 18:21 ` [PATCH 3/9] bpf: reject Tx callback installation with MT_LOCKFREE Marat Khalili
2026-10-11 18:21 ` [PATCH 4/9] bpf: add callback flag to skip multi-thread check Marat Khalili
2026-10-11 19:48 ` Stephen Hemminger
2026-10-11 20:12 ` Marat Khalili
2026-10-11 18:21 ` [PATCH 5/9] bpf: remove redundant memory barrier on unload Marat Khalili
2026-10-11 19:50 ` Stephen Hemminger
2026-10-11 20:14 ` Marat Khalili
2026-10-11 18:21 ` [PATCH 6/9] bpf: simplify callback inuse tracking to boolean flag Marat Khalili
2026-10-11 19:51 ` Stephen Hemminger
2026-10-11 20:17 ` Marat Khalili
2026-10-11 18:21 ` [PATCH 7/9] bpf: reformat packet callback unload diagram Marat Khalili
2026-10-11 18:21 ` [PATCH 8/9] bpf: use relaxed stores for callback inuse tracking Marat Khalili
2026-10-11 19:52 ` Stephen Hemminger
2026-10-11 20:24 ` Marat Khalili
2026-10-11 18:21 ` [PATCH 9/9] bpf: make callback handle atomic with relaxed access Marat Khalili
2026-10-11 19:54 ` Stephen Hemminger
2026-10-11 20:31 ` Marat Khalili
2026-10-11 20:29 ` [RFC] bpf: fix callback unload with concurrent Tx burst Stephen Hemminger
2026-10-12 21:09 ` [PATCH v2 0/9] bpf: clean up and document ethdev callback synchronization Marat Khalili
2026-10-12 21:09 ` [PATCH v2 1/9] bpf: document packet callback unload sequence Marat Khalili
2026-10-19 20:44 ` Konstantin Ananyev
2026-10-12 21:09 ` [PATCH v2 2/9] bpf: document ethdev callback threading limitations Marat Khalili
2026-10-12 21:44 ` Stephen Hemminger
2026-10-19 21:10 ` Konstantin Ananyev
2026-10-19 23:35 ` Stephen Hemminger
2026-10-20 6:54 ` Konstantin Ananyev
2026-10-24 14:10 ` Marat Khalili [this message]
2026-10-24 20:47 ` Stephen Hemminger
2026-10-25 7:50 ` Konstantin Ananyev
2026-10-12 21:09 ` [PATCH v2 3/9] bpf: reject Tx callback installation with MT_LOCKFREE Marat Khalili
2026-10-19 21:22 ` Konstantin Ananyev
2026-10-19 23:36 ` Stephen Hemminger
2026-10-12 21:09 ` [PATCH v2 4/9] bpf: remove redundant memory barrier on unload Marat Khalili
2026-10-12 21:09 ` [PATCH v2 5/9] bpf: simplify callback inuse tracking to boolean flag Marat Khalili
2026-10-19 20:50 ` Konstantin Ananyev
2026-10-24 14:14 ` Marat Khalili
2026-10-25 7:40 ` Konstantin Ananyev
2026-10-25 10:24 ` Marat Khalili
2026-10-25 10:50 ` Konstantin Ananyev
2026-10-25 11:00 ` Marat Khalili
2026-10-25 12:38 ` Konstantin Ananyev
2026-10-12 21:09 ` [PATCH v2 6/9] bpf: reformat packet callback unload diagram Marat Khalili
2026-10-12 21:09 ` [PATCH v2 7/9] bpf: use relaxed accesses for callback inuse tracking Marat Khalili
2026-10-12 21:09 ` [PATCH v2 8/9] bpf: make callback handle atomic with relaxed access Marat Khalili
2026-10-19 21:27 ` Konstantin Ananyev
2026-10-24 14:24 ` Marat Khalili
2026-10-25 7:44 ` Konstantin Ananyev
2026-10-25 10:14 ` Marat Khalili
2026-10-25 10:53 ` Konstantin Ananyev
2026-10-25 10:57 ` Marat Khalili
2026-10-25 12:40 ` Konstantin Ananyev
2026-10-12 21:09 ` [PATCH v2 9/9] bpf: add callback flag to skip multi-thread check Marat Khalili
2026-10-13 16:55 ` Stephen Hemminger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0309fc87-3912-41b1-8b38-7aa581bf07e3@gmail.com \
--to=qm2k21@gmail.com \
--cc=dev@dpdk.org \
--cc=konstantin.ananyev@huawei.com \
--cc=konstantin.v.ananyev@yandex.ru \
--cc=stephen@networkplumber.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox