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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.