* RE: [PATCH 4/7] app/test/mempool_perf: drop constant-values replay
From: Morten Brørup @ 2026-06-01 13:22 UTC (permalink / raw)
To: Andrew Rybchenko, Stephen Hemminger, dev
In-Reply-To: <1047eaf3-f41e-49b9-a4cf-0eb7d46dc6c6@oktetlabs.ru>
> From: Andrew Rybchenko [mailto:andrew.rybchenko@oktetlabs.ru]
> Sent: Monday, 1 June 2026 10.35
>
> On 5/29/26 8:10 PM, Stephen Hemminger wrote:
> > The second nested matrix replays each (n_get_bulk == n_put_bulk)
> > point with use_constant_values=1 to exercise the compile-time
> > constant bulk-size paths in test_loop(). This roughly doubles the
> > work for the get/put diagonal at every n_keep without adding new
> > signal: the cycles/op result for a constant bulk is interesting in
> > isolated inlining studies, not in routine regression sweeps.
> >
> > Drop the replay. The use_constant_values switch and its branches
> > in test_loop() are retained for now since they are exercised by
> > hand in any local benchmarking.
> >
> > Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
>
> As far as I can see you delete the only place where use_constant_values
> is set to 1. It looks suspicious and basically preserves dead code.
> Since Morten added the code, the patch should wait for his approval.
Having used the mempool perf test extensively myself, I agree that it is painfully slow.
Mempools are very often used with constant request sizes, so testing their performance remains relevant for regression sweeps too.
NAK to this change.
Maybe the testing of constant values could be reduced by using a subset of the non-constant mix of values.
>
> > ---
> > app/test/test_mempool_perf.c | 8 --------
> > 1 file changed, 8 deletions(-)
> >
> > diff --git a/app/test/test_mempool_perf.c
> b/app/test/test_mempool_perf.c
> > index 19591ad0c9..dd2f0bbaca 100644
> > --- a/app/test/test_mempool_perf.c
> > +++ b/app/test/test_mempool_perf.c
> > @@ -423,14 +423,6 @@ do_one_mempool_test(struct rte_mempool *mp,
> unsigned int cores, int external_cac
> > ret = launch_cores(mp, cores);
> > if (ret < 0)
> > return -1;
> > -
> > - /* replay test with constant values */
> > - if (n_get_bulk == n_put_bulk) {
> > - use_constant_values = 1;
> > - ret = launch_cores(mp, cores);
> > - if (ret < 0)
> > - return -1;
> > - }
> > }
> > }
> > }
^ permalink raw reply
* Re: [PATCH] net: fix GTP Tunnel parse out-of-bounds read
From: Thomas Monjalon @ 2026-06-01 12:59 UTC (permalink / raw)
To: dev, Andrew Rybchenko, Bruce Richardson, Jerin Jacob,
Hemant Agrawal
Cc: Stephen Hemminger, stable, Jie Hai
In-Reply-To: <20260409161556.141251-1-stephen@networkplumber.org>
Any comment about this fix?
09/04/2026 18:15, Stephen Hemminger:
> If packet is fragmented across multiple mbufs or the packet
> has only GTP header the code would reference outside
> the incoming mbuf.
>
> Send GTP packet:
> - Valid GTP header (8 bytes)
> - msg_type = 0xff
> - e=1, s=1, pn=1 (sets gtp_len = 12)
> - Total packet size = 10 bytes
>
> Read at gh + 12 accesses 2 bytes beyond packet end.
>
> The fix is to use rte_pktmbuf_read in a manner similar
> to the read of the GTP header.
>
> Fixes: 64ed7f854cf4 ("net: add tunnel packet type parsing")
> Cc: stable@dpdk.org
>
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> ---
> lib/net/rte_net.c | 15 ++++++++++-----
> 1 file changed, 10 insertions(+), 5 deletions(-)
>
> diff --git a/lib/net/rte_net.c b/lib/net/rte_net.c
> index 458b4814a9..da4018437b 100644
> --- a/lib/net/rte_net.c
> +++ b/lib/net/rte_net.c
> @@ -219,8 +219,7 @@ ptype_tunnel_with_udp(uint16_t *proto, const struct rte_mbuf *m,
> case RTE_GTPU_UDP_PORT: {
> const struct rte_gtp_hdr *gh;
> struct rte_gtp_hdr gh_copy;
> - uint8_t gtp_len;
> - uint8_t ip_ver;
> + uint32_t gtp_len;
> gh = rte_pktmbuf_read(m, *off, sizeof(*gh), &gh_copy);
> if (unlikely(gh == NULL))
> return 0;
> @@ -231,9 +230,16 @@ ptype_tunnel_with_udp(uint16_t *proto, const struct rte_mbuf *m,
> * Check message type. If message type is 0xff, it is
> * a GTP data packet. If not, it is a GTP control packet
> */
> + *off += gtp_len;
> if (gh->msg_type == 0xff) {
> - ip_ver = *(const uint8_t *)((const char *)gh + gtp_len);
> - ip_ver = (ip_ver) & 0xf0;
> + const uint8_t *l3_hdr;
> + uint8_t l3_copy, ip_ver;
> +
> + l3_hdr = rte_pktmbuf_read(m, *off, sizeof(*l3_hdr), &l3_copy);
> + if (unlikely(l3_hdr == NULL))
> + return 0;
> +
> + ip_ver = *l3_hdr & 0xf0;
> if (ip_ver == RTE_GTP_TYPE_IPV4)
> *proto = rte_cpu_to_be_16(RTE_ETHER_TYPE_IPV4);
> else if (ip_ver == RTE_GTP_TYPE_IPV6)
> @@ -243,7 +249,6 @@ ptype_tunnel_with_udp(uint16_t *proto, const struct rte_mbuf *m,
> } else {
> *proto = 0;
> }
> - *off += gtp_len;
> hdr_lens->inner_l2_len = gtp_len + sizeof(struct rte_udp_hdr);
> hdr_lens->tunnel_len = gtp_len;
> if (port_no == RTE_GTPC_UDP_PORT)
>
^ permalink raw reply
* RE: [PATCH 5/7] app/test/mempool_perf: scale down for high core counts
From: Morten Brørup @ 2026-06-01 12:58 UTC (permalink / raw)
To: Stephen Hemminger, Andrew Rybchenko, dev
In-Reply-To: <20260529171417.526892-6-stephen@networkplumber.org>
> From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> Sent: Friday, 29 May 2026 19.11
>
> On a 32-core system the test matrix runs the cartesian product of
> 4 mempools, 3 core-count configurations and ~340 (n_keep, bulk)
> points at TIME_S=1 second each: about 67 minutes total, well past
> the 10 minute perf-test timeout.
>
> Two reductions, no loss of meaningful signal:
>
> 1. Per-point duration: 1 second -> 200 ms. Each point currently
> collects 10^5-10^6 mempool ops; 200 ms still yields >10^4
> samples, well above the noise floor for a cycles-per-op average.
Ack to this.
>
> 2. Matrix trim: drop adjacent bulk and n_keep points that don't
> produce regime changes. Retained set covers the boundaries
> that matter: 1, 4, cache-line burst (8), typical packet burst
> (32) and cache size (RTE_MEMPOOL_CACHE_MAX_SIZE = 512) for bulk;
> 32 (fits in cache), 512 (= cache size) and 32768 (far exceeds
> cache) for n_keep.
My mempool optimization patch [1] introduces a bounce buffer limit, so huge requests are not needlessly copied twice to bounce through the cache, but are moved directly between application memory and the mempool backend driver.
The bounce buffer limit is half the cache size.
So, please keep 256. Maybe change it to RTE_MEMPOOL_CACHE_MAX_SIZE / 2.
[1]: https://patchwork.dpdk.org/project/dpdk/patch/20260526140000.175092-1-mb@smartsharesystems.com/
Also consider keeping 64; it seems to be a popular default burst size for some CPUs.
On the other hand, if the patch introducing default mbuf burst sizes [2] gets accepted, we could replace 32 with RTE_MBUF_BURST_SIZE_THROUGHPUT and 4 with RTE_MBUF_BURST_SIZE_LATENCY.
No strong opinion on 64; I'll leave that up to you.
[2]: https://patchwork.dpdk.org/project/dpdk/list/?series=37914
>
> Combined effect: ~10x runtime reduction.
>
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
With suggested changes,
Acked-by: Morten Brørup <mb@smartsharesystems.com>
^ permalink raw reply
* Re: [PATCH] tree-wide: fix 'allow[s] to' grammar
From: Thomas Monjalon @ 2026-06-01 12:46 UTC (permalink / raw)
To: luca.boccassi; +Cc: dev, Bruce Richardson
In-Reply-To: <aejrN1XS0LEH7hdu@bricha3-mobl1.ger.corp.intel.com>
22/04/2026 17:37, Bruce Richardson:
> On Wed, Apr 22, 2026 at 04:18:53PM +0100, luca.boccassi@gmail.com wrote:
> > From: Luca Boccassi <luca.boccassi@gmail.com>
> >
> > Lintian flags 'allow[s] to' as grammatically incorrect, as it
> > requires an object before the next verb.
> >
> > Fix docs, comments and son on by either switching to gerundinve or
> > adding 'one' as the object.
> >
> > I: dpdk-doc: typo-in-manual-page "allow to" "allow one to" [usr/share/man/man3/rte_graph_model_mcore_dispatch.h.3.gz:32]
> > I: dpdk-doc: typo-in-manual-page "allow to" "allow one to" [usr/share/man/man3/rte_mbuf_dyn.h.3.gz:167]
> > I: dpdk-doc: typo-in-manual-page "allow to" "allow one to" [usr/share/man/man3/rte_mbuf_history.h.3.gz:71]
> > I: dpdk-doc: typo-in-manual-page "allows to" "allows one to" [usr/share/man/man3/rte_bpf_ethdev.h.3.gz:41]
> > I: dpdk-doc: typo-in-manual-page "allows to" "allows one to" [usr/share/man/man3/rte_ethdev.h.3.gz:3423]
> > I: dpdk-doc: typo-in-manual-page "allows to" "allows one to" [usr/share/man/man3/rte_ethdev.h.3.gz:5197]
> > I: dpdk-doc: typo-in-manual-page "allows to" "allows one to" [usr/share/man/man3/rte_ethdev.h.3.gz:5224]
> > I: dpdk-doc: typo-in-manual-page "allows to" "allows one to" [usr/share/man/man3/rte_event_crypto_adapter_runtime_params.3.gz:32]
> > I: dpdk-doc: typo-in-manual-page "allows to" "allows one to" [usr/share/man/man3/rte_event_dma_adapter_runtime_params.3.gz:32]
> > I: dpdk-doc: typo-in-manual-page "allows to" "allows one to" [usr/share/man/man3/rte_event_eth_rx_adapter_runtime_params.3.gz:32]
> > I: dpdk-doc: typo-in-manual-page "allows to" "allows one to" [usr/share/man/man3/rte_event_eth_tx_adapter_runtime_params.3.gz:35]
> > I: dpdk-doc: typo-in-manual-page "allows to" "allows one to" [usr/share/man/man3/rte_flow.h.3.gz:2669]
> > I: dpdk-doc: typo-in-manual-page "allows to" "allows one to" [usr/share/man/man3/rte_graph.h.3.gz:222]
> > I: dpdk-doc: typo-in-manual-page "allows to" "allows one to" [usr/share/man/man3/rte_mempool_objhdr.3.gz:33]
> > I: dpdk-doc: typo-in-manual-page "allows to" "allows one to" [usr/share/man/man3/rte_mldev.h.3.gz:807]
> > I: dpdk-doc: typo-in-manual-page "allows to" "allows one to" [usr/share/man/man3/rte_node_eth_api.h.3.gz:44]
> > I: dpdk-doc: typo-in-manual-page "allows to" "allows one to" [usr/share/man/man3/rte_node_ip4_api.h.3.gz:73]
> > I: dpdk-doc: typo-in-manual-page "allows to" "allows one to" [usr/share/man/man3/rte_node_ip6_api.h.3.gz:50]
> > I: dpdk-doc: typo-in-manual-page "allows to" "allows one to" [usr/share/man/man3/rte_node_pkt_cls_api.h.3.gz:18]
> > I: dpdk-doc: typo-in-manual-page "allows to" "allows one to" [usr/share/man/man3/rte_node_udp4_input_api.h.3.gz:42]
> >
> > Signed-off-by: Luca Boccassi <luca.boccassi@gmail.com>
> > ---
> Acked-by: Bruce Richardson <bruce.richardson@intel.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH v2 2/5] eal: fix async IPC callback not fired when no peers
From: Thomas Monjalon @ 2026-06-01 12:40 UTC (permalink / raw)
To: Anatoly Burakov; +Cc: dev, Jianfeng Tan
In-Reply-To: <n2qqs3VCRg2oTV_S-0kNSw@monjalon.net>
01/06/2026 14:21, Thomas Monjalon:
> 29/05/2026 17:26, Anatoly Burakov:
> > Currently, when rte_mp_request_async() is called and no peer processes
> > are connected (nb_sent == 0), the user callback is never invoked.
> >
> > The original implementation used a dedicated background thread and
> > pthread_cond_signal() to wake it after queuing the dummy request. When
> > that thread was replaced with per-message alarms, no alarm was set for
> > the dummy request, silently breaking the nb_sent == 0 path.
> >
> > This was not noticed because async requests are used while handling
> > secondary process requests, where peers are typically already present.
> >
> > Fix it by setting a 1us alarm on the dummy request, so the callback path
> > immediately triggers and processes it.
> >
> > Fixes: daf9bfca717e ("ipc: remove thread for async requests")
> > Cc: stable@dpdk.org
> >
> > Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
> > ---
> > lib/eal/common/eal_common_proc.c | 12 ++++++++++--
> > 1 file changed, 10 insertions(+), 2 deletions(-)
> >
> > diff --git a/lib/eal/common/eal_common_proc.c b/lib/eal/common/eal_common_proc.c
> > index 799c6e81b0..0ec79336a5 100644
> > --- a/lib/eal/common/eal_common_proc.c
> > +++ b/lib/eal/common/eal_common_proc.c
> > @@ -1187,11 +1187,15 @@ rte_mp_request_async(struct rte_mp_msg *req, const struct timespec *ts,
> > if (rte_eal_process_type() == RTE_PROC_SECONDARY) {
> > ret = mp_request_async(eal_mp_socket_path(), copy, param, ts);
> >
> > - /* if we didn't send anything, put dummy request on the queue */
> > + /* if we didn't send anything, put dummy request on the queue
> > + * and set a minimum-delay alarm so the callback fires immediately.
> > + */
> > if (ret == 0 && reply->nb_sent == 0) {
> > TAILQ_INSERT_TAIL(&pending_requests.requests, dummy,
> > next);
> > dummy_used = true;
> > + if (rte_eal_alarm_set(1, async_reply_handle, dummy) < 0)
> > + EAL_LOG(ERR, "Fail to set alarm for dummy request");
>
> Shouldn't we return an error?
AI suggests this:
if (rte_eal_alarm_set(1, async_reply_handle,
(void *)(uintptr_t)dummy->id) < 0) {
EAL_LOG(ERR, "Fail to set alarm for dummy request");
TAILQ_REMOVE(&pending_requests.requests, dummy, next);
dummy_used = false;
ret = -1;
}
^ permalink raw reply
* Re: [PATCH] raw/gdtc : update MAINTAINERS entry
From: Thomas Monjalon @ 2026-06-01 12:37 UTC (permalink / raw)
To: Wenqiang Chen; +Cc: dev, ran.ming
In-Reply-To: <20260529062058.82782-1-chen.wenqiang2@zte.com.cn>
29/05/2026 08:20, Wenqiang Chen:
> ZTE GDTC
> -M: Yong Zhang <zhang.yong25@zte.com.cn>
> +M: Wenqiang Chen <chen.wenqiang2@zte.com.cn>
> F: drivers/raw/gdtc/
> F: doc/guides/rawdevs/gdtc.rst
Applied, with change in .mailmap, thanks.
^ permalink raw reply
* RE: [PATCH 3/7] app/test/mempool_perf: size mempool by tested cores
From: Morten Brørup @ 2026-06-01 12:22 UTC (permalink / raw)
To: Andrew Rybchenko, Stephen Hemminger, dev
In-Reply-To: <a239680c-0042-4635-b038-6c0a545ba0e5@oktetlabs.ru>
> From: Andrew Rybchenko [mailto:andrew.rybchenko@oktetlabs.ru]
> Sent: Monday, 1 June 2026 10.13
>
> On 5/29/26 8:10 PM, Stephen Hemminger wrote:
> > The mempool size is computed from rte_lcore_count() so on systems
> > with many lcores the test requires multiple GB of hugepages even
> > for the single-core and dual-core variants. On a 20 lcore system
> > with 2 GB of hugepages the test fails with:
> >
> > cannot populate ring_mp_mc mempool
> > Test Failed
> >
> > Size the four mempools by the number of cores actually exercised.
> >
> > Return TEST_SKIPPED rather than -1 when allocation or populate of
> > a mempool fails, so insufficient memory is reported as a skip and
> > not as a test failure. Propagate the skip through the combined
> > mempool_perf_autotest wrapper.
> >
> > Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
>
> Acked-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
LGTM too.
Acked-by: Morten Brørup <mb@smartsharesystems.com>
^ permalink raw reply
* Re: [PATCH v2 2/5] eal: fix async IPC callback not fired when no peers
From: Thomas Monjalon @ 2026-06-01 12:21 UTC (permalink / raw)
To: Anatoly Burakov; +Cc: dev, Jianfeng Tan
In-Reply-To: <1ad014dd239fa1e8ea62aab7e56a7bf7264c04ff.1780068382.git.anatoly.burakov@intel.com>
29/05/2026 17:26, Anatoly Burakov:
> Currently, when rte_mp_request_async() is called and no peer processes
> are connected (nb_sent == 0), the user callback is never invoked.
>
> The original implementation used a dedicated background thread and
> pthread_cond_signal() to wake it after queuing the dummy request. When
> that thread was replaced with per-message alarms, no alarm was set for
> the dummy request, silently breaking the nb_sent == 0 path.
>
> This was not noticed because async requests are used while handling
> secondary process requests, where peers are typically already present.
>
> Fix it by setting a 1us alarm on the dummy request, so the callback path
> immediately triggers and processes it.
>
> Fixes: daf9bfca717e ("ipc: remove thread for async requests")
> Cc: stable@dpdk.org
>
> Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
> ---
> lib/eal/common/eal_common_proc.c | 12 ++++++++++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/lib/eal/common/eal_common_proc.c b/lib/eal/common/eal_common_proc.c
> index 799c6e81b0..0ec79336a5 100644
> --- a/lib/eal/common/eal_common_proc.c
> +++ b/lib/eal/common/eal_common_proc.c
> @@ -1187,11 +1187,15 @@ rte_mp_request_async(struct rte_mp_msg *req, const struct timespec *ts,
> if (rte_eal_process_type() == RTE_PROC_SECONDARY) {
> ret = mp_request_async(eal_mp_socket_path(), copy, param, ts);
>
> - /* if we didn't send anything, put dummy request on the queue */
> + /* if we didn't send anything, put dummy request on the queue
> + * and set a minimum-delay alarm so the callback fires immediately.
> + */
> if (ret == 0 && reply->nb_sent == 0) {
> TAILQ_INSERT_TAIL(&pending_requests.requests, dummy,
> next);
> dummy_used = true;
> + if (rte_eal_alarm_set(1, async_reply_handle, dummy) < 0)
> + EAL_LOG(ERR, "Fail to set alarm for dummy request");
Shouldn't we return an error?
^ permalink raw reply
* Re: [PATCH v2 4/5] eal: fix async IPC resource leaks on partial failure
From: Thomas Monjalon @ 2026-06-01 12:16 UTC (permalink / raw)
To: Anatoly Burakov; +Cc: dev, Jianfeng Tan
In-Reply-To: <eea1925f6fb24f0f92a2a57d45e9a9c824d353c0.1780068382.git.anatoly.burakov@intel.com>
29/05/2026 17:26, Anatoly Burakov:
> Use a numeric request ID for alarm callback lookup so stale callbacks
> from rolled-back requests become harmless no-ops.
[...]
> +static struct pending_request *
> +find_pending_request_by_id(unsigned long id)
> +{
> + struct pending_request *r;
> +
> + TAILQ_FOREACH(r, &pending_requests.requests, next) {
> + if (r->id == id)
> + return r;
> + }
> +
> + return NULL;
> +}
This function is supposed to find only async requests?
What will happen if id wraparound and becomes 0,
matching sync requests?
I feel we should filter with r->type == REQUEST_TYPE_ASYNC
^ permalink raw reply
* Re: [PATCH] ethdev: promote experimental API's to stable
From: David Marchand @ 2026-06-01 11:55 UTC (permalink / raw)
To: Stephen Hemminger, Andrew Rybchenko; +Cc: dev, Thomas Monjalon
In-Reply-To: <20260527144407.160830-1-stephen@networkplumber.org>
On Wed, 27 May 2026 at 16:44, Stephen Hemminger
<stephen@networkplumber.org> wrote:
> + * ``rte_eth_macaddrs_get``
I am not enthousiastic on marking this stable.
It more or less sets in stone that the mac addresses are stored in an array.
The initial goal was to retrieve all mac addresses of a port (21.11
release note entry):
"""
* **Added support to get all MAC addresses of a device.**
Added ``rte_eth_macaddrs_get`` to allow a user to retrieve all
Ethernet
addresses assigned to a given Ethernet port.
"""
And this is how it is used in testpmd.
https://git.dpdk.org/dpdk/tree/app/test-pmd/config.c#n7618
I'd rather see an API using an iterator that abstracts how macs are stored.
That would also make it possible to skip null macs (which I find ugly
in existing code).
RTE_ETH_DEV_FOREACH_MAC(mac, port_id) {
}
--
David Marchand
^ permalink raw reply
* Re: [PATCH] test/latency: fix intermittent failure on slow platforms
From: Luca Boccassi @ 2026-06-01 10:23 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: dev, stable, Reshma Pattan, Bruce Richardson
In-Reply-To: <20260531180118.274308-1-stephen@networkplumber.org>
On Sun, 31 May 2026 at 19:01, Stephen Hemminger
<stephen@networkplumber.org> wrote:
>
> The forwarding loop was bounded by a fixed interval of 0.5ms
> but on slow or emulated platforms with a low-frequency timebase
> (e.g. RISC-V rdtime) this fails because the loop only ran once.
> The test needs two iterations to get any samples.
>
> Rearrange the forwarding loop so that a minimum number of iterations
> are required. The loop still has an upper bound on packets and time
> interval which is expanded to 10 ms.
>
> If no samples are collected, mark the test as skipped.
> Refactor the forwarding loop test so that cleanup happens on
> failure.
>
> Reported-by: Luca Boccassi <bluca@debian.org>
> Fixes: b34508b9cbcd ("test/latency: update with more checks")
> Cc: stable@dpdk.org
>
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> ---
> app/test/test_latencystats.c | 75 ++++++++++++++++++++++--------------
> 1 file changed, 46 insertions(+), 29 deletions(-)
Thanks, this has been failing consistently in riscv64 since at least
25.11, hopefully this makes it stable.
Acked-by: Luca Boccassi <luca.boccassi@gmail.com>
^ permalink raw reply
* [PATCH v1 2/2] dma/odm: avoid zero length DMA transfers
From: Shijith Thotton @ 2026-06-01 10:15 UTC (permalink / raw)
To: Gowrishankar Muthukrishnan, Vidya Sagar Velumuri; +Cc: dev, Shijith Thotton
In-Reply-To: <20260601101559.1925302-1-sthotton@marvell.com>
Add validation to reject zero-length DMA operations early
with -EINVAL, preventing queue disable.
Signed-off-by: Shijith Thotton <sthotton@marvell.com>
---
drivers/dma/odm/odm_dmadev.c | 18 +++++++++++++++---
1 file changed, 15 insertions(+), 3 deletions(-)
diff --git a/drivers/dma/odm/odm_dmadev.c b/drivers/dma/odm/odm_dmadev.c
index 0211133bd4..7488b960fd 100644
--- a/drivers/dma/odm/odm_dmadev.c
+++ b/drivers/dma/odm/odm_dmadev.c
@@ -110,6 +110,9 @@ odm_dmadev_copy(void *dev_private, uint16_t vchan, rte_iova_t src, rte_iova_t ds
vq = &odm->vq[vchan];
hdr.s.xtype = vq->xtype;
+ if (unlikely(!length))
+ return -EINVAL;
+
h = length;
h |= ((uint64_t)length << 32);
@@ -262,14 +265,20 @@ odm_dmadev_copy_sg(void *dev_private, uint16_t vchan, const struct rte_dma_sge *
pending_submit_len = vq->pending_submit_len;
pending_submit_cnt = vq->pending_submit_cnt;
- if (unlikely(nb_src > 4 || nb_dst > 4))
+ if (unlikely(!nb_src || nb_src > 4 || !nb_dst || nb_dst > 4))
return -EINVAL;
- for (i = 0; i < nb_src; i++)
+ for (i = 0; i < nb_src; i++) {
+ if (unlikely(!src[i].length))
+ return -EINVAL;
s_sz += src[i].length;
+ }
- for (i = 0; i < nb_dst; i++)
+ for (i = 0; i < nb_dst; i++) {
+ if (unlikely(!dst[i].length))
+ return -EINVAL;
d_sz += dst[i].length;
+ }
if (s_sz != d_sz)
return -EINVAL;
@@ -342,6 +351,9 @@ odm_dmadev_fill(void *dev_private, uint16_t vchan, uint64_t pattern, rte_iova_t
.s.nlst = 1,
};
+ if (unlikely(!length))
+ return -EINVAL;
+
h = (uint64_t)length;
switch (pattern) {
--
2.25.1
^ permalink raw reply related
* [PATCH v1 1/2] dma/odm: support dev to mem transfers
From: Shijith Thotton @ 2026-06-01 10:15 UTC (permalink / raw)
To: Gowrishankar Muthukrishnan, Vidya Sagar Velumuri
Cc: dev, Vamsi Attunuru, Shijith Thotton
In-Reply-To: <20260601101559.1925302-1-sthotton@marvell.com>
From: Vamsi Attunuru <vattunuru@marvell.com>
Adds support for dev to mem and mem to dev
DMA transfers.
Signed-off-by: Vamsi Attunuru <vattunuru@marvell.com>
Signed-off-by: Shijith Thotton <sthotton@marvell.com>
---
drivers/dma/odm/odm.c | 51 ++++++++++++++++++++++++++++++++++--
drivers/dma/odm/odm.h | 12 ++++++++-
drivers/dma/odm/odm_dmadev.c | 9 ++++---
drivers/dma/odm/odm_priv.h | 4 ++-
4 files changed, 69 insertions(+), 7 deletions(-)
diff --git a/drivers/dma/odm/odm.c b/drivers/dma/odm/odm.c
index 270808f4df..0633ce0b4b 100644
--- a/drivers/dma/odm/odm.c
+++ b/drivers/dma/odm/odm.c
@@ -125,13 +125,41 @@ odm_disable(struct odm_dev *odm)
return 0;
}
+static int
+odm_get_ext_port_type(const struct rte_dma_vchan_conf *conf, uint8_t *ext_port)
+{
+ uint8_t coreid;
+
+ if (conf->src_port.port_type == RTE_DMA_PORT_PCIE) {
+ coreid = conf->src_port.pcie.coreid;
+ } else if (conf->dst_port.port_type == RTE_DMA_PORT_PCIE) {
+ coreid = conf->dst_port.pcie.coreid;
+ } else {
+ *ext_port = ODM_EXT_PORT_NCB;
+ return 0;
+ }
+
+ switch (coreid) {
+ case 0:
+ *ext_port = ODM_EXT_PORT_PEM0;
+ return 0;
+ case 1:
+ *ext_port = ODM_EXT_PORT_PEM1;
+ return 0;
+ default:
+ ODM_LOG(ERR, "Unsupported PCIe coreid %u (only 0 and 1 are valid)", coreid);
+ return -EINVAL;
+ }
+}
+
int
-odm_vchan_setup(struct odm_dev *odm, int vchan, int nb_desc)
+odm_vchan_setup(struct odm_dev *odm, int vchan, const struct rte_dma_vchan_conf *conf)
{
struct odm_queue *vq = &odm->vq[vchan];
int isize, csize, max_nb_desc, rc = 0;
union odm_mbox_msg mbox_msg;
const struct rte_memzone *mz;
+ uint8_t ext_port;
char name[32];
if (vq->iring_mz != NULL)
@@ -140,10 +168,29 @@ odm_vchan_setup(struct odm_dev *odm, int vchan, int nb_desc)
mbox_msg.u[0] = 0;
mbox_msg.u[1] = 0;
+ switch (conf->direction) {
+ case RTE_DMA_DIR_DEV_TO_MEM:
+ vq->xtype = ODM_XTYPE_INBOUND;
+ break;
+ case RTE_DMA_DIR_MEM_TO_DEV:
+ vq->xtype = ODM_XTYPE_OUTBOUND;
+ break;
+ case RTE_DMA_DIR_MEM_TO_MEM:
+ vq->xtype = ODM_XTYPE_INTERNAL;
+ break;
+ default:
+ ODM_LOG(ERR, "Unsupported DMA direction %d", conf->direction);
+ return -EINVAL;
+ }
+
/* ODM PF driver expects vfid starts from index 0 */
mbox_msg.q.vfid = odm->vfid;
mbox_msg.q.cmd = ODM_QUEUE_OPEN;
mbox_msg.q.qidx = vchan;
+ rc = odm_get_ext_port_type(conf, &ext_port);
+ if (rc < 0)
+ return rc;
+ mbox_msg.q.ext_port = ext_port;
rc = send_mbox_to_pf(odm, &mbox_msg, &mbox_msg);
if (rc < 0)
return rc;
@@ -151,7 +198,7 @@ odm_vchan_setup(struct odm_dev *odm, int vchan, int nb_desc)
/* Determine instruction & completion ring sizes. */
/* Create iring that can support nb_desc. Round up to a multiple of 1024. */
- isize = RTE_ALIGN_CEIL(nb_desc * ODM_IRING_ENTRY_SIZE_MAX * 8, 1024);
+ isize = RTE_ALIGN_CEIL(conf->nb_desc * ODM_IRING_ENTRY_SIZE_MAX * 8, 1024);
isize = RTE_MIN(isize, ODM_IRING_MAX_SIZE);
snprintf(name, sizeof(name), "vq%d_iring%d", odm->vfid, vchan);
mz = rte_memzone_reserve_aligned(name, isize, SOCKET_ID_ANY, 0, 1024);
diff --git a/drivers/dma/odm/odm.h b/drivers/dma/odm/odm.h
index 6b96439094..a6b06daeb2 100644
--- a/drivers/dma/odm/odm.h
+++ b/drivers/dma/odm/odm.h
@@ -9,6 +9,7 @@
#include <rte_common.h>
#include <rte_compat.h>
+#include <rte_dmadev.h>
#include <rte_io.h>
#include <rte_log.h>
#include <rte_memzone.h>
@@ -40,10 +41,17 @@
* ODM Transfer Type Enumeration
* Enumerates the pointer type in ODM_DMA_INSTR_HDR_S[XTYPE]
*/
+#define ODM_XTYPE_OUTBOUND 0
+#define ODM_XTYPE_INBOUND 1
#define ODM_XTYPE_INTERNAL 2
#define ODM_XTYPE_FILL0 4
#define ODM_XTYPE_FILL1 5
+/* ODM external port type */
+#define ODM_EXT_PORT_PEM0 0x0
+#define ODM_EXT_PORT_PEM1 0x1
+#define ODM_EXT_PORT_NCB 0x2
+
/*
* ODM Header completion type enumeration
* Enumerates the completion type in ODM_DMA_INSTR_HDR_S[CT]
@@ -168,6 +176,8 @@ struct odm_queue {
uint16_t iring_max_words;
/* Number of words in cring.*/
uint16_t cring_max_entry;
+ /* DMA transfer type.*/
+ uint16_t xtype;
/* Extra instruction size used per inflight instruction.*/
uint8_t *extra_ins_sz;
struct vq_stats stats;
@@ -189,6 +199,6 @@ int odm_dev_fini(struct odm_dev *odm);
int odm_configure(struct odm_dev *odm);
int odm_enable(struct odm_dev *odm);
int odm_disable(struct odm_dev *odm);
-int odm_vchan_setup(struct odm_dev *odm, int vchan, int nb_desc);
+int odm_vchan_setup(struct odm_dev *odm, int vchan, const struct rte_dma_vchan_conf *conf);
#endif /* _ODM_H_ */
diff --git a/drivers/dma/odm/odm_dmadev.c b/drivers/dma/odm/odm_dmadev.c
index a2f4ed9a8e..0211133bd4 100644
--- a/drivers/dma/odm/odm_dmadev.c
+++ b/drivers/dma/odm/odm_dmadev.c
@@ -30,7 +30,8 @@ odm_dmadev_info_get(const struct rte_dma_dev *dev, struct rte_dma_info *dev_info
dev_info->max_vchans = odm->max_qs;
dev_info->nb_vchans = odm->num_qs;
dev_info->dev_capa =
- (RTE_DMA_CAPA_MEM_TO_MEM | RTE_DMA_CAPA_OPS_COPY | RTE_DMA_CAPA_OPS_COPY_SG);
+ (RTE_DMA_CAPA_MEM_TO_MEM | RTE_DMA_CAPA_OPS_COPY | RTE_DMA_CAPA_OPS_COPY_SG |
+ RTE_DMA_CAPA_MEM_TO_DEV | RTE_DMA_CAPA_DEV_TO_MEM);
dev_info->max_desc = ODM_IRING_MAX_ENTRY;
dev_info->min_desc = 1;
dev_info->max_sges = ODM_MAX_POINTER;
@@ -58,7 +59,7 @@ odm_dmadev_vchan_setup(struct rte_dma_dev *dev, uint16_t vchan,
struct odm_dev *odm = dev->fp_obj->dev_private;
RTE_SET_USED(conf_sz);
- return odm_vchan_setup(odm, vchan, conf->nb_desc);
+ return odm_vchan_setup(odm, vchan, conf);
}
static int
@@ -99,7 +100,7 @@ odm_dmadev_copy(void *dev_private, uint16_t vchan, rte_iova_t src, rte_iova_t ds
struct odm_queue *vq;
uint64_t h;
- const union odm_instr_hdr_s hdr = {
+ union odm_instr_hdr_s hdr = {
.s.ct = ODM_HDR_CT_CW_NC,
.s.xtype = ODM_XTYPE_INTERNAL,
.s.nfst = 1,
@@ -107,6 +108,7 @@ odm_dmadev_copy(void *dev_private, uint16_t vchan, rte_iova_t src, rte_iova_t ds
};
vq = &odm->vq[vchan];
+ hdr.s.xtype = vq->xtype;
h = length;
h |= ((uint64_t)length << 32);
@@ -252,6 +254,7 @@ odm_dmadev_copy_sg(void *dev_private, uint16_t vchan, const struct rte_dma_sge *
vq = &odm->vq[vchan];
const uint16_t max_iring_words = vq->iring_max_words;
+ hdr.s.xtype = vq->xtype;
iring_head_ptr = vq->iring_mz->addr;
iring_head = vq->iring_head;
iring_sz_available = vq->iring_sz_available;
diff --git a/drivers/dma/odm/odm_priv.h b/drivers/dma/odm/odm_priv.h
index 1878f4d9a6..71a46c7122 100644
--- a/drivers/dma/odm/odm_priv.h
+++ b/drivers/dma/odm/odm_priv.h
@@ -34,8 +34,10 @@ struct odm_mbox_queue_msg {
uint64_t vfid : 8;
/* Queue index in the VF */
uint64_t qidx : 8;
+ /* Port type for external DMA access */
+ uint64_t ext_port : 8;
/* Reserved */
- uint64_t rsvd_24_63 : 40;
+ uint64_t rsvd_32_63 : 32;
};
union odm_mbox_msg {
--
2.25.1
^ permalink raw reply related
* [PATCH v1 0/2] dma/odm: dev-to-mem support and zero-length validation
From: Shijith Thotton @ 2026-06-01 10:15 UTC (permalink / raw)
Cc: dev, Shijith Thotton
This series extends the Marvell ODM DMA driver with device memory
bidirectional DMA transfers (dev-to-mem and mem-to-dev), and rejects
zero-length operations early with -EINVAL to avoid queue disable.
Shijith Thotton (1):
dma/odm: avoid zero length DMA transfers
Vamsi Attunuru (1):
dma/odm: support dev to mem transfers
drivers/dma/odm/odm.c | 51 ++++++++++++++++++++++++++++++++++--
drivers/dma/odm/odm.h | 12 ++++++++-
drivers/dma/odm/odm_dmadev.c | 27 ++++++++++++++-----
drivers/dma/odm/odm_priv.h | 4 ++-
4 files changed, 84 insertions(+), 10 deletions(-)
--
2.25.1
^ permalink raw reply
* Re: Re: [PATCH v19 00/11]net/sxe2: fix logic errors and address feedback
From: liujie5 @ 2026-06-01 10:14 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev, stephen, David Marchand
In-Reply-To: <gMRpO5X1TMqg0ezYQiGHfg@monjalon.net>
[-- Attachment #1: Type: text/plain, Size: 733 bytes --]
26/05/2026 16:13, Thomas Monjalon:
> 21/05/2026 17:16, Thomas Monjalon:
> > Hello,
> >
> > 20/05/2026 04:17, liujie5@linkdatatechnology.com:
> > > common/sxe2: add sxe2 basic structures
> >
> > Are you planning to add a crypto or compress driver?
> > This is usually the reason to have a common library.
> > If you don't intend to share some code between different driver,
> > then you should not have a common library.
>
> We are curious about your plans for sxe2.
> Please, could you reply?
> Will you add another driver class to sxe2?
I see you are submitting patches
but you don't take time to answer questions.
Please stop sending before answering,
we need to communicate, otherwise it won't work.
[-- Attachment #2: Type: text/html, Size: 4159 bytes --]
^ permalink raw reply
* Re: [PATCH v2 3/5] trace: add PMU
From: Thomas Monjalon @ 2026-06-01 10:08 UTC (permalink / raw)
To: Tomasz Duszynski, Rakesh Kudurumalla
Cc: Jerin Jacob, Sunil Kumar Kori, dev, david.marchand, ndabilpuram,
mb
In-Reply-To: <20260505053023.3854665-3-rkudurumalla@marvell.com>
Hello,
This series is failing in the CI tests.
Are you working on a new version?
05/05/2026 07:30, rkudurumalla:
> From: Rakesh Kudurumalla <rkudurumalla@marvell.com>
>
> In order to profile app, one needs to store significant amount of samples
> somewhere for an analysis later on.
> Since trace library supports storing data in a CTF format,
> lets take advantage of that and add a dedicated PMU tracepoint.
>
> Signed-off-by: Tomasz Duszynski <tduszynski@marvell.com>
> Signed-off-by: Rakesh Kudurumalla <rkudurumalla@marvell.com>
^ permalink raw reply
* Re: [PATCH] eal: fix data race in hugepage prefault
From: Thomas Monjalon @ 2026-06-01 10:03 UTC (permalink / raw)
To: Michal Sieron, Stephen Hemminger
Cc: dev, stable, Anatoly Burakov, Bruce Richardson
In-Reply-To: <20260520170812.759638-1-stephen@networkplumber.org>
20/05/2026 19:08, Stephen Hemminger:
> The prefault step in alloc_seg() reads a value from the hugepage and
> writes it back unchanged to force the kernel to commit the backing
> page. The read and write were not atomic, which races with concurrent
> access to the same physical page from a secondary process attaching
> to the hugetlbfs-backed mapping during rte_eal_init().
>
> Replace the non-atomic load+store with a single atomic fetch-or of
> zero. This touches the page with an atomic read-modify-write without
> changing its contents, eliminating the race while preserving the
> original intent of forcing a write fault.
>
> Fixes: 0f1631be24bd ("mem: fix page fault trigger")
> Cc: stable@dpdk.org
>
> Reported-by: Michal Sieron <michal.sieron@nokia.com>
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> ---
> --- a/lib/eal/linux/eal_memalloc.c
> +++ b/lib/eal/linux/eal_memalloc.c
> - *(volatile int *)addr = *(volatile int *)addr;
> + (void)rte_atomic_fetch_or_explicit((int *)addr, 0, rte_memory_order_relaxed);
There is a compilation failure:
lib/eal/linux/eal_memalloc.c:604:8: error: address argument to atomic operation must be a pointer to _Atomic type ('int *' invalid)
(void)rte_atomic_fetch_or_explicit((int *)addr, 0, rte_memory_order_relaxed);
^ ~~~~~~~~~~~
^ permalink raw reply
* Re: [PATCH v19 00/11]net/sxe2: fix logic errors and address feedback
From: Thomas Monjalon @ 2026-06-01 9:51 UTC (permalink / raw)
To: Jie Liu; +Cc: dev, stephen, David Marchand
In-Reply-To: <gMRpO5X1TMqg0ezYQiGHfg@monjalon.net>
26/05/2026 16:13, Thomas Monjalon:
> 21/05/2026 17:16, Thomas Monjalon:
> > Hello,
> >
> > 20/05/2026 04:17, liujie5@linkdatatechnology.com:
> > > common/sxe2: add sxe2 basic structures
> >
> > Are you planning to add a crypto or compress driver?
> > This is usually the reason to have a common library.
> > If you don't intend to share some code between different driver,
> > then you should not have a common library.
>
> We are curious about your plans for sxe2.
> Please, could you reply?
> Will you add another driver class to sxe2?
I see you are submitting patches
but you don't take time to answer questions.
Please stop sending before answering,
we need to communicate, otherwise it won't work.
^ permalink raw reply
* Re: [PATCH v3 3/5] ethdev: hide VMDq internal sizes
From: Andrew Rybchenko @ 2026-06-01 9:39 UTC (permalink / raw)
To: David Marchand, dev; +Cc: rjarry, cfontain, Thomas Monjalon
In-Reply-To: <20260510170306.3406045-4-david.marchand@redhat.com>
On 5/10/26 8:03 PM, David Marchand wrote:
> Hide RTE_ETH_NUM_RECEIVE_MAC_ADDR and RTE_ETH_VMDQ_NUM_UC_HASH_ARRAY
> in the driver API as those (ambiguous) macros are only a driver concern.
>
> In practice, this is only used by the bnxt and ixgbe (+ clones) drivers.
>
> Signed-off-by: David Marchand <david.marchand@redhat.com>
Acked-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
^ permalink raw reply
* Re: [PATCH v3 2/5] ethdev: skip VMDq pools unless configured
From: Andrew Rybchenko @ 2026-06-01 9:38 UTC (permalink / raw)
To: David Marchand, dev
Cc: rjarry, cfontain, Nithin Dabilpuram, Kiran Kumar K,
Sunil Kumar Kori, Satha Rao, Harman Kalra, Thomas Monjalon
In-Reply-To: <20260510170306.3406045-3-david.marchand@redhat.com>
On 5/10/26 8:03 PM, David Marchand wrote:
> The mac_addr_add API describes that only the 0 pool should be passed
> unless VMDq has been enabled, though there was no validation so far.
> Add such a check, then cleanup the MAC related operations (adding,
> removing, restoring).
>
> As a side effect, the net/cnxk does not need to manually reset the
> mac_pool_sel[] array.
>
> Signed-off-by: David Marchand <david.marchand@redhat.com>
for ethdev
Acked-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
^ permalink raw reply
* Re: [PATCH v3 1/5] ethdev: check VMDq availability
From: Andrew Rybchenko @ 2026-06-01 9:38 UTC (permalink / raw)
To: David Marchand, dev; +Cc: rjarry, cfontain, Thomas Monjalon
In-Reply-To: <20260510170306.3406045-2-david.marchand@redhat.com>
On 5/10/26 8:03 PM, David Marchand wrote:
> Refuse VMDq related Rx/Tx modes when the driver do not announce VMDq
> pools availability.
> This will used later as a gate to ignore/reject VMDq related matters.
>
> Signed-off-by: David Marchand <david.marchand@redhat.com>
sorry for spam, I found the latest version too late
Acked-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
^ permalink raw reply
* Re: [PATCH v2 2/5] ethdev: announce VMDq capability
From: Andrew Rybchenko @ 2026-06-01 9:36 UTC (permalink / raw)
To: David Marchand, dev
Cc: Kishore Padmanabha, Ajit Khaparde, Bruce Richardson,
Anatoly Burakov, Vladimir Medvedkin, Jiawen Wu, Zaiyu Wang,
Thomas Monjalon
In-Reply-To: <20260506123554.2524136-3-david.marchand@redhat.com>
On 5/6/26 3:35 PM, David Marchand wrote:
> Let's mark VMDq feature availability as a per device capability.
> We can then enforce API calls related to this feature are done on device
> with such capability.
>
> Signed-off-by: David Marchand <david.marchand@redhat.com>
for ethdev
Acked-by: Andrew Rybchenko@oktetlabs.ru>
^ permalink raw reply
* Re: [PATCH v2 1/5] ethdev: skip VMDq pools unless configured
From: Andrew Rybchenko @ 2026-06-01 9:35 UTC (permalink / raw)
To: David Marchand, dev
Cc: Nithin Dabilpuram, Kiran Kumar K, Sunil Kumar Kori, Satha Rao,
Harman Kalra, Thomas Monjalon
In-Reply-To: <20260506123554.2524136-2-david.marchand@redhat.com>
On 5/6/26 3:35 PM, David Marchand wrote:
> The mac_addr_add API describes that only the 0 pool should be passed
> unless VMDq has been enabled, though there was no validation so far.
> Add such a check, then cleanup the related operations (adding, removing,
> restoring).
>
> As a side effect, the net/cnxk does not need to manually reset the
> mac_pool_sel[] array.
>
> Signed-off-by: David Marchand <david.marchand@redhat.com>
Acked-by: Andrew Rybchenko@oktetlabs.ru>
^ permalink raw reply
* Re: [PATCH 3/4] ethdev: hide VMDq internal sizes
From: Andrew Rybchenko @ 2026-06-01 9:34 UTC (permalink / raw)
To: David Marchand, dev; +Cc: rjarry, cfontain, Thomas Monjalon
In-Reply-To: <20260403091836.1073484-4-david.marchand@redhat.com>
On 4/3/26 12:18 PM, David Marchand wrote:
> Hide RTE_ETH_NUM_RECEIVE_MAC_ADDR and RTE_ETH_VMDQ_NUM_UC_HASH_ARRAY
> in the driver API as those (ambiguous) macros are only a driver concern.
>
> In practice, this is only used by the bnxt and ixgbe (+ clones) drivers.
>
> Signed-off-by: David Marchand <david.marchand@redhat.com>
Acked-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
^ permalink raw reply
* Re: [PATCH 2/4] ethdev: announce VMDq capability
From: Andrew Rybchenko @ 2026-06-01 9:32 UTC (permalink / raw)
To: David Marchand, dev
Cc: rjarry, cfontain, Kishore Padmanabha, Ajit Khaparde,
Bruce Richardson, Rosen Xu, Anatoly Burakov, Vladimir Medvedkin,
Jiawen Wu, Zaiyu Wang, Thomas Monjalon
In-Reply-To: <20260403091836.1073484-3-david.marchand@redhat.com>
On 4/3/26 12:18 PM, David Marchand wrote:
> Let's mark VMDq feature availability as a per device capability.
> We can then enforce API calls related to this feature are done on device
> with such capability.
>
> Signed-off-by: David Marchand <david.marchand@redhat.com>
for ethdev
Acked-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox