* [PATCH] app/test-crypto-perf: reset mbuf state for IPsec outbound iterations
From: Gagandeep Singh @ 2026-07-16 7:16 UTC (permalink / raw)
To: dev; +Cc: hemant.agrawal, stable, Gagandeep Singh
In cperf_set_ops_security_ipsec(), the same mbuf is reused across
multiple throughput iterations. For outbound (encap) IPsec the PMD
may modify mbuf metadata such as data_off, data_len and pkt_len as
part of in-place protocol processing. When the mbuf is recycled for
the next burst those modifications must be undone so the PMD always
sees a clean, freshly-allocated-like buffer.
Use rte_pktmbuf_reset() to restore the mbuf to its post-alloc state
in a PMD-agnostic manner, rather than patching individual fields with
driver-specific knowledge of the expected offset values.
Without this reset, drivers that back-adjust data_off after encap
(e.g. DPAA2 SEC, which advances data_off by SEC_FLC_DHR_OUTBOUND on
each dequeue) will receive a buffer with insufficient headroom on the
second and subsequent enqueues, causing hardware errors such as:
DPAA2_SEC: SEC encap returned Error - 50000045
(QI error 0x45: DHR correction underflow, reuse mode)
DPAA2_SEC: SEC returned Error - 50000020
(QI error 0x20: FD format error)
Fixes: 3b7d9f2bc6 ("app/test-crypto-perf: add ipsec lookaside support")
Cc: stable@dpdk.org
Signed-off-by: Gagandeep Singh <g.singh@nxp.com>
---
app/test-crypto-perf/cperf_ops.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/app/test-crypto-perf/cperf_ops.c b/app/test-crypto-perf/cperf_ops.c
index 873fa3b59f..1c8d1e263a 100644
--- a/app/test-crypto-perf/cperf_ops.c
+++ b/app/test-crypto-perf/cperf_ops.c
@@ -409,6 +409,8 @@ cperf_set_ops_security_ipsec(struct rte_crypto_op **ops,
ops[i]->status = RTE_CRYPTO_OP_STATUS_NOT_PROCESSED;
rte_security_attach_session(ops[i], sess);
sym_op->m_src = (struct rte_mbuf *)((uint8_t *)ops[i] + src_buf_offset);
+ if (options->is_outbound)
+ rte_pktmbuf_reset(sym_op->m_src);
sym_op->m_src->pkt_len = test_buffer_size;
while ((m->next != NULL) && (offset >= m->data_len)) {
--
2.25.1
^ permalink raw reply related
* RE: [PATCH v2] net/enic: check notify set return value during init
From: Hyong Youb Kim (hyonkim) @ 2026-07-16 0:40 UTC (permalink / raw)
To: Alexey Simakov, John Daley (johndale), Neil Horman, Sujith Sankar,
David Marchand
Cc: dev@dpdk.org, stable@dpdk.org
In-Reply-To: <20260715103105.39417-1-bigalex934@gmail.com>
> -----Original Message-----
> From: Alexey Simakov <bigalex934@gmail.com>
> Sent: Wednesday, July 15, 2026 7:31 PM
> To: John Daley (johndale) <johndale@cisco.com>; Hyong Youb Kim (hyonkim)
> <hyonkim@cisco.com>; Neil Horman <nhorman@tuxdriver.com>; Sujith Sankar
> <ssujith@cisco.com>; David Marchand <david.marchand@redhat.com>
> Cc: dev@dpdk.org; stable@dpdk.org; Alexey Simakov <bigalex934@gmail.com>
> Subject: [PATCH v2] net/enic: check notify set return value during init
>
> The return value of vnic_dev_notify_set() is silently ignored in
> enic_dev_init(), so a memory allocation failure or hardware command
> error goes unnoticed and the driver continues with uninitialized
> notification state.
>
> Check the return value and propagate the error to abort probe when
> notification setup fails.
>
> Fixes: fefed3d1e62c ("enic: new driver")
> Cc: stable@dpdk.org
>
> Signed-off-by: Alexey Simakov <bigalex934@gmail.com>
> ---
> v2 changes: validate return code of vnic_dev_notify_set()
> in driver init section
> v1 link:
> https://patches.dpdk.org/project/dpdk/patch/20260707112014.82821-1-
> bigalex934@gmail.com/
>
> drivers/net/enic/enic_main.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/enic/enic_main.c b/drivers/net/enic/enic_main.c
> index 2696fa77d4..f46f429135 100644
> --- a/drivers/net/enic/enic_main.c
> +++ b/drivers/net/enic/enic_main.c
> @@ -1887,7 +1887,9 @@ static int enic_dev_init(struct enic *enic)
> LIST_INIT(&enic->flows);
>
> /* set up link status checking */
> - vnic_dev_notify_set(enic->vdev, -1); /* No Intr for notify */
> + err = vnic_dev_notify_set(enic->vdev, -1); /* No Intr for notify */
> + if (err)
> + return err;
>
Could you add an error message, like the following? Looks like all error returns in this function log a message.
dev_err(enic, "failed to enable notify buffer\n");
Thanks.
-Hyong
> enic->overlay_offload = false;
> /*
> --
> 2.34.1
^ permalink raw reply
* Re: [PATCH v3] dmadev: clarify last_idx documentation for completion APIs
From: fengchengwen @ 2026-07-16 0:12 UTC (permalink / raw)
To: Raghavendra Ningoji, dev
Cc: bruce.richardson, kevin.laatz, selwin.sebastian, bhagyada.modali,
david.marchand, thomas
In-Reply-To: <20260715104934.3668478-1-raghavendra.ningoji@amd.com>
Reviewed-by: Chengwen Feng <fengchengwen@huawei.com>
On 7/15/2026 6:49 PM, Raghavendra Ningoji wrote:
> The last_idx output parameter was documented identically for
> rte_dma_completed() and rte_dma_completed_status(), even though the two
> APIs have different semantics:
>
> - rte_dma_completed() only reports operations that completed
> successfully and stops at the first error, so its last_idx is the
> ring_idx of the last successfully completed operation.
> - rte_dma_completed_status() reports all completed operations regardless
> of status, so its last_idx is the last completed operation's ring_idx
> irrespective of success or failure.
>
> In both cases only up to nb_cpls operations are reported per call, so
> last_idx is the ring_idx of the last reported operation, which may not
> be the last operation the device has actually completed.
>
> Refresh the full documentation of both functions to remove the
> ambiguity and make the behaviour explicit.
>
> Fixes: 91e581e5c924 ("dmadev: add data plane API")
>
> Signed-off-by: Raghavendra Ningoji <raghavendra.ningoji@amd.com>
> Acked-by: Bruce Richardson <bruce.richardson@intel.com>
^ permalink raw reply
* [PATCH] net/iavf: fix VLAN offload when inner VLAN is not supported
From: Anurag Mandal @ 2026-07-15 22:52 UTC (permalink / raw)
To: dev; +Cc: bruce.richardson, vladimir.medvedkin, Anurag Mandal, stable
In Double VLAN mode (DVM) i.e. when RTE_ETH_RX_OFFLOAD_VLAN_EXTEND
is enabled, the single VLAN offloads are programmed on the inner
VLAN (0x8100) engine by iavf_config_vlan_strip_v2() &
iavf_config_vlan_insert_v2().
When the PF/hardware does not advertise inner VLAN offloading
capabilities, these functions return -ENOTSUP.
On the enable path,these -ENOTSUP are trsnalated into -EIO,
which makes device configuration fail.
However, in DVM, with the default outer TPID set as 0x8100,
a single 0x8100 tagged VLAN frame is handled by the outer
VLAN engine, so the missing inner capability is harmless
and should not fail the configuration.
This patch fixes the same by returning success when DVM is
enabled and the outer TPID is 0x8100, so the outer VLAN
engine services the single VLAN.
Changed "qinq" flag from 'int' to 'bool' to address memory
wastage.
Fixes: 8599d7604e0a ("net/iavf: support QinQ strip")
Cc: stable@dpdk.org
Signed-off-by: Anurag Mandal <anurag.mandal@intel.com>
---
drivers/net/intel/iavf/iavf_vchnl.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/net/intel/iavf/iavf_vchnl.c b/drivers/net/intel/iavf/iavf_vchnl.c
index f8fffa7802..f346837bf1 100644
--- a/drivers/net/intel/iavf/iavf_vchnl.c
+++ b/drivers/net/intel/iavf/iavf_vchnl.c
@@ -920,7 +920,7 @@ iavf_config_vlan_strip_v2(struct iavf_adapter *adapter, bool enable)
uint8_t msg_buf[IAVF_AQ_BUF_SZ] = {0};
struct iavf_cmd_info args;
uint32_t *ethertype;
- int qinq = adapter->dev_data->dev_conf.rxmode.offloads &
+ bool qinq = adapter->dev_data->dev_conf.rxmode.offloads &
RTE_ETH_RX_OFFLOAD_VLAN_EXTEND;
bool strip_qinq = adapter->dev_data->dev_conf.rxmode.offloads &
RTE_ETH_RX_OFFLOAD_QINQ_STRIP;
@@ -943,7 +943,8 @@ iavf_config_vlan_strip_v2(struct iavf_adapter *adapter, bool enable)
(stripping_caps->inner & VIRTCHNL_VLAN_TOGGLE))
ethertype = &vlan_strip.inner_ethertype_setting;
else
- return -ENOTSUP;
+ /* Return success for non-inner VLAN supported hardware */
+ return (qinq && adapter->tpid == RTE_ETHER_TYPE_VLAN) ? 0 : -ENOTSUP;
memset(&vlan_strip, 0, sizeof(vlan_strip));
vlan_strip.vport_id = vf->vsi_res->vsi_id;
@@ -1036,7 +1037,8 @@ iavf_config_vlan_insert_v2(struct iavf_adapter *adapter, bool enable)
(insertion_caps->inner & VIRTCHNL_VLAN_TOGGLE))
ethertype = &vlan_insert.inner_ethertype_setting;
else
- return -ENOTSUP;
+ /* Return success for non-inner VLAN supported hardware */
+ return (qinq && adapter->tpid == RTE_ETHER_TYPE_VLAN) ? 0 : -ENOTSUP;
memset(&vlan_insert, 0, sizeof(vlan_insert));
vlan_insert.vport_id = vf->vsi_res->vsi_id;
@@ -1067,7 +1069,7 @@ iavf_add_del_vlan_v2(struct iavf_adapter *adapter, uint16_t vlanid, bool add)
struct virtchnl_vlan *vlan_setting;
struct iavf_cmd_info args;
uint32_t filtering_caps;
- int qinq = adapter->dev_data->dev_conf.rxmode.offloads &
+ bool qinq = adapter->dev_data->dev_conf.rxmode.offloads &
RTE_ETH_RX_OFFLOAD_VLAN_EXTEND;
int err;
--
2.43.0
^ permalink raw reply related
* Re: [RFC PATCH] net/dpaa2: fix RSS at inner level for non-tunnelled traffic
From: Maxime Leroy @ 2026-07-15 17:00 UTC (permalink / raw)
To: Hemant Agrawal; +Cc: dev
In-Reply-To: <20260630123857.392884-1-maxime@leroys.fr>
Hi Hemant,
Do you have any preference between the different approaches proposed below?
Regards,
Maxime Leroy
On Tue, Jun 30, 2026 at 2:39 PM Maxime Leroy <maxime@leroys.fr> wrote:
>
> When RTE_ETH_RSS_LEVEL_INNERMOST is requested, the IP key extracts use
> the innermost header index (HDR_INDEX_LAST). The hardware only resolves
> that index when several IP headers are stacked: for a non-tunnelled
> frame, which carries a single IP header, the extraction returns nothing.
> The RSS hash is then constant and all such frames are steered to a
> single Rx queue.
>
> Always also extract the outer IP (header index 0), which the hardware
> resolves for any frame. Non-tunnelled frames are thus hashed on their
> only IP header, while tunnelled frames keep being hashed on their inner
> IP.
>
> This is a deliberate tradeoff: the ethdev API defines
> RTE_ETH_RSS_LEVEL_INNERMOST as hashing the innermost header only, but the
> hardware cannot do that without breaking RSS for plain traffic. As a
> consequence, two tunnelled flows with the same inner header but
> different outer IPs may hash to different queues. This limitation is
> documented in the dpaa2 guide.
>
> Alternatives considered (feedback welcome, hence RFC):
>
> - Hash both outer and inner only under RTE_ETH_RSS_LEVEL_PMD_DEFAULT and
> keep INNERMOST strictly inner-only. The ethdev API leaves the default
> level to the PMD, so this stays API-compliant; it changes the default
> hash for tunnelled traffic.
>
> - Add a generic RTE_ETH_RSS_LEVEL_OUTER_INNER value to the ethdev API so
> applications can request hashing on both encapsulation levels
> explicitly, instead of overloading INNERMOST. This needs an ethdev API
> change and agreement from other PMDs.
>
> Fixes: 32f701671d2f ("net/dpaa2: support inner RSS level for tunnelled traffic")
> Signed-off-by: Maxime Leroy <maxime@leroys.fr>
> ---
> doc/guides/nics/dpaa2.rst | 6 +++
> drivers/net/dpaa2/base/dpaa2_hw_dpni.c | 64 +++++++++++---------------
> 2 files changed, 33 insertions(+), 37 deletions(-)
>
> diff --git a/doc/guides/nics/dpaa2.rst b/doc/guides/nics/dpaa2.rst
> index 2d70bd0ab9..b7b68f0cd5 100644
> --- a/doc/guides/nics/dpaa2.rst
> +++ b/doc/guides/nics/dpaa2.rst
> @@ -558,6 +558,12 @@ Other Limitations
>
> - RSS hash key cannot be modified.
> - RSS RETA cannot be configured.
> +- Under ``RTE_ETH_RSS_LEVEL_INNERMOST``, the IP hash also covers the
> + outermost IP, not only the innermost one. The hardware extracts no IP
> + at the innermost index for non-tunnelled frames, so the outer IP is
> + added to keep RSS working on plain traffic. As a result, tunnelled
> + flows with the same inner header but different outer IPs may be
> + distributed to different queues.
>
> .. _dptmapi:
>
> diff --git a/drivers/net/dpaa2/base/dpaa2_hw_dpni.c b/drivers/net/dpaa2/base/dpaa2_hw_dpni.c
> index 07f4a3d414..b002dba171 100644
> --- a/drivers/net/dpaa2/base/dpaa2_hw_dpni.c
> +++ b/drivers/net/dpaa2/base/dpaa2_hw_dpni.c
> @@ -398,48 +398,38 @@ dpaa2_distset_to_dpkg_profile_cfg(
> case RTE_ETH_RSS_IPV6:
> case RTE_ETH_RSS_FRAG_IPV6:
> case RTE_ETH_RSS_NONFRAG_IPV6_OTHER:
> - case RTE_ETH_RSS_IPV6_EX:
> + case RTE_ETH_RSS_IPV6_EX: {
> + static const uint32_t ip_fields[] = {
> + NH_FLD_IP_SRC, NH_FLD_IP_DST,
> + NH_FLD_IP_PROTO };
> + static const uint8_t ip_hdr_index[] = {
> + 0, DPAA2_DIST_HDR_INDEX_LAST };
> + unsigned int n_hdr, f, h;
>
> if (l3_configured)
> break;
> l3_configured = 1;
>
> - kg_cfg->extracts[i].extract.from_hdr.prot =
> - NET_PROT_IP;
> - kg_cfg->extracts[i].extract.from_hdr.hdr_index =
> - hdr_index;
> - kg_cfg->extracts[i].extract.from_hdr.field =
> - NH_FLD_IP_SRC;
> - kg_cfg->extracts[i].type =
> - DPKG_EXTRACT_FROM_HDR;
> - kg_cfg->extracts[i].extract.from_hdr.type =
> - DPKG_FULL_FIELD;
> - i++;
> -
> - kg_cfg->extracts[i].extract.from_hdr.prot =
> - NET_PROT_IP;
> - kg_cfg->extracts[i].extract.from_hdr.hdr_index =
> - hdr_index;
> - kg_cfg->extracts[i].extract.from_hdr.field =
> - NH_FLD_IP_DST;
> - kg_cfg->extracts[i].type =
> - DPKG_EXTRACT_FROM_HDR;
> - kg_cfg->extracts[i].extract.from_hdr.type =
> - DPKG_FULL_FIELD;
> - i++;
> -
> - kg_cfg->extracts[i].extract.from_hdr.prot =
> - NET_PROT_IP;
> - kg_cfg->extracts[i].extract.from_hdr.hdr_index =
> - hdr_index;
> - kg_cfg->extracts[i].extract.from_hdr.field =
> - NH_FLD_IP_PROTO;
> - kg_cfg->extracts[i].type =
> - DPKG_EXTRACT_FROM_HDR;
> - kg_cfg->extracts[i].extract.from_hdr.type =
> - DPKG_FULL_FIELD;
> - i++;
> - break;
> + /* outer IP always; inner IP too for INNERMOST */
> + n_hdr = (hdr_index == DPAA2_DIST_HDR_INDEX_LAST) ?
> + 2 : 1;
> +
> + for (h = 0; h < n_hdr; h++)
> + for (f = 0; f < RTE_DIM(ip_fields); f++) {
> + kg_cfg->extracts[i].extract.from_hdr.prot =
> + NET_PROT_IP;
> + kg_cfg->extracts[i].extract.from_hdr.hdr_index =
> + ip_hdr_index[h];
> + kg_cfg->extracts[i].extract.from_hdr.field =
> + ip_fields[f];
> + kg_cfg->extracts[i].type =
> + DPKG_EXTRACT_FROM_HDR;
> + kg_cfg->extracts[i].extract.from_hdr.type =
> + DPKG_FULL_FIELD;
> + i++;
> + }
> + break;
> + }
>
> case RTE_ETH_RSS_NONFRAG_IPV4_TCP:
> case RTE_ETH_RSS_NONFRAG_IPV6_TCP:
> --
> 2.43.0
>
--
-------------------------------
Maxime Leroy
maxime@leroys.fr
^ permalink raw reply
* Re: mempool cache change
From: Kishore Padmanabha @ 2026-07-15 15:12 UTC (permalink / raw)
To: Morten Brørup; +Cc: fengchengwen, Thomas Monjalon, dev, Wisam Jaddo
In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35F6596E@smartserver.smartshare.dk>
[-- Attachment #1.1: Type: text/plain, Size: 2473 bytes --]
On Wed, Jul 15, 2026 at 5:02 AM Morten Brørup <mb@smartsharesystems.com>
wrote:
> > From: fengchengwen [mailto:fengchengwen@huawei.com]
> > Sent: Wednesday, 15 July 2026 10.12
> >
> > On 7/15/2026 4:08 AM, Morten Brørup wrote:
> > > Hi Kishore,
> > >
> > > For your testing purposes, please follow the guidance provided to
> > Wisam Jaddo:
> > >
> > https://inbox.dpdk.org/dev/98CBD80474FA8B44BF855DF32C47DC35F65964@smart
> > server.smartshare.dk/
> >
> > We need to recompile in this case. We should try to avoid
> > recompilation.
> > I think it is necessary to adjust RTE_MEMPOOL_CACHE_MAX_SIZE to 768 as
> > a default configuration.
>
> Changing RTE_MEMPOOL_CACHE_MAX_SIZE breaks both the API and the ABI; so it
> has to be done when building locally, where API/ABI breakage is acceptable.
>
> For DPDK 26.11, where API/ABI breakage is acceptable, we can discuss
> increasing the default from 512 to a higher value. I do have some input to
> that discussion, but let's postpone it until after DPDK 26.07 has been
> released.
>
We should increase this value to avoid performance degradation, as users
may not realize they need to change it. We do not have do it right away
for 26.07 release but we should it right after the release.
>
> >
> > Thanks
> >
> > >
> > > Thank you for testing!
> > >
> > > Venlig hilsen / Kind regards,
> > > -Morten Brørup
> > >
> > > From: Kishore Padmanabha [mailto:kishore.padmanabha@broadcom.com]
> > > Sent: Tuesday, 14 July 2026 18.49
> > > To: Thomas Monjalon; Morten Brørup
> > > Cc: dev@dpdk.org
> > > Subject: mempool cache change
> > >
> > > Hi Thomas,
> > >
> > > The recent change done as part of BUG ID: 1027, with commit id
> > https://git.dpdk.org/dpdk/commit/?id=f5e1310f16e0909e7e7f71807123644c63
> > b23cba
> > > Is causing performance drop for the bnxt NIC in 26.07 release.
> > >
> > > The smaller, shallower cache increases the miss rate, causing refills
> > to hit the shared ring more frequently.
> > > In the old code, the cache only touched the shared ring when it
> > climbed past 768 instead of 512. That extra 256 elements of headroom
> > allowed significantly more frees to remain local.
> > >
> > > Could we make the change in config/rte_config.h for
> > RTE_MEMPOOL_CACHE_MAX_SIZE to be 768 instead of 512. Since we use –
> > mbcache=512 as argument for the performance tests.
> > >
> > > Thanks,
> > > Kishore
> > >
> > >
>
>
[-- Attachment #1.2: Type: text/html, Size: 3797 bytes --]
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 5493 bytes --]
^ permalink raw reply
* [PATCH v2 2/2] net/ixgbe: fix return value of close operation
From: Sid Ali Cherrati @ 2026-07-15 12:48 UTC (permalink / raw)
To: dev
Cc: Bruce Richardson, Anatoly Burakov, Vladimir Medvedkin,
Sid Ali Cherrati, stable
In-Reply-To: <20260715124816.19882-1-scherrati1@gmail.com>
rte_intr_callback_unregister() returns the number of unregistered
callbacks on success. Since the close operation started returning
the ret variable instead of 0, this positive value leaks as the
return value of ixgbe_dev_close(), so applications checking
rte_eth_dev_close() != 0 treat a successful close as a failure.
Use a separate cb_ret variable for the unregister return value so a
successful unregister never clobbers the dev_stop() error already
stored in ret, and stop retrying once unregister fails with anything
other than -EAGAIN, since those errors are not transient.
Fixes: 62024eb82756 ("ethdev: change stop operation callback to return int")
Cc: stable@dpdk.org
Signed-off-by: Sid Ali Cherrati <scherrati1@gmail.com>
---
v2: use a temporary cb_ret variable instead of unconditionally zeroing
ret, and stop retrying on a non-transient unregister error, so an
earlier error is not lost or masked by a successful/failed
unregister
drivers/net/intel/ixgbe/ixgbe_ethdev.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/net/intel/ixgbe/ixgbe_ethdev.c b/drivers/net/intel/ixgbe/ixgbe_ethdev.c
index c5010f623c..9433515b85 100644
--- a/drivers/net/intel/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/intel/ixgbe/ixgbe_ethdev.c
@@ -3095,6 +3095,7 @@ ixgbe_dev_close(struct rte_eth_dev *dev)
struct rte_intr_handle *intr_handle = pci_dev->intr_handle;
int retries = 0;
int ret;
+ int cb_ret;
PMD_INIT_FUNC_TRACE();
if (rte_eal_process_type() != RTE_PROC_PRIMARY)
@@ -3118,14 +3119,17 @@ ixgbe_dev_close(struct rte_eth_dev *dev)
rte_intr_disable(intr_handle);
do {
- ret = rte_intr_callback_unregister(intr_handle,
+ cb_ret = rte_intr_callback_unregister(intr_handle,
ixgbe_dev_interrupt_handler, dev);
- if (ret >= 0 || ret == -ENOENT) {
+ if (cb_ret >= 0 || cb_ret == -ENOENT) {
break;
- } else if (ret != -EAGAIN) {
+ } else if (cb_ret != -EAGAIN) {
PMD_INIT_LOG(ERR,
"intr callback unregister failed: %d",
- ret);
+ cb_ret);
+ if (ret == 0)
+ ret = cb_ret;
+ break;
}
rte_delay_ms(100);
} while (retries++ < (10 + IXGBE_LINK_UP_TIME));
--
2.34.1
^ permalink raw reply related
* [PATCH v2 1/2] net/i40e: fix return value of close operation
From: Sid Ali Cherrati @ 2026-07-15 12:48 UTC (permalink / raw)
To: dev
Cc: Bruce Richardson, Anatoly Burakov, Vladimir Medvedkin,
Sid Ali Cherrati, stable
In-Reply-To: <20260710134639.108129-1-scherrati1@gmail.com>
rte_intr_callback_unregister() returns the number of unregistered
callbacks on success. Since the close operation started returning
the ret variable instead of 0, this positive value leaks as the
return value of i40e_dev_close(), so applications checking
rte_eth_dev_close() != 0 treat a successful close as a failure.
Use a separate cb_ret variable for the unregister return value so a
successful unregister never clobbers an earlier error stored in ret,
and stop retrying once unregister fails with anything other than
-EAGAIN, since those errors are not transient.
Fixes: 62024eb82756 ("ethdev: change stop operation callback to return int")
Cc: stable@dpdk.org
Signed-off-by: Sid Ali Cherrati <scherrati1@gmail.com>
---
v2: use a temporary cb_ret variable instead of unconditionally zeroing
ret, and stop retrying on a non-transient unregister error, so an
earlier error is not lost or masked by a successful/failed
unregister
drivers/net/intel/i40e/i40e_ethdev.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/net/intel/i40e/i40e_ethdev.c b/drivers/net/intel/i40e/i40e_ethdev.c
index b6b2d291ee..b5457bcf2e 100644
--- a/drivers/net/intel/i40e/i40e_ethdev.c
+++ b/drivers/net/intel/i40e/i40e_ethdev.c
@@ -2693,6 +2693,7 @@ i40e_dev_close(struct rte_eth_dev *dev)
uint32_t reg;
int i;
int ret;
+ int cb_ret;
uint8_t aq_fail = 0;
int retries = 0;
@@ -2761,14 +2762,17 @@ i40e_dev_close(struct rte_eth_dev *dev)
i40e_pf_host_uninit(dev);
do {
- ret = rte_intr_callback_unregister(intr_handle,
+ cb_ret = rte_intr_callback_unregister(intr_handle,
i40e_dev_interrupt_handler, dev);
- if (ret >= 0 || ret == -ENOENT) {
+ if (cb_ret >= 0 || cb_ret == -ENOENT) {
break;
- } else if (ret != -EAGAIN) {
+ } else if (cb_ret != -EAGAIN) {
PMD_INIT_LOG(ERR,
"intr callback unregister failed: %d",
- ret);
+ cb_ret);
+ if (ret == 0)
+ ret = cb_ret;
+ break;
}
i40e_msec_delay(500);
} while (retries++ < 5);
--
2.34.1
^ permalink raw reply related
* [PATCH v2] doc: add deprecation notice for iavf devarg auto reconfig
From: Ciara Loftus @ 2026-07-15 12:20 UTC (permalink / raw)
To: dev; +Cc: Ciara Loftus, Bruce Richardson
In-Reply-To: <20260715105959.2216756-1-ciara.loftus@intel.com>
The `auto_reconfig` devarg in the iavf driver is enabled by default and the
case for ever disabling it is weak. When disabled, it means the user is
requesting the driver not to restore settings (unicast/multicast
promiscuous modes) when recovering from a reset. The use case where this
might be desired is during a VF initiated reset where the user initiates
the reset and wants the VF brought back up in an untouched state. That
scenario can be facilitated by extending the `rte_pmd_iavf_reinit` API
rather than relying on this devarg, so it should be safe to remove the
devarg.
Signed-off-by: Ciara Loftus <ciara.loftus@intel.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
---
v2:
* Shortened deprecation note
---
doc/guides/rel_notes/deprecation.rst | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index f5c12cc747..910feb7cf2 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -159,3 +159,9 @@ Deprecation Notices
* net/iavf: The dynamic mbuf field used to detect LLDP packets on the
transmit path in the iavf PMD will be removed in a future release.
After removal, only packet type-based detection will be supported.
+
+* net/iavf: The ``auto_reconfig`` devarg is deprecated and will be removed
+ in a future release. It allows disabling the automatic restoration of
+ device settings after a VF reset, but this is of questionable value
+ since most applications expect their settings to be preserved
+ transparently across a reset.
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] doc: add deprecation notice for iavf devarg auto reconfig
From: Bruce Richardson @ 2026-07-15 12:01 UTC (permalink / raw)
To: Ciara Loftus; +Cc: dev
In-Reply-To: <20260715105959.2216756-1-ciara.loftus@intel.com>
On Wed, Jul 15, 2026 at 10:59:59AM +0000, Ciara Loftus wrote:
> The `auto_reconfig` devarg in the iavf driver is enabled by default and the
> case for ever disabling it is weak. When disabled, it means the user is
> requesting the driver not to restore settings (unicast/multicast
> promiscuous modes) when recovering from a reset. The use case where this
> might be desired is during a VF initiated reset where the user initiates
> the reset and wants the VF brought back up in an untouched state. That
> scenario can be facilitated by extending the `rte_pmd_iavf_reinit` API
> rather than relying on this devarg, so it should be safe to remove the
> devarg.
>
> Signed-off-by: Ciara Loftus <ciara.loftus@intel.com>
> ---
> doc/guides/rel_notes/deprecation.rst | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
> index f5c12cc747..b88774a3ae 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -159,3 +159,12 @@ Deprecation Notices
> * net/iavf: The dynamic mbuf field used to detect LLDP packets on the
> transmit path in the iavf PMD will be removed in a future release.
> After removal, only packet type-based detection will be supported.
> +
> +* net/iavf: The ``auto_reconfig`` devarg is deprecated and will be removed
> + in a future release. It allows disabling the automatic restoration of
> + device settings after a VF reset, but this is of questionable value
> + since most applications expect their settings to be preserved
> + transparently across a reset. The only use case for this devarg is
> + arguably a VF initiated reset; however this functionality could be
> + supported by extending the ``rte_pmd_iavf_reinit`` API instead of
> + relying on a devarg.
> --
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
I think the text might be slightly too long for a deprecation notice, so
I'd tend toward removing the description of the possible API change, since
you only talk about how it "could" be done, rather than how it "will" be
done. The first two sentences should be enough on their own.
^ permalink raw reply
* [PATCH] doc: add deprecation notice for iavf devarg auto reconfig
From: Ciara Loftus @ 2026-07-15 10:59 UTC (permalink / raw)
To: dev; +Cc: Ciara Loftus
The `auto_reconfig` devarg in the iavf driver is enabled by default and the
case for ever disabling it is weak. When disabled, it means the user is
requesting the driver not to restore settings (unicast/multicast
promiscuous modes) when recovering from a reset. The use case where this
might be desired is during a VF initiated reset where the user initiates
the reset and wants the VF brought back up in an untouched state. That
scenario can be facilitated by extending the `rte_pmd_iavf_reinit` API
rather than relying on this devarg, so it should be safe to remove the
devarg.
Signed-off-by: Ciara Loftus <ciara.loftus@intel.com>
---
doc/guides/rel_notes/deprecation.rst | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index f5c12cc747..b88774a3ae 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -159,3 +159,12 @@ Deprecation Notices
* net/iavf: The dynamic mbuf field used to detect LLDP packets on the
transmit path in the iavf PMD will be removed in a future release.
After removal, only packet type-based detection will be supported.
+
+* net/iavf: The ``auto_reconfig`` devarg is deprecated and will be removed
+ in a future release. It allows disabling the automatic restoration of
+ device settings after a VF reset, but this is of questionable value
+ since most applications expect their settings to be preserved
+ transparently across a reset. The only use case for this devarg is
+ arguably a VF initiated reset; however this functionality could be
+ supported by extending the ``rte_pmd_iavf_reinit`` API instead of
+ relying on a devarg.
--
2.43.0
^ permalink raw reply related
* [PATCH v3] dmadev: clarify last_idx documentation for completion APIs
From: Raghavendra Ningoji @ 2026-07-15 10:49 UTC (permalink / raw)
To: dev
Cc: fengchengwen, bruce.richardson, kevin.laatz, selwin.sebastian,
bhagyada.modali, david.marchand, thomas, Raghavendra Ningoji
The last_idx output parameter was documented identically for
rte_dma_completed() and rte_dma_completed_status(), even though the two
APIs have different semantics:
- rte_dma_completed() only reports operations that completed
successfully and stops at the first error, so its last_idx is the
ring_idx of the last successfully completed operation.
- rte_dma_completed_status() reports all completed operations regardless
of status, so its last_idx is the last completed operation's ring_idx
irrespective of success or failure.
In both cases only up to nb_cpls operations are reported per call, so
last_idx is the ring_idx of the last reported operation, which may not
be the last operation the device has actually completed.
Refresh the full documentation of both functions to remove the
ambiguity and make the behaviour explicit.
Fixes: 91e581e5c924 ("dmadev: add data plane API")
Signed-off-by: Raghavendra Ningoji <raghavendra.ningoji@amd.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
---
v3:
- Refresh the full documentation of both functions (per Chengwen Feng),
not just the last_idx field: update the summary, nb_cpls, has_error,
status and return descriptions to make the completion semantics
explicit.
v2:
- Clarify (per Bruce Richardson) that last_idx is the ring_idx of the
last operation reported by the call, bounded by nb_cpls, which may not
be the last operation the device has actually completed.
lib/dmadev/rte_dmadev.h | 67 +++++++++++++++++++++++++++--------------
1 file changed, 45 insertions(+), 22 deletions(-)
diff --git a/lib/dmadev/rte_dmadev.h b/lib/dmadev/rte_dmadev.h
index 81dfe187e2..364a9d335a 100644
--- a/lib/dmadev/rte_dmadev.h
+++ b/lib/dmadev/rte_dmadev.h
@@ -1327,26 +1327,41 @@ rte_dma_submit(int16_t dev_id, uint16_t vchan)
}
/**
- * Return the number of operations that have been successfully completed.
- * Once an operation has been reported as completed, the results of that
- * operation will be visible to all cores on the system.
+ * Return the number of operations that have completed successfully,
+ * starting from the current ring position.
+ *
+ * This function reports a contiguous run of successfully completed
+ * operations. It stops at the first operation that either failed or
+ * has not yet completed. Once an operation is reported as successfully
+ * completed, the results of that operation are visible to all cores
+ * on the system.
*
* @param dev_id
* The identifier of the device.
* @param vchan
- * The identifier of virtual DMA channel.
+ * The identifier of the virtual DMA channel.
* @param nb_cpls
- * The maximum number of completed operations that can be processed.
+ * The maximum number of completed operations to report.
* @param[out] last_idx
- * The last completed operation's ring_idx.
+ * The ring_idx of the last successfully completed operation reported
+ * by this call. The function stops at the first failed or incomplete
+ * operation, and reports at most nb_cpls operations, so this may not
+ * be the last successful operation the device has actually completed.
* If not required, NULL can be passed in.
* @param[out] has_error
- * Indicates if there are transfer error.
+ * When set to true, a failed operation was encountered among the
+ * completed operations on the device (within the nb_cpls limit),
+ * causing the function to stop early. The returned count covers
+ * only the successful completions preceding that first failure.
+ * When false, all operations reported by this call succeeded;
+ * the function stopped either because nb_cpls operations have been
+ * reported, or because no more completed operations are available on
+ * the device.
* If not required, NULL can be passed in.
*
* @return
- * The number of operations that successfully completed. This return value
- * must be less than or equal to the value of nb_cpls.
+ * The number of operations that successfully completed. This
+ * return value is less than or equal to the value of nb_cpls.
*/
static inline uint16_t
rte_dma_completed(int16_t dev_id, uint16_t vchan, const uint16_t nb_cpls,
@@ -1385,30 +1400,38 @@ rte_dma_completed(int16_t dev_id, uint16_t vchan, const uint16_t nb_cpls,
}
/**
- * Return the number of operations that have been completed, and the operations
- * result may succeed or fail.
- * Once an operation has been reported as completed successfully, the results of that
- * operation will be visible to all cores on the system.
+ * Return the number of operations that have completed (successfully
+ * or with error), starting from the current ring position.
+ *
+ * This function reports all completed operations up to nb_cpls,
+ * regardless of whether each individual operation succeeded or
+ * failed. Once an operation has been reported as completed
+ * successfully, the results of that operation are visible to all
+ * cores on the system.
*
* @param dev_id
* The identifier of the device.
* @param vchan
- * The identifier of virtual DMA channel.
+ * The identifier of the virtual DMA channel.
* @param nb_cpls
- * Indicates the size of status array.
+ * The size of the status array, i.e. the maximum number of
+ * completed operations to report.
* @param[out] last_idx
- * The last completed operation's ring_idx.
+ * The ring_idx of the last completed operation reported by this
+ * call, whether successful or failed. The function reports up to
+ * nb_cpls completed operations without stopping on errors, so this
+ * may not be the last operation the device has actually completed.
* If not required, NULL can be passed in.
* @param[out] status
- * This is a pointer to an array of length 'nb_cpls' that holds the completion
- * status code of each operation.
+ * Pointer to an array of length 'nb_cpls' that receives the
+ * completion status code of each reported operation.
* @see enum rte_dma_status_code
*
* @return
- * The number of operations that completed. This return value must be less
- * than or equal to the value of nb_cpls.
- * If this number is greater than zero (assuming n), then n values in the
- * status array are also set.
+ * The number of operations that completed. This return value is
+ * less than or equal to the value of nb_cpls.
+ * If this number is n (n > 0), the first n entries in the status
+ * array are valid.
*/
static inline uint16_t
rte_dma_completed_status(int16_t dev_id, uint16_t vchan,
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v2] dmadev: clarify last_idx documentation for completion APIs
From: Raghavendra Ningoji @ 2026-07-15 10:48 UTC (permalink / raw)
To: fengchengwen, dev
Cc: Raghavendra Ningoji, Bruce Richardson, Kevin Laatz,
Selwin.Sebastian, Bhagyada Modali, David Marchand,
Thomas Monjalon
In-Reply-To: <7ce41207-c13f-4c35-8303-119d8241f74f@huawei.com>
On Wed, 15 Jul 2026, fengchengwen <fengchengwen@huawei.com> wrote:
>
> Apart from the comment for the last_idx field, I think the others also
> need to be updated.
>
> Based on your v2, I have refreshed the comments for these two functions.
> [...]
> You can send a v3 version based on this.
Thanks, that reads much better. I have adopted your refreshed comments
for both rte_dma_completed() and rte_dma_completed_status() and will
send them as v3.
Thanks,
Raghavendra
^ permalink raw reply
* [PATCH v2] net/enic: check notify set return value during init
From: Alexey Simakov @ 2026-07-15 10:31 UTC (permalink / raw)
To: John Daley, Hyong Youb Kim, Neil Horman, Sujith Sankar,
David Marchand
Cc: dev, stable, Alexey Simakov
The return value of vnic_dev_notify_set() is silently ignored in
enic_dev_init(), so a memory allocation failure or hardware command
error goes unnoticed and the driver continues with uninitialized
notification state.
Check the return value and propagate the error to abort probe when
notification setup fails.
Fixes: fefed3d1e62c ("enic: new driver")
Cc: stable@dpdk.org
Signed-off-by: Alexey Simakov <bigalex934@gmail.com>
---
v2 changes: validate return code of vnic_dev_notify_set()
in driver init section
v1 link:
https://patches.dpdk.org/project/dpdk/patch/20260707112014.82821-1-bigalex934@gmail.com/
drivers/net/enic/enic_main.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/enic/enic_main.c b/drivers/net/enic/enic_main.c
index 2696fa77d4..f46f429135 100644
--- a/drivers/net/enic/enic_main.c
+++ b/drivers/net/enic/enic_main.c
@@ -1887,7 +1887,9 @@ static int enic_dev_init(struct enic *enic)
LIST_INIT(&enic->flows);
/* set up link status checking */
- vnic_dev_notify_set(enic->vdev, -1); /* No Intr for notify */
+ err = vnic_dev_notify_set(enic->vdev, -1); /* No Intr for notify */
+ if (err)
+ return err;
enic->overlay_offload = false;
/*
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v2] crypto/virtio: cookies are allocated from mempool
From: Ji, Kai @ 2026-07-15 10:29 UTC (permalink / raw)
To: Nicolau, Radu, dev@dpdk.org
Cc: maxime.coquelin@redhat.com, david.marchand@redhat.com,
jianjay.zhou@huawei.com, Jiang, YuX, Fan Zhang
In-Reply-To: <20260706095746.2586714-2-radu.nicolau@intel.com>
[-- Attachment #1: Type: text/plain, Size: 3215 bytes --]
Acked-by: Kai Ji <kai.ji@intel.com>
________________________________
From: Radu Nicolau <radu.nicolau@intel.com>
Sent: 06 July 2026 17:57
To: dev@dpdk.org <dev@dpdk.org>
Cc: maxime.coquelin@redhat.com <maxime.coquelin@redhat.com>; david.marchand@redhat.com <david.marchand@redhat.com>; Nicolau, Radu <radu.nicolau@intel.com>; jianjay.zhou@huawei.com <jianjay.zhou@huawei.com>; Jiang, YuX <yux.jiang@intel.com>; Fan Zhang <fanzhang.oss@gmail.com>
Subject: [PATCH v2] crypto/virtio: cookies are allocated from mempool
The Rx/Tx functions allocate cookies as needed, no need to
allocate and free from heap.
Fixes: 6f0175ff53e0 ("crypto/virtio: support basic PMD ops")
Cc: jianjay.zhou@huawei.com
Signed-off-by: Radu Nicolau <radu.nicolau@intel.com>
Tested-by: Yu Jiang <yux.jiang@intel.com>
---
v2: removed redundant mempool free
drivers/crypto/virtio/virtio_cryptodev.c | 23 -----------------------
1 file changed, 23 deletions(-)
diff --git a/drivers/crypto/virtio/virtio_cryptodev.c b/drivers/crypto/virtio/virtio_cryptodev.c
index 6f079f15f6..d70651646e 100644
--- a/drivers/crypto/virtio/virtio_cryptodev.c
+++ b/drivers/crypto/virtio/virtio_cryptodev.c
@@ -68,7 +68,6 @@ void
virtio_crypto_queue_release(struct virtqueue *vq)
{
struct virtio_crypto_hw *hw;
- uint16_t i;
PMD_INIT_FUNC_TRACE();
@@ -80,9 +79,6 @@ virtio_crypto_queue_release(struct virtqueue *vq)
hw->vqs[vq->vq_queue_index] = NULL;
rte_memzone_free(vq->mz);
rte_mempool_free(vq->mpool);
- for (i = 0; i < vq->vq_nentries; i++)
- rte_free(vq->vq_descx[i].cookie);
-
rte_free(vq);
}
}
@@ -102,8 +98,6 @@ virtio_crypto_queue_setup(struct rte_cryptodev *dev,
unsigned int vq_size;
struct virtio_crypto_hw *hw = dev->data->dev_private;
struct virtqueue *vq = NULL;
- uint32_t i = 0;
- uint32_t j;
PMD_INIT_FUNC_TRACE();
@@ -175,29 +169,12 @@ virtio_crypto_queue_setup(struct rte_cryptodev *dev,
"Cannot create mempool");
goto mpool_create_err;
}
- for (i = 0; i < nb_desc; i++) {
- vq->vq_descx[i].cookie =
- rte_zmalloc("crypto PMD op cookie pointer",
- sizeof(struct virtio_crypto_op_cookie),
- RTE_CACHE_LINE_SIZE);
- if (vq->vq_descx[i].cookie == NULL) {
- VIRTIO_CRYPTO_DRV_LOG_ERR("Failed to "
- "alloc mem for cookie");
- goto cookie_alloc_err;
- }
- }
}
*pvq = vq;
return 0;
-cookie_alloc_err:
- rte_mempool_free(vq->mpool);
- if (i != 0) {
- for (j = 0; j < i; j++)
- rte_free(vq->vq_descx[j].cookie);
- }
mpool_create_err:
rte_free(vq);
return -ENOMEM;
--
2.52.0
[-- Attachment #2: Type: text/html, Size: 7726 bytes --]
^ permalink raw reply related
* [PATCH] examples/l3fwd: dynamic NUMA-aware alloc lcore_conf
From: Chengwen Feng @ 2026-07-15 9:22 UTC (permalink / raw)
To: thomas, stephen; +Cc: dev
In-Reply-To: <20260623032301.17570-1-fengchengwen@huawei.com>
Currently lcore_conf is a global static array. When multiple
ports/lcores are distributed across different NUMA nodes, datapath
suffers from severe cross-NUMA memory access penalty.
On Kunpeng platform, sizeof(struct lcore_conf) reaches 133760 bytes.
Such a huge per-lcore structure significantly amplifies cross-NUMA
overhead in multi-port multi-NUMA deployment scenarios.
This commit refactors lcore_conf to pointer array and implements
per-lcore NUMA-aware hugepage allocation, allocating each lcore's
configuration on its local socket to eliminate remote memory access.
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
---
v3: Fix Thomas' comment: support no-numa parameter
v2: Fix AI review comment: add cleanup when init lcore-conf fail
---
examples/l3fwd/l3fwd.h | 2 +-
examples/l3fwd/l3fwd_acl.c | 2 +-
examples/l3fwd/l3fwd_em.c | 8 +++---
examples/l3fwd/l3fwd_fib.c | 6 ++---
examples/l3fwd/l3fwd_lpm.c | 8 +++---
examples/l3fwd/main.c | 52 +++++++++++++++++++++++++++++++-------
6 files changed, 56 insertions(+), 22 deletions(-)
diff --git a/examples/l3fwd/l3fwd.h b/examples/l3fwd/l3fwd.h
index 349fc37c79..20c457ee7f 100644
--- a/examples/l3fwd/l3fwd.h
+++ b/examples/l3fwd/l3fwd.h
@@ -104,7 +104,7 @@ extern uint32_t hash_entry_number;
extern xmm_t val_eth[RTE_MAX_ETHPORTS];
-extern struct lcore_conf lcore_conf[RTE_MAX_LCORE];
+extern struct lcore_conf *lcore_conf[RTE_MAX_LCORE];
extern struct parm_cfg parm_config;
diff --git a/examples/l3fwd/l3fwd_acl.c b/examples/l3fwd/l3fwd_acl.c
index 4ee3411d2a..0605f6feb9 100644
--- a/examples/l3fwd/l3fwd_acl.c
+++ b/examples/l3fwd/l3fwd_acl.c
@@ -1090,7 +1090,7 @@ acl_main_loop(__rte_unused void *dummy)
prev_tsc = 0;
lcore_id = rte_lcore_id();
- qconf = &lcore_conf[lcore_id];
+ qconf = lcore_conf[lcore_id];
socketid = rte_lcore_to_socket_id(lcore_id);
if (qconf->n_rx_queue == 0) {
diff --git a/examples/l3fwd/l3fwd_em.c b/examples/l3fwd/l3fwd_em.c
index d8748a0edd..9aa23759d3 100644
--- a/examples/l3fwd/l3fwd_em.c
+++ b/examples/l3fwd/l3fwd_em.c
@@ -597,7 +597,7 @@ em_main_loop(__rte_unused void *dummy)
US_PER_S * BURST_TX_DRAIN_US;
lcore_id = rte_lcore_id();
- qconf = &lcore_conf[lcore_id];
+ qconf = lcore_conf[lcore_id];
const uint16_t n_rx_q = qconf->n_rx_queue;
const uint16_t n_tx_p = qconf->n_tx_port;
@@ -685,7 +685,7 @@ em_event_loop_single(struct l3fwd_event_resources *evt_rsrc,
return;
lcore_id = rte_lcore_id();
- lconf = &lcore_conf[lcore_id];
+ lconf = lcore_conf[lcore_id];
RTE_LOG(INFO, L3FWD, "entering %s on lcore %u\n", __func__, lcore_id);
while (!force_quit) {
@@ -747,7 +747,7 @@ em_event_loop_burst(struct l3fwd_event_resources *evt_rsrc,
lcore_id = rte_lcore_id();
- lconf = &lcore_conf[lcore_id];
+ lconf = lcore_conf[lcore_id];
RTE_LOG(INFO, L3FWD, "entering %s on lcore %u\n", __func__, lcore_id);
@@ -877,7 +877,7 @@ em_event_loop_vector(struct l3fwd_event_resources *evt_rsrc,
if (dst_ports == NULL)
return;
lcore_id = rte_lcore_id();
- lconf = &lcore_conf[lcore_id];
+ lconf = lcore_conf[lcore_id];
RTE_LOG(INFO, L3FWD, "entering %s on lcore %u\n", __func__, lcore_id);
diff --git a/examples/l3fwd/l3fwd_fib.c b/examples/l3fwd/l3fwd_fib.c
index 4fc6bf90d5..32c8847130 100644
--- a/examples/l3fwd/l3fwd_fib.c
+++ b/examples/l3fwd/l3fwd_fib.c
@@ -192,7 +192,7 @@ fib_main_loop(__rte_unused void *dummy)
US_PER_S * BURST_TX_DRAIN_US;
lcore_id = rte_lcore_id();
- qconf = &lcore_conf[lcore_id];
+ qconf = lcore_conf[lcore_id];
const uint16_t n_rx_q = qconf->n_rx_queue;
const uint16_t n_tx_p = qconf->n_tx_port;
@@ -282,7 +282,7 @@ fib_event_loop(struct l3fwd_event_resources *evt_rsrc,
lcore_id = rte_lcore_id();
- lconf = &lcore_conf[lcore_id];
+ lconf = lcore_conf[lcore_id];
RTE_LOG(INFO, L3FWD, "entering %s on lcore %u\n", __func__, lcore_id);
@@ -446,7 +446,7 @@ fib_process_event_vector(struct rte_event_vector *vec, uint8_t *type_arr,
uint16_t nh;
int i;
- lconf = &lcore_conf[rte_lcore_id()];
+ lconf = lcore_conf[rte_lcore_id()];
/* Reset counters. */
ipv4_cnt = 0;
diff --git a/examples/l3fwd/l3fwd_lpm.c b/examples/l3fwd/l3fwd_lpm.c
index 2d2651e750..77701503f7 100644
--- a/examples/l3fwd/l3fwd_lpm.c
+++ b/examples/l3fwd/l3fwd_lpm.c
@@ -154,7 +154,7 @@ lpm_main_loop(__rte_unused void *dummy)
US_PER_S * BURST_TX_DRAIN_US;
lcore_id = rte_lcore_id();
- qconf = &lcore_conf[lcore_id];
+ qconf = lcore_conf[lcore_id];
const uint16_t n_rx_q = qconf->n_rx_queue;
const uint16_t n_tx_p = qconf->n_tx_port;
@@ -270,7 +270,7 @@ lpm_event_loop_single(struct l3fwd_event_resources *evt_rsrc,
return;
lcore_id = rte_lcore_id();
- lconf = &lcore_conf[lcore_id];
+ lconf = lcore_conf[lcore_id];
RTE_LOG(INFO, L3FWD, "entering %s on lcore %u\n", __func__, lcore_id);
while (!force_quit) {
@@ -324,7 +324,7 @@ lpm_event_loop_burst(struct l3fwd_event_resources *evt_rsrc,
lcore_id = rte_lcore_id();
- lconf = &lcore_conf[lcore_id];
+ lconf = lcore_conf[lcore_id];
RTE_LOG(INFO, L3FWD, "entering %s on lcore %u\n", __func__, lcore_id);
@@ -468,7 +468,7 @@ lpm_event_loop_vector(struct l3fwd_event_resources *evt_rsrc,
return;
lcore_id = rte_lcore_id();
- lconf = &lcore_conf[lcore_id];
+ lconf = lcore_conf[lcore_id];
dst_port_list =
rte_zmalloc("", sizeof(uint16_t) * evt_rsrc->vector_size,
RTE_CACHE_LINE_SIZE);
diff --git a/examples/l3fwd/main.c b/examples/l3fwd/main.c
index 6866811526..b1ad0af8cb 100644
--- a/examples/l3fwd/main.c
+++ b/examples/l3fwd/main.c
@@ -95,7 +95,7 @@ uint32_t enabled_port_mask;
/* Used only in exact match mode. */
bool ipv6_enabled; /**< ipv6 is false by default. */
-struct lcore_conf lcore_conf[RTE_MAX_LCORE];
+struct lcore_conf *lcore_conf[RTE_MAX_LCORE];
struct parm_cfg parm_config;
@@ -367,17 +367,17 @@ init_lcore_rx_queues(void)
for (i = 0; i < nb_lcore_params; ++i) {
lcore = lcore_params[i].lcore_id;
- nb_rx_queue = lcore_conf[lcore].n_rx_queue;
+ nb_rx_queue = lcore_conf[lcore]->n_rx_queue;
if (nb_rx_queue >= MAX_RX_QUEUE_PER_LCORE) {
printf("error: too many queues (%u) for lcore: %u\n",
(unsigned int)nb_rx_queue + 1, lcore);
return -1;
} else {
- lcore_conf[lcore].rx_queue_list[nb_rx_queue].port_id =
+ lcore_conf[lcore]->rx_queue_list[nb_rx_queue].port_id =
lcore_params[i].port_id;
- lcore_conf[lcore].rx_queue_list[nb_rx_queue].queue_id =
+ lcore_conf[lcore]->rx_queue_list[nb_rx_queue].queue_id =
lcore_params[i].queue_id;
- lcore_conf[lcore].n_rx_queue++;
+ lcore_conf[lcore]->n_rx_queue++;
}
}
return 0;
@@ -1117,6 +1117,36 @@ print_ethaddr(const char *name, const struct rte_ether_addr *eth_addr)
printf("%s%s", name, buf);
}
+static int
+init_lcore_conf(void)
+{
+ unsigned int lcore_id;
+ int socketid;
+
+ for (lcore_id = 0; lcore_id < RTE_MAX_LCORE; lcore_id++) {
+ if (rte_lcore_is_enabled(lcore_id) == 0)
+ continue;
+
+ socketid = numa_on ? rte_lcore_to_socket_id(lcore_id) : 0;
+ lcore_conf[lcore_id] = rte_zmalloc_socket(NULL, sizeof(struct lcore_conf),
+ RTE_CACHE_LINE_SIZE, socketid);
+ if (lcore_conf[lcore_id] == NULL)
+ goto cleanup;
+ }
+
+ return 0;
+
+cleanup:
+ for (lcore_id = 0; lcore_id < RTE_MAX_LCORE; lcore_id++) {
+ if (lcore_conf[lcore_id] != NULL) {
+ rte_free(lcore_conf[lcore_id]);
+ lcore_conf[lcore_id] = NULL;
+ }
+ }
+
+ return -ENOMEM;
+}
+
int
init_mem(uint16_t portid, unsigned int nb_mbuf)
{
@@ -1188,7 +1218,7 @@ init_mem(uint16_t portid, unsigned int nb_mbuf)
}
#endif
- qconf = &lcore_conf[lcore_id];
+ qconf = lcore_conf[lcore_id];
qconf->ipv4_lookup_struct =
l3fwd_lkp.get_ipv4_lookup_struct(socketid);
qconf->ipv6_lookup_struct =
@@ -1489,7 +1519,7 @@ l3fwd_poll_resource_setup(void)
"rte_eth_tx_queue_setup: err=%d, "
"port=%d\n", ret, portid);
- qconf = &lcore_conf[lcore_id];
+ qconf = lcore_conf[lcore_id];
qconf->tx_queue_id[portid] = queueid;
queueid++;
@@ -1502,7 +1532,7 @@ l3fwd_poll_resource_setup(void)
for (lcore_id = 0; lcore_id < RTE_MAX_LCORE; lcore_id++) {
if (rte_lcore_is_enabled(lcore_id) == 0)
continue;
- qconf = &lcore_conf[lcore_id];
+ qconf = lcore_conf[lcore_id];
printf("\nInitializing rx queues on lcore %u ... ", lcore_id );
fflush(stdout);
/* init RX queues */
@@ -1683,6 +1713,10 @@ main(int argc, char **argv)
if (ret < 0)
rte_exit(EXIT_FAILURE, "Invalid L3FWD parameters\n");
+ ret = init_lcore_conf();
+ if (ret)
+ rte_exit(EXIT_FAILURE, "Init lcore conf failed!\n");
+
RTE_LOG(INFO, L3FWD, "Using Rx burst %u Tx burst %u\n", rx_burst_size, tx_burst_size);
/* Setup function pointers for lookup method. */
@@ -1746,7 +1780,7 @@ main(int argc, char **argv)
for (lcore_id = 0; lcore_id < RTE_MAX_LCORE; lcore_id++) {
if (rte_lcore_is_enabled(lcore_id) == 0)
continue;
- qconf = &lcore_conf[lcore_id];
+ qconf = lcore_conf[lcore_id];
for (queue = 0; queue < qconf->n_rx_queue; ++queue) {
portid = qconf->rx_queue_list[queue].port_id;
queueid = qconf->rx_queue_list[queue].queue_id;
--
2.17.1
^ permalink raw reply related
* Re: [PATCH] doc: add deprecation notice about upcoming change to ethdev API
From: Bruce Richardson @ 2026-07-15 9:15 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: dev
In-Reply-To: <20260603023207.31974-1-stephen@networkplumber.org>
On Tue, Jun 02, 2026 at 07:32:07PM -0700, Stephen Hemminger wrote:
> Inform users that rte_eth_dev_get_name_by_port() will add a size
> parameter in next release.
>
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> ---
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
> doc/guides/rel_notes/deprecation.rst | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
> index 17f90a6352..d390a1640a 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -158,3 +158,7 @@ Deprecation Notices
> * net/iavf: The dynamic mbuf field used to detect LLDP packets on the
> transmit path in the iavf PMD will be removed in a future release.
> After removal, only packet type-based detection will be supported.
> +
> +* ethdev: Starting in 26.11, the function ``rte_eth_dev_get_name_by_port()``
> + will take a size parameter as well as the string buffer.
> + This will detect and prevent accidental overwriting of caller provided buffer.
> --
> 2.53.0
>
^ permalink raw reply
* RE: mempool cache change
From: Morten Brørup @ 2026-07-15 9:02 UTC (permalink / raw)
To: fengchengwen, Kishore Padmanabha, Thomas Monjalon; +Cc: dev, Wisam Jaddo
In-Reply-To: <e0b59e0b-1fb7-4a7b-84bb-9fc47f4feb5a@huawei.com>
> From: fengchengwen [mailto:fengchengwen@huawei.com]
> Sent: Wednesday, 15 July 2026 10.12
>
> On 7/15/2026 4:08 AM, Morten Brørup wrote:
> > Hi Kishore,
> >
> > For your testing purposes, please follow the guidance provided to
> Wisam Jaddo:
> >
> https://inbox.dpdk.org/dev/98CBD80474FA8B44BF855DF32C47DC35F65964@smart
> server.smartshare.dk/
>
> We need to recompile in this case. We should try to avoid
> recompilation.
> I think it is necessary to adjust RTE_MEMPOOL_CACHE_MAX_SIZE to 768 as
> a default configuration.
Changing RTE_MEMPOOL_CACHE_MAX_SIZE breaks both the API and the ABI; so it has to be done when building locally, where API/ABI breakage is acceptable.
For DPDK 26.11, where API/ABI breakage is acceptable, we can discuss increasing the default from 512 to a higher value. I do have some input to that discussion, but let's postpone it until after DPDK 26.07 has been released.
>
> Thanks
>
> >
> > Thank you for testing!
> >
> > Venlig hilsen / Kind regards,
> > -Morten Brørup
> >
> > From: Kishore Padmanabha [mailto:kishore.padmanabha@broadcom.com]
> > Sent: Tuesday, 14 July 2026 18.49
> > To: Thomas Monjalon; Morten Brørup
> > Cc: dev@dpdk.org
> > Subject: mempool cache change
> >
> > Hi Thomas,
> >
> > The recent change done as part of BUG ID: 1027, with commit id
> https://git.dpdk.org/dpdk/commit/?id=f5e1310f16e0909e7e7f71807123644c63
> b23cba
> > Is causing performance drop for the bnxt NIC in 26.07 release.
> >
> > The smaller, shallower cache increases the miss rate, causing refills
> to hit the shared ring more frequently.
> > In the old code, the cache only touched the shared ring when it
> climbed past 768 instead of 512. That extra 256 elements of headroom
> allowed significantly more frees to remain local.
> >
> > Could we make the change in config/rte_config.h for
> RTE_MEMPOOL_CACHE_MAX_SIZE to be 768 instead of 512. Since we use –
> mbcache=512 as argument for the performance tests.
> >
> > Thanks,
> > Kishore
> >
> >
^ permalink raw reply
* Re: mempool cache change
From: fengchengwen @ 2026-07-15 8:11 UTC (permalink / raw)
To: Morten Brørup, Kishore Padmanabha, Thomas Monjalon; +Cc: dev, Wisam Jaddo
In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35F6596D@smartserver.smartshare.dk>
On 7/15/2026 4:08 AM, Morten Brørup wrote:
> Hi Kishore,
>
> For your testing purposes, please follow the guidance provided to Wisam Jaddo:
> https://inbox.dpdk.org/dev/98CBD80474FA8B44BF855DF32C47DC35F65964@smartserver.smartshare.dk/
We need to recompile in this case. We should try to avoid recompilation.
I think it is necessary to adjust RTE_MEMPOOL_CACHE_MAX_SIZE to 768 as a
default configuration.
Thanks
>
> Thank you for testing!
>
> Venlig hilsen / Kind regards,
> -Morten Brørup
>
> From: Kishore Padmanabha [mailto:kishore.padmanabha@broadcom.com]
> Sent: Tuesday, 14 July 2026 18.49
> To: Thomas Monjalon; Morten Brørup
> Cc: dev@dpdk.org
> Subject: mempool cache change
>
> Hi Thomas,
>
> The recent change done as part of BUG ID: 1027, with commit id https://git.dpdk.org/dpdk/commit/?id=f5e1310f16e0909e7e7f71807123644c63b23cba
> Is causing performance drop for the bnxt NIC in 26.07 release.
>
> The smaller, shallower cache increases the miss rate, causing refills to hit the shared ring more frequently.
> In the old code, the cache only touched the shared ring when it climbed past 768 instead of 512. That extra 256 elements of headroom allowed significantly more frees to remain local.
>
> Could we make the change in config/rte_config.h for RTE_MEMPOOL_CACHE_MAX_SIZE to be 768 instead of 512. Since we use –mbcache=512 as argument for the performance tests.
>
> Thanks,
> Kishore
>
>
^ permalink raw reply
* Re: [PATCH v2] dmadev: clarify last_idx documentation for completion APIs
From: fengchengwen @ 2026-07-15 8:03 UTC (permalink / raw)
To: Raghavendra Ningoji, dev
Cc: Bruce Richardson, Kevin Laatz, selwin.sebastian, bhagyada.modali,
David Marchand, Thomas Monjalon
In-Reply-To: <20260715060630.3450172-1-raghavendra.ningoji@amd.com>
Apart from the comment for the last_idx field, I think the others also
need to be updated.
Based on your v2, I have refreshed the comments for these two functions.
/**
* Return the number of operations that have completed successfully,
* starting from the current ring position.
*
* This function reports a contiguous run of successfully completed
* operations. It stops at the first operation that either failed or
* has not yet completed. Once an operation is reported as successfully
* completed, the results of that operation are visible to all cores
* on the system.
*
* @param dev_id
* The identifier of the device.
* @param vchan
* The identifier of the virtual DMA channel.
* @param nb_cpls
* The maximum number of completed operations to report.
* @param[out] last_idx
* The ring_idx of the last successfully completed operation reported
* by this call. The function stops at the first failed or incomplete
* operation, and reports at most nb_cpls operations, so this may not
* be the last successful operation the device has actually completed.
* If not required, NULL can be passed in.
* @param[out] has_error
* When set to true, a failed operation was encountered among the
* completed operations on the device (within the nb_cpls limit),
* causing the function to stop early. The returned count covers
* only the successful completions preceding that first failure.
* When false, all operations reported by this call succeeded;
* the function stopped either because nb_cpls operations have been
* reported, or because no more completed operations are available on
* the device.
* If not required, NULL can be passed in.
*
* @return
* The number of operations that successfully completed. This
* return value is less than or equal to the value of nb_cpls.
*/
static inline uint16_t
rte_dma_completed(int16_t dev_id, uint16_t vchan, const uint16_t nb_cpls,
uint16_t *last_idx, bool *has_error)
/**
* Return the number of operations that have completed (successfully
* or with error), starting from the current ring position.
*
* This function reports all completed operations up to nb_cpls,
* regardless of whether each individual operation succeeded or
* failed. Once an operation has been reported as completed
* successfully, the results of that operation are visible to all
* cores on the system.
*
* @param dev_id
* The identifier of the device.
* @param vchan
* The identifier of the virtual DMA channel.
* @param nb_cpls
* The size of the status array, i.e. the maximum number of
* completed operations to report.
* @param[out] last_idx
* The ring_idx of the last completed operation reported by this
* call, whether successful or failed. The function reports up to
* nb_cpls completed operations without stopping on errors, so this
* may not be the last operation the device has actually completed.
* If not required, NULL can be passed in.
* @param[out] status
* Pointer to an array of length 'nb_cpls' that receives the
* completion status code of each reported operation.
* @see enum rte_dma_status_code
*
* @return
* The number of operations that completed. This return value is
* less than or equal to the value of nb_cpls.
* If this number is n (n > 0), the first n entries in the status
* array are valid.
*/
static inline uint16_t
rte_dma_completed_status(int16_t dev_id, uint16_t vchan,
const uint16_t nb_cpls, uint16_t *last_idx,
enum rte_dma_status_code *status)
You can send a v3 version based on this.
Thanks
On 7/15/2026 2:06 PM, Raghavendra Ningoji wrote:
> The last_idx output parameter was documented identically for
> rte_dma_completed() and rte_dma_completed_status(), even though the two
> APIs have different semantics:
>
> - rte_dma_completed() only reports operations that completed
> successfully and stops at the first error, so its last_idx is the
> ring_idx of the last successfully completed operation.
> - rte_dma_completed_status() reports all completed operations regardless
> of status, so its last_idx is the last completed operation's ring_idx
> irrespective of success or failure.
>
> In both cases only up to nb_cpls operations are reported per call, so
> last_idx is the ring_idx of the last reported operation, which may not
> be the last operation the device has actually completed.
>
> Clarify both descriptions to remove the ambiguity.
>
> Fixes: 91e581e5c924 ("dmadev: add data plane API")
>
> Signed-off-by: Raghavendra Ningoji <raghavendra.ningoji@amd.com>
> ---
> v2:
> - Clarify (per Bruce Richardson) that last_idx is the ring_idx of the
> last operation reported by the call, bounded by nb_cpls, which may not
> be the last operation the device has actually completed.
>
> lib/dmadev/rte_dmadev.h | 9 +++++++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/lib/dmadev/rte_dmadev.h b/lib/dmadev/rte_dmadev.h
> index 81dfe187e2..76b0dd6a1b 100644
> --- a/lib/dmadev/rte_dmadev.h
> +++ b/lib/dmadev/rte_dmadev.h
> @@ -1338,7 +1338,9 @@ rte_dma_submit(int16_t dev_id, uint16_t vchan)
> * @param nb_cpls
> * The maximum number of completed operations that can be processed.
> * @param[out] last_idx
> - * The last completed operation's ring_idx.
> + * The ring_idx of the last successfully completed operation reported by
> + * this call (at most nb_cpls operations are reported, so this may not be
> + * the last operation the device has actually completed).
> * If not required, NULL can be passed in.
> * @param[out] has_error
> * Indicates if there are transfer error.
> @@ -1397,7 +1399,10 @@ rte_dma_completed(int16_t dev_id, uint16_t vchan, const uint16_t nb_cpls,
> * @param nb_cpls
> * Indicates the size of status array.
> * @param[out] last_idx
> - * The last completed operation's ring_idx.
> + * The ring_idx of the last operation reported by this call, regardless of
> + * whether it completed successfully or with an error (at most nb_cpls
> + * operations are reported, so this may not be the last operation the
> + * device has actually completed).
> * If not required, NULL can be passed in.
> * @param[out] status
> * This is a pointer to an array of length 'nb_cpls' that holds the completion
^ permalink raw reply
* Re: [PATCH v2] dmadev: clarify last_idx documentation for completion APIs
From: Bruce Richardson @ 2026-07-15 8:03 UTC (permalink / raw)
To: Raghavendra Ningoji
Cc: dev, fengchengwen, Kevin Laatz, selwin.sebastian, bhagyada.modali,
David Marchand, Thomas Monjalon
In-Reply-To: <20260715060630.3450172-1-raghavendra.ningoji@amd.com>
On Wed, Jul 15, 2026 at 11:36:30AM +0530, Raghavendra Ningoji wrote:
> The last_idx output parameter was documented identically for
> rte_dma_completed() and rte_dma_completed_status(), even though the two
> APIs have different semantics:
>
> - rte_dma_completed() only reports operations that completed
> successfully and stops at the first error, so its last_idx is the
> ring_idx of the last successfully completed operation.
> - rte_dma_completed_status() reports all completed operations regardless
> of status, so its last_idx is the last completed operation's ring_idx
> irrespective of success or failure.
>
> In both cases only up to nb_cpls operations are reported per call, so
> last_idx is the ring_idx of the last reported operation, which may not
> be the last operation the device has actually completed.
>
> Clarify both descriptions to remove the ambiguity.
>
> Fixes: 91e581e5c924 ("dmadev: add data plane API")
>
> Signed-off-by: Raghavendra Ningoji <raghavendra.ningoji@amd.com>
> ---
> v2:
> - Clarify (per Bruce Richardson) that last_idx is the ring_idx of the
> last operation reported by the call, bounded by nb_cpls, which may not
> be the last operation the device has actually completed.
>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
^ permalink raw reply
* Re: [PATCH] graph: fix xstats of cloned nodes
From: kirankumark @ 2026-07-15 6:32 UTC (permalink / raw)
To: rjarry
Cc: Andrey.Yudin, dev, jerinj, kirankumark, ndabilpuram, pbhagavatula,
stable, yanzhirun_163
In-Reply-To: <20260708081420.1100574-1-Andrey.Yudin@infotecs.ru>
On Wed, Jul 08, 2026 at 11:14:19AM +0300, Andrey Yudin wrote:
> When cloning a node with xstats enabled, xstat_desc entries are copied
> into the rte_node_register structure, but the nb_xstats field is not.
>
> As a result, the cloned node reports zero available xstats,
> making xstats unusable.
>
> Copy the nb_xstats field when cloning the node so that cloned nodes
> preserve the xstats configuration of the original node.
>
> Fixes: 070db97e017b ("graph: support node xstats")
> Cc: stable@dpdk.org
> Signed-off-by: Andrey Yudin <Andrey.Yudin@infotecs.ru>
> ---
> lib/graph/node.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/lib/graph/node.c b/lib/graph/node.c
> index 1fce3e6632..bb39c616de 100644
> --- a/lib/graph/node.c
> +++ b/lib/graph/node.c
> @@ -208,6 +208,7 @@ node_clone(struct node *node, const char *name)
> goto free;
> }
>
> + reg->xstats->nb_xstats = node->xstats->nb_xstats;
> for (i = 0; i < node->xstats->nb_xstats; i++)
> if (rte_strscpy(reg->xstats->xstat_desc[i], node->xstats->xstat_desc[i],
> RTE_NODE_XSTAT_DESC_SIZE) < 0)
> --
> 2.47.3
>
Acked-by: Kiran Kumar Kokkilagadda <kirankumark@marvell.com>
^ permalink raw reply
* [PATCH v2] dmadev: clarify last_idx documentation for completion APIs
From: Raghavendra Ningoji @ 2026-07-15 6:06 UTC (permalink / raw)
To: dev
Cc: fengchengwen, Bruce Richardson, Kevin Laatz, selwin.sebastian,
bhagyada.modali, David Marchand, Thomas Monjalon,
Raghavendra Ningoji
The last_idx output parameter was documented identically for
rte_dma_completed() and rte_dma_completed_status(), even though the two
APIs have different semantics:
- rte_dma_completed() only reports operations that completed
successfully and stops at the first error, so its last_idx is the
ring_idx of the last successfully completed operation.
- rte_dma_completed_status() reports all completed operations regardless
of status, so its last_idx is the last completed operation's ring_idx
irrespective of success or failure.
In both cases only up to nb_cpls operations are reported per call, so
last_idx is the ring_idx of the last reported operation, which may not
be the last operation the device has actually completed.
Clarify both descriptions to remove the ambiguity.
Fixes: 91e581e5c924 ("dmadev: add data plane API")
Signed-off-by: Raghavendra Ningoji <raghavendra.ningoji@amd.com>
---
v2:
- Clarify (per Bruce Richardson) that last_idx is the ring_idx of the
last operation reported by the call, bounded by nb_cpls, which may not
be the last operation the device has actually completed.
lib/dmadev/rte_dmadev.h | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/lib/dmadev/rte_dmadev.h b/lib/dmadev/rte_dmadev.h
index 81dfe187e2..76b0dd6a1b 100644
--- a/lib/dmadev/rte_dmadev.h
+++ b/lib/dmadev/rte_dmadev.h
@@ -1338,7 +1338,9 @@ rte_dma_submit(int16_t dev_id, uint16_t vchan)
* @param nb_cpls
* The maximum number of completed operations that can be processed.
* @param[out] last_idx
- * The last completed operation's ring_idx.
+ * The ring_idx of the last successfully completed operation reported by
+ * this call (at most nb_cpls operations are reported, so this may not be
+ * the last operation the device has actually completed).
* If not required, NULL can be passed in.
* @param[out] has_error
* Indicates if there are transfer error.
@@ -1397,7 +1399,10 @@ rte_dma_completed(int16_t dev_id, uint16_t vchan, const uint16_t nb_cpls,
* @param nb_cpls
* Indicates the size of status array.
* @param[out] last_idx
- * The last completed operation's ring_idx.
+ * The ring_idx of the last operation reported by this call, regardless of
+ * whether it completed successfully or with an error (at most nb_cpls
+ * operations are reported, so this may not be the last operation the
+ * device has actually completed).
* If not required, NULL can be passed in.
* @param[out] status
* This is a pointer to an array of length 'nb_cpls' that holds the completion
--
2.34.1
^ permalink raw reply related
* RE: mempool cache change
From: Morten Brørup @ 2026-07-14 20:08 UTC (permalink / raw)
To: Kishore Padmanabha, Thomas Monjalon; +Cc: dev, Wisam Jaddo
In-Reply-To: <b54ad1f1692a0274da705d446972efd1@mail.gmail.com>
Hi Kishore,
For your testing purposes, please follow the guidance provided to Wisam Jaddo:
https://inbox.dpdk.org/dev/98CBD80474FA8B44BF855DF32C47DC35F65964@smartserver.smartshare.dk/
Thank you for testing!
Venlig hilsen / Kind regards,
-Morten Brørup
From: Kishore Padmanabha [mailto:kishore.padmanabha@broadcom.com]
Sent: Tuesday, 14 July 2026 18.49
To: Thomas Monjalon; Morten Brørup
Cc: dev@dpdk.org
Subject: mempool cache change
Hi Thomas,
The recent change done as part of BUG ID: 1027, with commit id https://git.dpdk.org/dpdk/commit/?id=f5e1310f16e0909e7e7f71807123644c63b23cba
Is causing performance drop for the bnxt NIC in 26.07 release.
The smaller, shallower cache increases the miss rate, causing refills to hit the shared ring more frequently.
In the old code, the cache only touched the shared ring when it climbed past 768 instead of 512. That extra 256 elements of headroom allowed significantly more frees to remain local.
Could we make the change in config/rte_config.h for RTE_MEMPOOL_CACHE_MAX_SIZE to be 768 instead of 512. Since we use –mbcache=512 as argument for the performance tests.
Thanks,
Kishore
^ permalink raw reply
* mempool cache change
From: Kishore Padmanabha @ 2026-07-14 16:48 UTC (permalink / raw)
To: Thomas Monjalon, Morten Brørup; +Cc: dev
[-- Attachment #1.1: Type: text/plain, Size: 738 bytes --]
Hi Thomas,
The recent change done as part of BUG ID: 1027, with commit id
https://git.dpdk.org/dpdk/commit/?id=f5e1310f16e0909e7e7f71807123644c63b23cba
Is causing performance drop for the bnxt NIC in 26.07 release.
The smaller, shallower cache increases the miss rate, causing refills to
hit the shared ring more frequently.
In the old code, the cache only touched the shared ring when it climbed
past 768 instead of 512. That extra 256 elements of headroom allowed
significantly more frees to remain local.
Could we make the change in config/rte_config.h for
RTE_MEMPOOL_CACHE_MAX_SIZE to be 768 instead of 512. Since we use
–mbcache=512 as argument for the performance tests.
Thanks,
Kishore
[-- Attachment #1.2: Type: text/html, Size: 2685 bytes --]
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 5493 bytes --]
^ 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