* 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
* Re: DPDK release candidate 26.07-rc2
From: Riley Fletcher @ 2026-07-14 15:44 UTC (permalink / raw)
To: Thomas Monjalon, dev
In-Reply-To: <CP3kiV_jTf67aEg8Usilhg@monjalon.net>
IBM - Power Systems Testing
DPDK v26.07-rc2
* Build CI on Fedora 40, 41, 42 and 43 container images for ppc64le
* Basic PF on Mellanox: No issues found
* Performance: TestPMD throughput single core tests
* OS:- RHEL 10.2 kernel: 6.12.0-211.7.3.el10_2.ppc64le
with gcc version 14.3.1 20251022 (Red Hat 14.3.1-4)
Systems tested:
- LPARs on IBM Power11 CHRP IBM, 9105-22A
NICs:
- Mellanox Technologies MT4129 Family [ConnectX-7 100 GbE 2-Port]
- Firmware Version: 28.48.1000 (MT_0000000834)
- OFED 26.04-0.8.6
Regards,
Riley Fletcher
On Fri, 2026-07-03 at 04:58 +0200, Thomas Monjalon wrote:
> A new DPDK release candidate is ready for testing:
> https://git.dpdk.org/dpdk/tag/?id=v26.07-rc2
>
> There are 289 new patches in this snapshot.
>
> Release notes:
> https://doc.dpdk.org/guides/rel_notes/release_26_07.html
>
> There are many fixes and new drivers features.
>
> Please test and report issues on bugs.dpdk.org.
>
> Patches to improve tooling, examples and documentation are welcome.
>
> Thank you everyone
>
^ permalink raw reply
* Re: [PATCH] vhost/crypto: fix segfault
From: Radu Nicolau @ 2026-07-14 12:10 UTC (permalink / raw)
To: Maxime Coquelin
Cc: David Marchand, dev, stable, Chenbo Xia, Jay Zhou, Fan Zhang
In-Reply-To: <dc3a218b-815b-4d18-838e-c3f463b4391b@intel.com>
On 29-Jun-26 9:35 AM, Radu Nicolau wrote:
>
> On 29-Jun-26 9:18 AM, Maxime Coquelin wrote:
>> On Fri, Jun 26, 2026 at 10:50 AM Radu Nicolau
>> <radu.nicolau@intel.com> wrote:
>>>
>>> On 25-Jun-26 1:44 PM, David Marchand wrote:
>>>> On Wed, 24 Jun 2026 at 16:21, Radu Nicolau <radu.nicolau@intel.com>
>>>> wrote:
>>>>> Fix potential call with dev->mem uninitialized, one common usecase
>>>>> example being running the autotest with more than one device.
>>>>>
>>>>> Fixes: 3bb595ecd682 ("vhost/crypto: add request handler")
>>>>> Cc: stable@dpdk.org
>>>>>
>>>>> Signed-off-by: Radu Nicolau <radu.nicolau@intel.com>
>>>>> ---
>>>>> lib/vhost/vhost_crypto.c | 4 ++++
>>>>> 1 file changed, 4 insertions(+)
>>>>>
>>>>> diff --git a/lib/vhost/vhost_crypto.c b/lib/vhost/vhost_crypto.c
>>>>> index 648e2d731b..3679eaca1e 100644
>>>>> --- a/lib/vhost/vhost_crypto.c
>>>>> +++ b/lib/vhost/vhost_crypto.c
>>>>> @@ -1512,6 +1512,10 @@ vhost_crypto_process_one_req(struct
>>>>> vhost_crypto *vcrypto,
>>>>> VC_LOG_ERR("Invalid descriptor");
>>>>> return -1;
>>>>> }
>>>>> + if (unlikely((vc_req->dev->mem) == NULL)) {
>>>> (Unneeded extra ())
>>>>
>>>> It sounds to me that some initialisation failed, or processing happens
>>>> without waiting initialisation finished.
>>> Indeed calling this function with dev->mem uninitialized is caused by
>>> some init/deinit state bug, but I still think we should keep this check
>>> in for added safety.
>>>
>>> I will follow up with a v2 to remove the redundant () and also I will
>>> look into fixing the root cause.
>> Or maybe this crypto backend is lacking proper protection between
>> control and data paths?
>> If dev->mem is reset to NULL asynchrously by the control path without
>> proper locking, then
>> the above fix is not enough. For example, the above check could pass
>> and dev->mem be
>> reset right after.
> 100% there is a deeper root cause for this segfault and I'm working to
> find it, but it may take a while. That's why I propose this as a stop
> gap fix, it adds an extra check but of course it doesn't remove the
> root cause.
I'm unable to reproduce the segfault anymore, I will drop the patch.
^ permalink raw reply
* Re: [PATCH] dmadev: clarify last_idx documentation for completion APIs
From: Bruce Richardson @ 2026-07-14 11:03 UTC (permalink / raw)
To: Raghavendra Ningoji
Cc: dev, fengchengwen, Kevin Laatz, David Marchand, Thomas Monjalon,
Selwin.Sebastian, Bhagyada Modali
In-Reply-To: <20260714110043.3424477-1-raghavendra.ningoji@amd.com>
On Tue, Jul 14, 2026 at 04:30:43PM +0530, Raghavendra Ningoji wrote:
> On Tue, 14 Jul 2026, Bruce Richardson <bruce.richardson@intel.com> wrote:
> >
> > Just wondering if completed is ambiguous here. The index is that of the
> > last reported operation, right? So if we request completed status of e.g.
> > 32 operations, but 64 are actually completed, we only get returned the
> > index of the 32nd op AFAIK.
>
> Right, that's correct - last_idx is the ring_idx of the last operation
> *reported by the call*, which is bounded by nb_cpls, not necessarily the
> last operation the device has completed. And as you point out this applies
> to both APIs. How about making that explicit, e.g. for completed_status():
>
> @param[out] last_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).
>
> and the equivalent (with the "successfully completed" wording) for
> rte_dma_completed()? If that reads well I'll send it as v2.
>
I think that would be much clearer, thanks.
^ permalink raw reply
* Re: [PATCH] dmadev: clarify last_idx documentation for completion APIs
From: Raghavendra Ningoji @ 2026-07-14 11:00 UTC (permalink / raw)
To: Bruce Richardson, dev
Cc: Raghavendra Ningoji, fengchengwen, Kevin Laatz, David Marchand,
Thomas Monjalon, Selwin.Sebastian, Bhagyada Modali
In-Reply-To: <alXt5X6MsOEy_5IX@bricha3-mobl1.ger.corp.intel.com>
On Tue, 14 Jul 2026, Bruce Richardson <bruce.richardson@intel.com> wrote:
>
> Just wondering if completed is ambiguous here. The index is that of the
> last reported operation, right? So if we request completed status of e.g.
> 32 operations, but 64 are actually completed, we only get returned the
> index of the 32nd op AFAIK.
Right, that's correct - last_idx is the ring_idx of the last operation
*reported by the call*, which is bounded by nb_cpls, not necessarily the
last operation the device has completed. And as you point out this applies
to both APIs. How about making that explicit, e.g. for completed_status():
@param[out] last_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).
and the equivalent (with the "successfully completed" wording) for
rte_dma_completed()? If that reads well I'll send it as v2.
Thanks,
Raghavendra
^ permalink raw reply
* Re: [PATCH v1] tools: ai review fix uninitialized variable
From: Thomas Monjalon @ 2026-07-14 10:27 UTC (permalink / raw)
To: Matthew Gee; +Cc: dev, stephen, aconole, lylavoie
In-Reply-To: <20260713161128.2338643-1-mgee@iol.unh.edu>
13/07/2026 18:11, Matthew Gee:
> There was a previously introduced bug where the curr_state variable in
> the classify_review function would be potentially uninitialized. This
> would cause the script to crash when the variable was used during the
> analysis of the AI review text.
>
> This patch fixes the bug by initializing the variable before it is used
> during the parsing of the AI review text.
>
> Fixes: 18b85df67daa ("devtools: fix AI review result classification")
>
> Signed-off-by: Matthew Gee <mgee@iol.unh.edu>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH v5 00/18] net/dpaa: bug fixes for bus, net and fmlib drivers
From: Thomas Monjalon @ 2026-07-14 10:21 UTC (permalink / raw)
To: Hemant Agrawal; +Cc: stephen, dev
In-Reply-To: <20260713101747.2947405-1-hemant.agrawal@nxp.com>
13/07/2026 12:17, Hemant Agrawal:
> Gagandeep Singh (3):
> bus/dpaa: fix device probe issue
> net/dpaa: fix invalid check on interrupt unregister
> net/dpaa: fix device remove
>
> Hemant Agrawal (11):
> bus/dpaa: fix error handling of qman_create_fq
> bus/dpaa: fix fqid endianness
> bus/dpaa: fix error handling in qman_query
> net/dpaa: fix modify cgr to use index
> bus/dpaa: fix fd leak for ccsr mmap
> net/dpaa: fix xstat name for tx undersized counter
> net/dpaa: fix xstat string typos in BMI stats table
> net/dpaa: remove duplicate ptype entries
> net/dpaa: fix wrong buffer in xstats get by id
> net/dpaa: fix null l3_len check in checksum offload
> net/dpaa: fix mbuf leak in SG fd creation
>
> Jun Yang (1):
> bus/dpaa: fix BMI RX stats register offset
>
> Prashant Gupta (1):
> net/dpaa/fmlib: add null check in scheme delete
>
> Vanshika Shukla (2):
> net/dpaa: fix port_handle leak in fm_prev_cleanup
> dma/dpaa: fix out-of-bounds access in SG descriptor enqueue
We don't care the cause of a bug in the subject of the fix.
The most important is to reflect clearly the consequence,
the scope of the impact in words easy to quickly read.
Also, acronyms should be uppercased.
Applied with better titles.
Note there are still issues detected by AI but it is late
and merging in this release was explicitly requested.
^ permalink raw reply
* [DPDK/core Bug 1968] [dpdk-26.07] ABI testing dpdk26.07+dpdk25.11 meson_tests/power_kvm_vm_autotest: TEST FAILED
From: bugzilla @ 2026-07-14 9:43 UTC (permalink / raw)
To: dev
http://bugs.dpdk.org/show_bug.cgi?id=1968
Bug ID: 1968
Summary: [dpdk-26.07] ABI testing dpdk26.07+dpdk25.11
meson_tests/power_kvm_vm_autotest: TEST FAILED
Product: DPDK
Version: 26.07
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: Normal
Component: core
Assignee: dev@dpdk.org
Reporter: yux.jiang@intel.com
Target Milestone: ---
Environment
-----------
DPDK version:
[DPDK 26.07rc3]
Steps to reproduce
------------------
1, Build latest dpdk(dpdk26.07rc3)
cd dpdk
rm -rf x86_64-native-linuxapp-gcc
CC=gcc meson -Dlibdir=lib -Dc_args=-DRTE_BUILD_SHARED_LIB
--default-library=shared x86_64-native-linuxapp-gcc
ninja -C x86_64-native-linuxapp-gcc
rm -rf /root/tmp/dpdk_share_lib /root/shared_lib_dpdk
DESTDIR=/root/tmp/dpdk_share_lib ninja -C x86_64-native-linuxapp-gcc -j 110
install
mv /root/tmp/dpdk_share_lib/usr/local/lib /root/shared_lib_dpdk
cat /root/.bashrc | grep LD_LIBRARY_PATH
sed -i 's#export LD_LIBRARY_PATH=.*#export
LD_LIBRARY_PATH=/root/shared_lib_dpdk#g' /root/.bashrc
2, copy LTS(dpdk25.11) dpdk_abi.tar.gz and build LTS dpdk
tar zxf /tmp/dpdk_abi.tar.gz -C ~
cd ~/dpdk/
rm -rf x86_64-native-linuxapp-gcc
CC=gcc meson -Dlibdir=lib -Dc_args=-DRTE_BUILD_SHARED_LIB
--default-library=shared x86_64-native-linuxapp-gcc
ninja -C x86_64-native-linuxapp-gcc
rm -rf x86_64-native-linuxapp-gcc/lib
rm -rf x86_64-native-linuxapp-gcc/drivers
3, do meson test
meson test -C x86_64-native-linuxapp-gcc power_kvm_vm_autotest -t 24
--num-processes 20 --test-args '-l 1-8 -d /root/shared_lib_dpdk'
Show the output from the previous commands.
-------------------------------------------
FAIL
Expected Result
---------------
Test OK
Is this issue a regression: Y
-----------------------------
0cec08732d (3-0cec08732d-f) power: validate lcore ID in cpufreq framework
Need fix or not? pls confirm
----------------------------
--
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply
* [DPDK/core Bug 1967] [dpdk-26.07] ABI testing dpdk26.07+dpdk25.11 meson_tests/test_fasts vdev_autotest and devargs_autotest both failed
From: bugzilla @ 2026-07-14 9:35 UTC (permalink / raw)
To: dev
http://bugs.dpdk.org/show_bug.cgi?id=1967
Bug ID: 1967
Summary: [dpdk-26.07] ABI testing dpdk26.07+dpdk25.11
meson_tests/test_fasts vdev_autotest and
devargs_autotest both failed
Product: DPDK
Version: 26.07
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: Normal
Component: core
Assignee: dev@dpdk.org
Reporter: yux.jiang@intel.com
Target Milestone: ---
Environment
-----------
DPDK version:
[DPDK 26.07rc3]
Steps to reproduce
------------------
1, Build latest dpdk(dpdk26.07rc3)
cd dpdk
rm -rf x86_64-native-linuxapp-gcc
CC=gcc meson -Dlibdir=lib -Dc_args=-DRTE_BUILD_SHARED_LIB
--default-library=shared x86_64-native-linuxapp-gcc
ninja -C x86_64-native-linuxapp-gcc
rm -rf /root/tmp/dpdk_share_lib /root/shared_lib_dpdk
DESTDIR=/root/tmp/dpdk_share_lib ninja -C x86_64-native-linuxapp-gcc -j 110
install
mv /root/tmp/dpdk_share_lib/usr/local/lib /root/shared_lib_dpdk
cat /root/.bashrc | grep LD_LIBRARY_PATH
sed -i 's#export LD_LIBRARY_PATH=.*#export
LD_LIBRARY_PATH=/root/shared_lib_dpdk#g' /root/.bashrc
2, copy LTS(dpdk25.11) dpdk_abi.tar.gz and build LTS dpdk
tar zxf /tmp/dpdk_abi.tar.gz -C ~
cd ~/dpdk/
rm -rf x86_64-native-linuxapp-gcc
CC=gcc meson -Dlibdir=lib -Dc_args=-DRTE_BUILD_SHARED_LIB
--default-library=shared x86_64-native-linuxapp-gcc
ninja -C x86_64-native-linuxapp-gcc
rm -rf x86_64-native-linuxapp-gcc/lib
rm -rf x86_64-native-linuxapp-gcc/drivers
3, do meson test
meson test -C x86_64-native-linuxapp-gcc --suite DPDK:fast-tests
devargs_autotest vdev_autotest -t 24 --num-processes 20 --test-args '-l 1-8 -d
/root/shared_lib_dpdk'
Show the output from the previous commands.
-------------------------------------------
FAIL
root@icx-jy-abi-d81:~/dpdk# MALLOC_PERTURB_=132
LD_LIBRARY_PATH=/root/dpdk/x86_64-native-linuxapp-gcc/lib:/root/dpdk/x86_64-native-linuxapp-gcc/drivers:/root/shared_lib_dpdk
MESON_TEST_ITERATION=1 DPDK_TEST=vdev_autotest
UBSAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1:print_stacktrace=1
MSAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1:print_stacktrace=1
ASAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1
/root/dpdk/x86_64-native-linuxapp-gcc/app/dpdk-test --no-huge -m 2048 -d
/root/dpdk/x86_64-native-linuxapp-gcc/drivers -l 1-8 -d /root/shared_lib_dpdk
EAL: Detected CPU lcores: 160
EAL: Detected NUMA nodes: 2
EAL: Detected shared linkage of DPDK
EAL: Multi-process socket /var/run/dpdk/rte/mp_socket
EAL: Selected IOVA mode 'VA'
EAL: VFIO support initialized
APP: HPET is not enabled, using TSC as default timer
RTE>>vdev_autotest
== test vdev bus ==
Segmentation fault (core dumped)
Expected Result
---------------
Test OK
Is this issue a regression: Y
-----------------------------
devargs_autotest bad commit: d03dbd4003 bus: support multiple probe
vdev_autotest bad commit: 89127f66f5 bus: consolidate device lookup
Need fix or not? pls confirm
----------------------------
--
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply
* RE: [PATCH v4 05/10] net/iavf: fix duplicate MAC addresses install
From: Loftus, Ciara @ 2026-07-14 9:23 UTC (permalink / raw)
To: David Marchand
Cc: dev@dpdk.org, rjarry@redhat.com, cfontain@redhat.com,
stable@dpdk.org, Medvedkin, Vladimir, Richardson, Bruce
In-Reply-To: <CAJFAV8xbkajqm+BPF+-+24NvT7XG4Rv=tB7ci4M6BSg+0roD8w@mail.gmail.com>
> Subject: Re: [PATCH v4 05/10] net/iavf: fix duplicate MAC addresses install
>
> On Mon, 13 Jul 2026 at 15:14, Loftus, Ciara <ciara.loftus@intel.com> wrote:
> >
> > > Subject: [PATCH v4 05/10] net/iavf: fix duplicate MAC addresses install
> > >
> > > On port restart, all MAC addresses get pushed *twice* to the hardware,
> > > once by the driver and once by the eth_dev_mac_restore() in ethdev.
> > >
> > > On the other hand, MAC address filters are reset in the hardware
> > > by the PF only when a VF reset is triggered.
> > >
> > > Strictly speaking, the mac restore on port (re)start is unneeded,
> > > if no VF reset happened, so we can announce to ethdev that no mac
> > > restoration is needed via a get_restore_flags callback.
> > >
> > > Then, move the mac restoration to the VF reset handler.
> > >
> > > Fixes: 3d42086def30 ("net/iavf: preserve MAC address with i40e PF Linux
> > > driver")
> > > Cc: stable@dpdk.org
> > >
> > > Signed-off-by: David Marchand <david.marchand@redhat.com>
> > > ---
> > > drivers/net/intel/iavf/iavf_ethdev.c | 31 ++++++++++++++++++++--------
> > > 1 file changed, 22 insertions(+), 9 deletions(-)
> > >
> > > diff --git a/drivers/net/intel/iavf/iavf_ethdev.c
> > > b/drivers/net/intel/iavf/iavf_ethdev.c
> > > index 179d90ec55..fe54df4b9f 100644
> > > --- a/drivers/net/intel/iavf/iavf_ethdev.c
> > > +++ b/drivers/net/intel/iavf/iavf_ethdev.c
> > > @@ -134,6 +134,8 @@ static int iavf_dev_vlan_filter_set(struct
> rte_eth_dev
> > > *dev,
> > > static int iavf_vlan_tpid_set(struct rte_eth_dev *dev,
> > > enum rte_vlan_type vlan_type, uint16_t tpid);
> > > static int iavf_dev_vlan_offload_set(struct rte_eth_dev *dev, int mask);
> > > +static uint64_t iavf_get_restore_flags(struct rte_eth_dev *dev,
> > > + enum rte_eth_dev_operation op);
> > > static int iavf_dev_rss_reta_update(struct rte_eth_dev *dev,
> > > struct rte_eth_rss_reta_entry64 *reta_conf,
> > > uint16_t reta_size);
> > > @@ -264,6 +266,7 @@ static const struct eth_dev_ops iavf_eth_dev_ops
> = {
> > > .tx_done_cleanup = iavf_dev_tx_done_cleanup,
> > > .get_monitor_addr = iavf_get_monitor_addr,
> > > .tm_ops_get = iavf_tm_ops_get,
> > > + .get_restore_flags = iavf_get_restore_flags,
> > > };
> > >
> > > static int
> > > @@ -284,6 +287,13 @@ iavf_tm_ops_get(struct rte_eth_dev *dev,
> > > return 0;
> > > }
> > >
> > > +static uint64_t
> > > +iavf_get_restore_flags(__rte_unused struct rte_eth_dev *dev,
> > > + __rte_unused enum rte_eth_dev_operation op)
> > > +{
> > > + return RTE_ETH_RESTORE_ALL & ~RTE_ETH_RESTORE_MAC_ADDR;
> > > +}
> > > +
> > > __rte_unused
> > > static int
> > > iavf_vfr_inprogress(struct iavf_hw *hw)
> > > @@ -1074,15 +1084,14 @@ iavf_dev_start(struct rte_eth_dev *dev)
> > > rte_intr_enable(intr_handle);
> > > }
> > >
> > > - /* Set all mac addrs */
> > > - iavf_add_del_all_mac_addr(adapter, true);
> > > -
> > > - if (!adapter->mac_primary_set)
> > > - adapter->mac_primary_set = true;
> > > -
> > > - /* Set all multicast addresses */
> > > - iavf_add_del_mc_addr_list(adapter, vf->mc_addrs, vf-
> > > >mc_addrs_num,
> > > - true);
> > > + if (!adapter->mac_primary_set) {
> > > + if (iavf_add_del_eth_addr(adapter, &dev->data-
> > > >mac_addrs[0], true,
> > > + VIRTCHNL_ETHER_ADDR_PRIMARY) != 0)
> > > + PMD_DRV_LOG(ERR, "failed to add primary MAC:"
> > > RTE_ETHER_ADDR_PRT_FMT,
> > > + RTE_ETHER_ADDR_BYTES(&dev->data-
> > > >mac_addrs[0]));
> > > + else
> > > + adapter->mac_primary_set = true;
> > > + }
> > >
> > > rte_spinlock_init(&vf->phc_time_aq_lock);
> > >
> > > @@ -3424,6 +3433,10 @@ iavf_handle_hw_reset(struct rte_eth_dev
> *dev,
> > > bool vf_initiated_reset)
> > > if (ret)
> > > goto error;
> > >
> > > + /* after a VF reset, all mac addresses got flushed, restore them
> > > */
> > > + iavf_add_del_all_mac_addr(adapter, true);
> > > + iavf_add_del_mc_addr_list(adapter, vf->mc_addrs, vf-
> > > >mc_addrs_num, true);
> > > +
> >
> > This restore block only runs if the device was started when the handler was
> > entered. It might make more sense to move it into iavf_post_reset_reconfig
> > which will run for VF-initiated resets regardless of started state, and for
> > PF-initiated will run if the device was started on entry.
> > For PF-initiated if the device was not started we return from
> > iavf_handle_hw_reset() immediately, so there's no opportunity to restore
> > the MAC addresses at all. It needs to be considered how to restore the macs
> > in that case.
> > Need to consider as well how the restore_flags and auto_reconfig features
> > work with one another. If the auto_reconfig devarg is set to zero it means
> > the user doesn't want any restoration of settings upon reset.
>
> I was not aware of this knob.
> It seems crazy to me to have such specific flag to disable something
> that I take foregranted during the life of a DPDK port.
> I really hope no application relies on the mac addresses list being
> flushed during a VF reset...
I think it's reasonable to keep the MAC restore outside of auto_reconfig,
that also preserves the existing behaviour of restoring MACs on reset.
But with your patch the restore is skipped whenever the port was stopped at
reset entry. Will the MACs be restored on the next dev_start?
>
> While moving the code to iavf_post_reset_reconfig kind of makes sense
> to me, I honesly don't know what to do wrt restore_flags.
> It seems orthogonal to me.
> If ethdev decides to restore the mac addresses, I don't see why some
> devargs would have something to say about it.
I agree ethdev should take precedence over the devarg. One option is to
have iavf_post_reset_reconfig honour the same restore_flags mask the normal
start path uses, so the two paths don't diverge. I don't think you need to
address that in your set, it's something I can look into.
And I agree the flag is quite specific. I think its main use is during a VF
initiated reset, the user may want to reset the VF completely and not
restore anything. I think instead of a devarg I could address this by
adding a parameter to the dev-private rte_pmd_iavf_reinit API. I'll look
into this too. Definitely room for improvement here around the reset path.
>
>
> --
> David Marchand
^ permalink raw reply
* Re: [PATCH] dmadev: clarify last_idx documentation for completion APIs
From: Bruce Richardson @ 2026-07-14 8:05 UTC (permalink / raw)
To: Raghavendra Ningoji
Cc: dev, fengchengwen, Kevin Laatz, selwin.sebastian, bhagyada.modali,
David Marchand, Thomas Monjalon
In-Reply-To: <20260714074954.3412248-1-raghavendra.ningoji@amd.com>
On Tue, Jul 14, 2026 at 01:19:54PM +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.
>
> Clarify both descriptions to remove the ambiguity.
>
> Fixes: 91e581e5c924 ("dmadev: add data plane API")
>
> Signed-off-by: Raghavendra Ningoji <raghavendra.ningoji@amd.com>
> ---
> lib/dmadev/rte_dmadev.h | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/lib/dmadev/rte_dmadev.h b/lib/dmadev/rte_dmadev.h
> index 81dfe187e2..394ee8bfdc 100644
> --- a/lib/dmadev/rte_dmadev.h
> +++ b/lib/dmadev/rte_dmadev.h
> @@ -1338,7 +1338,7 @@ 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 last successfully completed operation's ring_idx.
> * If not required, NULL can be passed in.
> * @param[out] has_error
> * Indicates if there are transfer error.
> @@ -1397,7 +1397,8 @@ 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 last completed operation's ring_idx, regardless of whether it
> + * completed successfully or with an error.
Just wondering if completed is ambiguous here. The index is that of the
last reported operation, right? So if we request completed status of e.g.
32 operations, but 64 are actually completed, we only get returned the
index of the 32nd op AFAIK.
/Bruce
> * 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
* Re: [PATCH v5 3/4] dma/ae4dma: add data path operations
From: Raghavendra Ningoji @ 2026-07-14 7:53 UTC (permalink / raw)
To: fengchengwen, dev
Cc: Raghavendra Ningoji, David Marchand, Bruce Richardson,
Selwin.Sebastian, Bhagyada Modali, Robin Jarry, Thomas Monjalon
In-Reply-To: <c5331090-0d39-4479-8de5-44b95d364b55>
On Fri, 10 Jul 2026, fengchengwen <fengchengwen@huawei.com> wrote:
>
> I think it is necessary to update.
> Please also update rte_dma_completed_status, both in a separate patch
Done - sent as a separate patch updating both rte_dma_completed() and
rte_dma_completed_status():
[PATCH] dmadev: clarify last_idx documentation for completion APIs
Thanks,
Raghavendra
^ permalink raw reply
* [PATCH] dmadev: clarify last_idx documentation for completion APIs
From: Raghavendra Ningoji @ 2026-07-14 7:49 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.
Clarify both descriptions to remove the ambiguity.
Fixes: 91e581e5c924 ("dmadev: add data plane API")
Signed-off-by: Raghavendra Ningoji <raghavendra.ningoji@amd.com>
---
lib/dmadev/rte_dmadev.h | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/lib/dmadev/rte_dmadev.h b/lib/dmadev/rte_dmadev.h
index 81dfe187e2..394ee8bfdc 100644
--- a/lib/dmadev/rte_dmadev.h
+++ b/lib/dmadev/rte_dmadev.h
@@ -1338,7 +1338,7 @@ 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 last successfully completed operation's ring_idx.
* If not required, NULL can be passed in.
* @param[out] has_error
* Indicates if there are transfer error.
@@ -1397,7 +1397,8 @@ 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 last completed operation's ring_idx, regardless of whether it
+ * completed successfully or with an error.
* 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
* [PATCH v2] net/mlx5: avoid wildcard drop flow in priority discovery
From: Gavin Hu @ 2026-07-14 6:07 UTC (permalink / raw)
To: dev
Cc: Wei Yan, stable, Dariusz Sosnowski, Viacheslav Ovsiienko,
Bing Zhao, Ori Kam, Suanming Mou, Matan Azrad, Ophir Munk,
Dmitry Kozlyuk
In-Reply-To: <20260713041856.67144-1-gahu@nvidia.com>
From: Wei Yan <yanwei.wy@bytedance.com>
Priority discovery installs temporary drop flows to probe supported flow
priorities. These flows match a wildcard Ethernet pattern, so they can
also match real traffic while discovery is running. On shared devices this
may temporarily drop kernel traffic and cause TCP connection timeouts.
Constrain the probe flows to match both source and destination MAC
addresses as ff:ff:ff:ff:ff:ff. This keeps the rule valid for discovery
while avoiding matches on normal Ethernet traffic.
Fixes: 3eca5f8a610e ("net/mlx5: move flow priority discovery to Verbs file")
Fixes: c5042f93a425 ("net/mlx5: discover max flow priority using DevX")
Cc: stable@dpdk.org
Signed-off-by: Wei Yan <yanwei.wy@bytedance.com>
Signed-off-by: Gavin Hu <gahu@nvidia.com>
---
+v2:
+* Fixed the compiling issue by some compilers in mlx5_flow_verbs.c.
drivers/net/mlx5/mlx5_flow_dv.c | 18 ++++++++++++++++++
drivers/net/mlx5/mlx5_flow_verbs.c | 8 ++++++++
2 files changed, 26 insertions(+)
diff --git a/drivers/net/mlx5/mlx5_flow_dv.c b/drivers/net/mlx5/mlx5_flow_dv.c
index 58ebcf87eb..9cb7c59b83 100644
--- a/drivers/net/mlx5/mlx5_flow_dv.c
+++ b/drivers/net/mlx5/mlx5_flow_dv.c
@@ -19794,6 +19794,22 @@ mlx5_flow_discover_dr_action_support(struct rte_eth_dev *dev)
void *matcher = NULL;
void *flow = NULL;
int ret = -1;
+ struct rte_flow_item_eth eth;
+ struct rte_flow_item item = {
+ .type = RTE_FLOW_ITEM_TYPE_ETH,
+ .spec = ð,
+ .mask = ð,
+ };
+
+ memset(ð, 0, sizeof(eth));
+ memset(ð.hdr.dst_addr, 0xff, sizeof(eth.hdr.dst_addr));
+ memset(ð.hdr.src_addr, 0xff, sizeof(eth.hdr.src_addr));
+ flow_dv_translate_item_eth(mask.buf, &item,
+ /* inner */ false, /* group */ 0,
+ MLX5_SET_MATCHER_SW_M);
+ flow_dv_translate_item_eth(value.buf, &item,
+ /* inner */ false, /* group */ 0,
+ MLX5_SET_MATCHER_SW_V);
tbl = mlx5_flow_dv_tbl_resource_get(dev, 0, 0, 0, false, NULL,
0, 0, 0, NULL);
@@ -20683,6 +20699,8 @@ flow_dv_discover_priorities(struct rte_eth_dev *dev,
flow.dv.actions[0] = action;
flow.dv.actions_n = 1;
memset(ð, 0, sizeof(eth));
+ memset(ð.hdr.dst_addr, 0xff, sizeof(eth.hdr.dst_addr));
+ memset(ð.hdr.src_addr, 0xff, sizeof(eth.hdr.src_addr));
flow_dv_translate_item_eth(matcher.mask.buf, &item,
/* inner */ false, /* group */ 0,
MLX5_SET_MATCHER_SW_M);
diff --git a/drivers/net/mlx5/mlx5_flow_verbs.c b/drivers/net/mlx5/mlx5_flow_verbs.c
index bb240d38d9..eb576f73d4 100644
--- a/drivers/net/mlx5/mlx5_flow_verbs.c
+++ b/drivers/net/mlx5/mlx5_flow_verbs.c
@@ -65,6 +65,14 @@ flow_verbs_discover_priorities(struct rte_eth_dev *dev,
.eth = {
.type = IBV_FLOW_SPEC_ETH,
.size = sizeof(struct ibv_flow_spec_eth),
+ .val = {
+ .dst_mac = {0xff, 0xff, 0xff, 0xff, 0xff, 0xff},
+ .src_mac = {0xff, 0xff, 0xff, 0xff, 0xff, 0xff},
+ },
+ .mask = {
+ .dst_mac = {0xff, 0xff, 0xff, 0xff, 0xff, 0xff},
+ .src_mac = {0xff, 0xff, 0xff, 0xff, 0xff, 0xff},
+ },
},
.drop = {
.size = sizeof(struct ibv_flow_spec_action_drop),
--
2.27.0
^ permalink raw reply related
* please help backporting some patches to stable release 24.11.7
From: luca.boccassi @ 2026-07-13 17:22 UTC (permalink / raw)
To: dpdk
Cc: dpdk stable, Akhil Goyal, Ankur Dwivedi, Anoob Joseph,
Archana Muniganti, Ferruh Yigit, Jack Bond-Preston, Jerin Jacob,
Konstantin Ananyev, Morten Brørup, Ravi Kumar,
Siraj Luthfi Ananda, Stephen Hemminger, Sunil Uttarwar,
Tejasree Kondoj, Zbigniew Bodek
Hi commit authors (and maintainers),
Despite being selected by the DPDK maintenance tool ./devtools/git-log-fixes.sh
I didn't apply following commits from DPDK main to 24.11
stable branch, as conflicts or build errors occur.
Can authors check your patches in the following list and either:
- Backport your patches to the 24.11 branch, or
- Indicate that the patch should not be backported
Please do either of the above by 2026/07/20.
You can find the a temporary work-in-progress branch of the coming 24.11.7
release at:
https://github.com/bluca/dpdk-stable
It is recommended to backport on top of that to minimize further conflicts or
misunderstandings.
Some notes on stable backports:
A backport should contain a reference to the DPDK main branch commit
in it's commit message in the following fashion:
[ upstream commit <commit's dpdk main branch SHA-1 checksum> ]
For example:
https://git.dpdk.org/dpdk-stable/commit/?h=18.11&id=d90e6ae6f936ecdc2fd3811ff9f26aec7f3c06eb
When sending the backported patch, please indicate the target branch in the
subject line, as we have multiple branches, for example:
[PATCH 24.11] foo/bar: fix baz
With git format-patch, this can be achieved by appending the parameter:
--subject-prefix='PATCH 24.11'
Send the backported patch to "stable@dpdk.org" but not "dev@dpdk.org".
FYI, branch 24.11 is located at tree:
https://git.dpdk.org/dpdk-stable
Thanks.
Luca Boccassi
---
d84f4082f8 Stephen Hemminger crypto/armv8: use timing-safe digest comparison
752589fb45 Stephen Hemminger crypto/ccp: use timing-safe digest comparison
f72517b8e7 Stephen Hemminger crypto/cnxk: use timing-safe digest comparison
^ permalink raw reply
* [PATCH v1] tools: ai review fix uninitialized variable
From: Matthew Gee @ 2026-07-13 16:11 UTC (permalink / raw)
To: dev; +Cc: stephen, aconole, lylavoie, Matthew Gee
There was a previously introduced bug where the curr_state variable in
the classify_review function would be potentially uninitialized. This
would cause the script to crash when the variable was used during the
analysis of the AI review text.
This patch fixes the bug by initializing the variable before it is used
during the parsing of the AI review text.
Fixes: 18b85df67daa ("devtools: fix AI review result classification")
Signed-off-by: Matthew Gee <mgee@iol.unh.edu>
---
devtools/ai/review-patch.py | 1 +
1 file changed, 1 insertion(+)
diff --git a/devtools/ai/review-patch.py b/devtools/ai/review-patch.py
index 3705ca8209..5f8d9ed772 100755
--- a/devtools/ai/review-patch.py
+++ b/devtools/ai/review-patch.py
@@ -159,6 +159,7 @@ def classify_review(review_text: str, output_format: str) -> int:
rgx_header_match: str = r"(#+\s)?(\*+)?(<h[1-3]>)?{err_or_warn}"
# Matches against observed filler text
rgx_filler_match: str = r"(none(.)?$|\(must fix\)$|$)"
+ curr_state: ReviewParseState = ReviewParseState.NORMAL
curr_line: str
for curr_line in review_text.splitlines():
--
2.54.0
^ permalink raw reply related
* Re: [PATCH v4 05/10] net/iavf: fix duplicate MAC addresses install
From: David Marchand @ 2026-07-13 14:10 UTC (permalink / raw)
To: Loftus, Ciara
Cc: dev@dpdk.org, rjarry@redhat.com, cfontain@redhat.com,
stable@dpdk.org, Medvedkin, Vladimir, Richardson, Bruce
In-Reply-To: <IA4PR11MB92781CFE503B95525EC366AF8EFA2@IA4PR11MB9278.namprd11.prod.outlook.com>
On Mon, 13 Jul 2026 at 15:14, Loftus, Ciara <ciara.loftus@intel.com> wrote:
>
> > Subject: [PATCH v4 05/10] net/iavf: fix duplicate MAC addresses install
> >
> > On port restart, all MAC addresses get pushed *twice* to the hardware,
> > once by the driver and once by the eth_dev_mac_restore() in ethdev.
> >
> > On the other hand, MAC address filters are reset in the hardware
> > by the PF only when a VF reset is triggered.
> >
> > Strictly speaking, the mac restore on port (re)start is unneeded,
> > if no VF reset happened, so we can announce to ethdev that no mac
> > restoration is needed via a get_restore_flags callback.
> >
> > Then, move the mac restoration to the VF reset handler.
> >
> > Fixes: 3d42086def30 ("net/iavf: preserve MAC address with i40e PF Linux
> > driver")
> > Cc: stable@dpdk.org
> >
> > Signed-off-by: David Marchand <david.marchand@redhat.com>
> > ---
> > drivers/net/intel/iavf/iavf_ethdev.c | 31 ++++++++++++++++++++--------
> > 1 file changed, 22 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/net/intel/iavf/iavf_ethdev.c
> > b/drivers/net/intel/iavf/iavf_ethdev.c
> > index 179d90ec55..fe54df4b9f 100644
> > --- a/drivers/net/intel/iavf/iavf_ethdev.c
> > +++ b/drivers/net/intel/iavf/iavf_ethdev.c
> > @@ -134,6 +134,8 @@ static int iavf_dev_vlan_filter_set(struct rte_eth_dev
> > *dev,
> > static int iavf_vlan_tpid_set(struct rte_eth_dev *dev,
> > enum rte_vlan_type vlan_type, uint16_t tpid);
> > static int iavf_dev_vlan_offload_set(struct rte_eth_dev *dev, int mask);
> > +static uint64_t iavf_get_restore_flags(struct rte_eth_dev *dev,
> > + enum rte_eth_dev_operation op);
> > static int iavf_dev_rss_reta_update(struct rte_eth_dev *dev,
> > struct rte_eth_rss_reta_entry64 *reta_conf,
> > uint16_t reta_size);
> > @@ -264,6 +266,7 @@ static const struct eth_dev_ops iavf_eth_dev_ops = {
> > .tx_done_cleanup = iavf_dev_tx_done_cleanup,
> > .get_monitor_addr = iavf_get_monitor_addr,
> > .tm_ops_get = iavf_tm_ops_get,
> > + .get_restore_flags = iavf_get_restore_flags,
> > };
> >
> > static int
> > @@ -284,6 +287,13 @@ iavf_tm_ops_get(struct rte_eth_dev *dev,
> > return 0;
> > }
> >
> > +static uint64_t
> > +iavf_get_restore_flags(__rte_unused struct rte_eth_dev *dev,
> > + __rte_unused enum rte_eth_dev_operation op)
> > +{
> > + return RTE_ETH_RESTORE_ALL & ~RTE_ETH_RESTORE_MAC_ADDR;
> > +}
> > +
> > __rte_unused
> > static int
> > iavf_vfr_inprogress(struct iavf_hw *hw)
> > @@ -1074,15 +1084,14 @@ iavf_dev_start(struct rte_eth_dev *dev)
> > rte_intr_enable(intr_handle);
> > }
> >
> > - /* Set all mac addrs */
> > - iavf_add_del_all_mac_addr(adapter, true);
> > -
> > - if (!adapter->mac_primary_set)
> > - adapter->mac_primary_set = true;
> > -
> > - /* Set all multicast addresses */
> > - iavf_add_del_mc_addr_list(adapter, vf->mc_addrs, vf-
> > >mc_addrs_num,
> > - true);
> > + if (!adapter->mac_primary_set) {
> > + if (iavf_add_del_eth_addr(adapter, &dev->data-
> > >mac_addrs[0], true,
> > + VIRTCHNL_ETHER_ADDR_PRIMARY) != 0)
> > + PMD_DRV_LOG(ERR, "failed to add primary MAC:"
> > RTE_ETHER_ADDR_PRT_FMT,
> > + RTE_ETHER_ADDR_BYTES(&dev->data-
> > >mac_addrs[0]));
> > + else
> > + adapter->mac_primary_set = true;
> > + }
> >
> > rte_spinlock_init(&vf->phc_time_aq_lock);
> >
> > @@ -3424,6 +3433,10 @@ iavf_handle_hw_reset(struct rte_eth_dev *dev,
> > bool vf_initiated_reset)
> > if (ret)
> > goto error;
> >
> > + /* after a VF reset, all mac addresses got flushed, restore them
> > */
> > + iavf_add_del_all_mac_addr(adapter, true);
> > + iavf_add_del_mc_addr_list(adapter, vf->mc_addrs, vf-
> > >mc_addrs_num, true);
> > +
>
> This restore block only runs if the device was started when the handler was
> entered. It might make more sense to move it into iavf_post_reset_reconfig
> which will run for VF-initiated resets regardless of started state, and for
> PF-initiated will run if the device was started on entry.
> For PF-initiated if the device was not started we return from
> iavf_handle_hw_reset() immediately, so there's no opportunity to restore
> the MAC addresses at all. It needs to be considered how to restore the macs
> in that case.
> Need to consider as well how the restore_flags and auto_reconfig features
> work with one another. If the auto_reconfig devarg is set to zero it means
> the user doesn't want any restoration of settings upon reset.
I was not aware of this knob.
It seems crazy to me to have such specific flag to disable something
that I take foregranted during the life of a DPDK port.
I really hope no application relies on the mac addresses list being
flushed during a VF reset...
While moving the code to iavf_post_reset_reconfig kind of makes sense
to me, I honesly don't know what to do wrt restore_flags.
It seems orthogonal to me.
If ethdev decides to restore the mac addresses, I don't see why some
devargs would have something to say about it.
--
David Marchand
^ permalink raw reply
* RE: sxe2 driver bug due to mempool layer violation
From: Morten Brørup @ 2026-07-13 14:07 UTC (permalink / raw)
To: Jie Liu, Stephen Hemminger; +Cc: dev
In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35F6596A@smartserver.smartshare.dk>
> From: Morten Brørup [mailto:mb@smartsharesystems.com]
> Sent: Monday, 13 July 2026 14.05
>
> Hi Jie Liu,
>
> Your sxe2 driver is accessing the flushthresh field in the mempool
> structure [1].
> This field is obsolete, as the mempool cache algorithm has been updated
> [2].
> If you need to bypass the mempool API and work directly with mempool
> internals, please keep your code up to date with the internals of the
> mempool library implementation.
>
> Please submit an updated version of your driver, or the patch to
> support AVX512 needs to be reverted. Jie Liu
As a temporary quick-fix, you can update the comparison on line 70 as:
- if (cache->len >= cache->flushthresh) {
+ if (cache->len > cache->size) {
>
> It looks like your driver introduced something similar to what the
> Intel common drivers were previously doing [3]; the Intel common
> drivers were updated accordingly [4].
>
> [1]: https://github.com/DPDK/dpdk/blob/v26.07-
> rc3/drivers/net/sxe2/sxe2_txrx_vec_avx512.c#L70
> [2]:
> https://github.com/DPDK/dpdk/commit/f5e1310f16e0909e7e7f71807123644c63b
> 23cba
> [3]:
> https://github.com/DPDK/dpdk/blob/v26.03/drivers/net/intel/common/tx.h#
> L315
> [4]:
> https://github.com/DPDK/dpdk/commit/062d6fe5d00d837ecb1a2b77b4a306e3619
> a7fde
>
^ permalink raw reply
* RE: [PATCH v4 05/10] net/iavf: fix duplicate MAC addresses install
From: Loftus, Ciara @ 2026-07-13 13:12 UTC (permalink / raw)
To: David Marchand, dev@dpdk.org
Cc: rjarry@redhat.com, cfontain@redhat.com, stable@dpdk.org,
Medvedkin, Vladimir, Richardson, Bruce
In-Reply-To: <20260709160247.1798575-6-david.marchand@redhat.com>
> Subject: [PATCH v4 05/10] net/iavf: fix duplicate MAC addresses install
>
> On port restart, all MAC addresses get pushed *twice* to the hardware,
> once by the driver and once by the eth_dev_mac_restore() in ethdev.
>
> On the other hand, MAC address filters are reset in the hardware
> by the PF only when a VF reset is triggered.
>
> Strictly speaking, the mac restore on port (re)start is unneeded,
> if no VF reset happened, so we can announce to ethdev that no mac
> restoration is needed via a get_restore_flags callback.
>
> Then, move the mac restoration to the VF reset handler.
>
> Fixes: 3d42086def30 ("net/iavf: preserve MAC address with i40e PF Linux
> driver")
> Cc: stable@dpdk.org
>
> Signed-off-by: David Marchand <david.marchand@redhat.com>
> ---
> drivers/net/intel/iavf/iavf_ethdev.c | 31 ++++++++++++++++++++--------
> 1 file changed, 22 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/net/intel/iavf/iavf_ethdev.c
> b/drivers/net/intel/iavf/iavf_ethdev.c
> index 179d90ec55..fe54df4b9f 100644
> --- a/drivers/net/intel/iavf/iavf_ethdev.c
> +++ b/drivers/net/intel/iavf/iavf_ethdev.c
> @@ -134,6 +134,8 @@ static int iavf_dev_vlan_filter_set(struct rte_eth_dev
> *dev,
> static int iavf_vlan_tpid_set(struct rte_eth_dev *dev,
> enum rte_vlan_type vlan_type, uint16_t tpid);
> static int iavf_dev_vlan_offload_set(struct rte_eth_dev *dev, int mask);
> +static uint64_t iavf_get_restore_flags(struct rte_eth_dev *dev,
> + enum rte_eth_dev_operation op);
> static int iavf_dev_rss_reta_update(struct rte_eth_dev *dev,
> struct rte_eth_rss_reta_entry64 *reta_conf,
> uint16_t reta_size);
> @@ -264,6 +266,7 @@ static const struct eth_dev_ops iavf_eth_dev_ops = {
> .tx_done_cleanup = iavf_dev_tx_done_cleanup,
> .get_monitor_addr = iavf_get_monitor_addr,
> .tm_ops_get = iavf_tm_ops_get,
> + .get_restore_flags = iavf_get_restore_flags,
> };
>
> static int
> @@ -284,6 +287,13 @@ iavf_tm_ops_get(struct rte_eth_dev *dev,
> return 0;
> }
>
> +static uint64_t
> +iavf_get_restore_flags(__rte_unused struct rte_eth_dev *dev,
> + __rte_unused enum rte_eth_dev_operation op)
> +{
> + return RTE_ETH_RESTORE_ALL & ~RTE_ETH_RESTORE_MAC_ADDR;
> +}
> +
> __rte_unused
> static int
> iavf_vfr_inprogress(struct iavf_hw *hw)
> @@ -1074,15 +1084,14 @@ iavf_dev_start(struct rte_eth_dev *dev)
> rte_intr_enable(intr_handle);
> }
>
> - /* Set all mac addrs */
> - iavf_add_del_all_mac_addr(adapter, true);
> -
> - if (!adapter->mac_primary_set)
> - adapter->mac_primary_set = true;
> -
> - /* Set all multicast addresses */
> - iavf_add_del_mc_addr_list(adapter, vf->mc_addrs, vf-
> >mc_addrs_num,
> - true);
> + if (!adapter->mac_primary_set) {
> + if (iavf_add_del_eth_addr(adapter, &dev->data-
> >mac_addrs[0], true,
> + VIRTCHNL_ETHER_ADDR_PRIMARY) != 0)
> + PMD_DRV_LOG(ERR, "failed to add primary MAC:"
> RTE_ETHER_ADDR_PRT_FMT,
> + RTE_ETHER_ADDR_BYTES(&dev->data-
> >mac_addrs[0]));
> + else
> + adapter->mac_primary_set = true;
> + }
>
> rte_spinlock_init(&vf->phc_time_aq_lock);
>
> @@ -3424,6 +3433,10 @@ iavf_handle_hw_reset(struct rte_eth_dev *dev,
> bool vf_initiated_reset)
> if (ret)
> goto error;
>
> + /* after a VF reset, all mac addresses got flushed, restore them
> */
> + iavf_add_del_all_mac_addr(adapter, true);
> + iavf_add_del_mc_addr_list(adapter, vf->mc_addrs, vf-
> >mc_addrs_num, true);
> +
This restore block only runs if the device was started when the handler was
entered. It might make more sense to move it into iavf_post_reset_reconfig
which will run for VF-initiated resets regardless of started state, and for
PF-initiated will run if the device was started on entry.
For PF-initiated if the device was not started we return from
iavf_handle_hw_reset() immediately, so there's no opportunity to restore
the MAC addresses at all. It needs to be considered how to restore the macs
in that case.
Need to consider as well how the restore_flags and auto_reconfig features
work with one another. If the auto_reconfig devarg is set to zero it means
the user doesn't want any restoration of settings upon reset.
> dev->data->dev_started = 1;
> }
>
> --
> 2.54.0
^ permalink raw reply
* Re: [PATCH v4 0/4] add versioned symbols for recently stabilized APIs
From: David Marchand @ 2026-07-13 12:46 UTC (permalink / raw)
To: Dariusz Sosnowski
Cc: Bruce Richardson, NBU-Contact-Thomas Monjalon (EXTERNAL),
Andrew Rybchenko, Slava Ovsiienko, Bing Zhao, Ori Kam,
Suanming Mou, Matan Azrad, dev@dpdk.org, Yu Jiang
In-Reply-To: <PH0PR12MB70779D26817E22DC927E8860A4FA2@PH0PR12MB7077.namprd12.prod.outlook.com>
On Mon, 13 Jul 2026 at 13:05, Dariusz Sosnowski <dsosnowski@nvidia.com> wrote:
> > LGTM.
> > Series applied, thanks Dariusz.
> >
> > Please send the patch to drop this compat in 26.11.
>
> Patches for dropping these compatibility aliases are on the mailing list:
>
> - https://patches.dpdk.org/project/dpdk/patch/20260713105935.24152-1-dsosnowski@nvidia.com/
> - https://patches.dpdk.org/project/dpdk/patch/20260713110101.24218-1-dsosnowski@nvidia.com/
Thank you.
Those lgtm, I delegated them to me, and marked as deferred.
I'll take them with rc0.
--
David Marchand
^ permalink raw reply
* sxe2 driver bug due to mempool layer violation
From: Morten Brørup @ 2026-07-13 12:04 UTC (permalink / raw)
To: Jie Liu, Stephen Hemminger; +Cc: dev
Hi Jie Liu,
Your sxe2 driver is accessing the flushthresh field in the mempool structure [1].
This field is obsolete, as the mempool cache algorithm has been updated [2].
If you need to bypass the mempool API and work directly with mempool internals, please keep your code up to date with the internals of the mempool library implementation.
Please submit an updated version of your driver, or the patch to support AVX512 needs to be reverted.
It looks like your driver introduced something similar to what the Intel common drivers were previously doing [3]; the Intel common drivers were updated accordingly [4].
[1]: https://github.com/DPDK/dpdk/blob/v26.07-rc3/drivers/net/sxe2/sxe2_txrx_vec_avx512.c#L70
[2]: https://github.com/DPDK/dpdk/commit/f5e1310f16e0909e7e7f71807123644c63b23cba
[3]: https://github.com/DPDK/dpdk/blob/v26.03/drivers/net/intel/common/tx.h#L315
[4]: https://github.com/DPDK/dpdk/commit/062d6fe5d00d837ecb1a2b77b4a306e3619a7fde
Venlig hilsen / Kind regards,
-Morten Brørup
^ permalink raw reply
* Re: [PATCH v2] net/mlx5: fallback to verbs for Tx memory allocation if devx unsupported
From: Dariusz Sosnowski @ 2026-07-13 11:15 UTC (permalink / raw)
To: banoth.saikumar; +Cc: viacheslavo, bingz, dev, stable
In-Reply-To: <20260630102311.1050-1-banoth.saikumar@oracle.com>
On Tue, Jun 30, 2026 at 03:53:11PM +0530, banoth.saikumar@oracle.com wrote:
> From: Banoth Saikumar <banoth.saikumar@oracle.com>
>
> Previously, the mlx5 PMD attempted to allocate consecutive Tx memory
> using DevX without checking whether the NIC actually supported DevX.
> This led to allocation failures on legacy or unsupported NICs.
>
> This patch adds a fallback mechanism: if DevX is not available, the PMD
> skips DevX-based allocation and allows the verbs path to handle memory
> allocation and registration. This improves compatibility with older
> NICs and ensures Tx queue setup proceeds correctly.
>
> Fixes: bbfab2eb2528 ("net/mlx5: allocate and release unique
> resources for Tx queues")
> Cc: stable@dpdk.org
>
> Signed-off-by: Banoth Saikumar <banoth.saikumar@oracle.com>
Acked-by: Dariusz Sosnowski <dsosnowski@nvidia.com>
^ permalink raw reply
* RE: [PATCH v4 0/4] add versioned symbols for recently stabilized APIs
From: Dariusz Sosnowski @ 2026-07-13 11:05 UTC (permalink / raw)
To: David Marchand
Cc: Bruce Richardson, NBU-Contact-Thomas Monjalon (EXTERNAL),
Andrew Rybchenko, Slava Ovsiienko, Bing Zhao, Ori Kam,
Suanming Mou, Matan Azrad, dev@dpdk.org, Yu Jiang
In-Reply-To: <CAJFAV8zwKcABUr5kWV429+k_r=Wr=eSkGTLDymogtysobXMAwQ@mail.gmail.com>
> -----Original Message-----
> From: David Marchand <david.marchand@redhat.com>
> Sent: Sunday, June 28, 2026 3:57 PM
> To: Dariusz Sosnowski <dsosnowski@nvidia.com>
> Cc: Bruce Richardson <bruce.richardson@intel.com>; NBU-Contact-Thomas
> Monjalon (EXTERNAL) <thomas@monjalon.net>; Andrew Rybchenko
> <andrew.rybchenko@oktetlabs.ru>; Slava Ovsiienko
> <viacheslavo@nvidia.com>; Bing Zhao <bingz@nvidia.com>; Ori Kam
> <orika@nvidia.com>; Suanming Mou <suanmingm@nvidia.com>; Matan
> Azrad <matan@nvidia.com>; dev@dpdk.org; Yu Jiang <yux.jiang@intel.com>
> Subject: Re: [PATCH v4 0/4] add versioned symbols for recently stabilized APIs
>
> External email: Use caution opening links or attachments
>
>
> Hello Dariusz,
>
> On Thu, 25 Jun 2026 at 18:08, Dariusz Sosnowski <dsosnowski@nvidia.com>
> wrote:
> >
> > Main goal of this patchset is to address
> https://bugs.dpdk.org/show_bug.cgi?id=1957
> > but it also handles other recently stabilized symbols and has some minor
> fixes:
> >
> > - Patch 1 - Fix RTE_VERSION_EXPERIMENTAL_SYMBOL macro on clang.
> > - Patch 2 - Allow function versioning inside drivers.
> > - Patch 3 - Version the function symbols stabilized in
> >
> https://git.dpdk.org/dpdk/commit/?id=e8cab133645f5466ef75e511629add43
> b68a5027
> > - Patch 4 - Version the rte_flow_dynf_metadata_register() function stabilized
> in
> >
> https://git.dpdk.org/dpdk/commit/?id=4ee2f5c1cedf9ee7f39afa667f71b07f40
> 04ba5c
> > Restore EXPERIMENTAL version on global variable symbols
> > rte_flow_dynf_metadata_offs and rte_flow_dynf_metadata_mask.
> >
> > v4:
> > - Fixed build with older meson versions.
> >
> > v3:
> > - https://inbox.dpdk.org/dev/20260625133311.1299705-1-
> dsosnowski@nvidia.com/
> > - Added rebuilding of drivers with -DRTE_BUILD_SHARED_LIB
> > whenever function versioning is enabled.
> >
> > v2:
> > - https://inbox.dpdk.org/dev/20260624131337.1127323-1-
> dsosnowski@nvidia.com/
> > - Drop patches introducing versioning macros for symbol aliases
> > and their usage (patch 4 and 5 from v1)
> > - EXPERIMENTAL version on global variable symbols
> > rte_flow_dynf_metadata_offs and rte_flow_dynf_metadata_mask,
> > as discussed under v1.
> > - Change commit title prefix in patch (2) from "drivers" to "build".
> >
> > v1: https://inbox.dpdk.org/dev/20260623113752.1100072-1-
> dsosnowski@nvidia.com/
> >
> > Dariusz Sosnowski (4):
> > eal: fix macro for versioned experimental symbol
> > build: support function versioning for drivers
> > net/mlx5: fix stabilized function versions
> > ethdev: fix promoted flow metadata symbols
> >
> > drivers/meson.build | 21 ++++++++++++++++++++-
> > drivers/net/mlx5/meson.build | 2 ++
> > drivers/net/mlx5/mlx5_driver_event.c | 22 ++++++++++++++++------
> > drivers/net/mlx5/mlx5_flow.c | 18 ++++++++++++------
> > lib/eal/common/eal_export.h | 2 +-
> > lib/ethdev/meson.build | 2 ++
> > lib/ethdev/rte_flow.c | 13 ++++++++-----
> > 7 files changed, 61 insertions(+), 19 deletions(-)
>
> LGTM.
> Series applied, thanks Dariusz.
>
> Please send the patch to drop this compat in 26.11.
Patches for dropping these compatibility aliases are on the mailing list:
- https://patches.dpdk.org/project/dpdk/patch/20260713105935.24152-1-dsosnowski@nvidia.com/
- https://patches.dpdk.org/project/dpdk/patch/20260713110101.24218-1-dsosnowski@nvidia.com/
Best regards,
Dariusz Sosnowski
^ permalink raw reply
* [PATCH 26.11] net/mlx5: remove versioned symbols aliases
From: Dariusz Sosnowski @ 2026-07-13 11:01 UTC (permalink / raw)
To: David Marchand, Viacheslav Ovsiienko, Bing Zhao, Ori Kam,
Suanming Mou, Matan Azrad
Cc: dev
Version symbols added in [1] for functions:
- rte_pmd_mlx5_driver_event_cb_register
- rte_pmd_mlx5_driver_event_cb_unregister
- rte_pmd_mlx5_enable_steering
- rte_pmd_mlx5_disable_steering
are not needed after ABI version bump.
This patch removes versioned symbols.
[1]: 556b2a33727a ("net/mlx5: add aliases for some promoted symbols")
Signed-off-by: Dariusz Sosnowski <dsosnowski@nvidia.com>
---
drivers/net/mlx5/meson.build | 2 --
drivers/net/mlx5/mlx5_driver_event.c | 22 ++++++----------------
drivers/net/mlx5/mlx5_flow.c | 18 ++++++------------
3 files changed, 12 insertions(+), 30 deletions(-)
diff --git a/drivers/net/mlx5/meson.build b/drivers/net/mlx5/meson.build
index 0fa6322779..82a7dfe782 100644
--- a/drivers/net/mlx5/meson.build
+++ b/drivers/net/mlx5/meson.build
@@ -2,8 +2,6 @@
# Copyright 2018 6WIND S.A.
# Copyright 2018 Mellanox Technologies, Ltd
-use_function_versioning = true
-
if not (is_linux or is_windows)
build = false
reason = 'only supported on Linux and Windows'
diff --git a/drivers/net/mlx5/mlx5_driver_event.c b/drivers/net/mlx5/mlx5_driver_event.c
index d0e22d6151..89e49331c8 100644
--- a/drivers/net/mlx5/mlx5_driver_event.c
+++ b/drivers/net/mlx5/mlx5_driver_event.c
@@ -236,8 +236,9 @@ notify_existing_devices(rte_pmd_mlx5_driver_event_callback_t cb, void *opaque)
notify_existing_queues(port_id, cb, opaque);
}
-RTE_DEFAULT_SYMBOL(26, int, rte_pmd_mlx5_driver_event_cb_register,
- (rte_pmd_mlx5_driver_event_callback_t cb, void *opaque))
+RTE_EXPORT_SYMBOL(rte_pmd_mlx5_driver_event_cb_register)
+int
+rte_pmd_mlx5_driver_event_cb_register(rte_pmd_mlx5_driver_event_callback_t cb, void *opaque)
{
struct registered_cb *r;
@@ -263,14 +264,9 @@ RTE_DEFAULT_SYMBOL(26, int, rte_pmd_mlx5_driver_event_cb_register,
return 0;
}
-RTE_VERSION_EXPERIMENTAL_SYMBOL(int, rte_pmd_mlx5_driver_event_cb_register,
- (rte_pmd_mlx5_driver_event_callback_t cb, void *opaque))
-{
- return rte_pmd_mlx5_driver_event_cb_register(cb, opaque);
-}
-
-RTE_DEFAULT_SYMBOL(26, int, rte_pmd_mlx5_driver_event_cb_unregister,
- (rte_pmd_mlx5_driver_event_callback_t cb))
+RTE_EXPORT_SYMBOL(rte_pmd_mlx5_driver_event_cb_unregister)
+int
+rte_pmd_mlx5_driver_event_cb_unregister(rte_pmd_mlx5_driver_event_callback_t cb)
{
struct registered_cb *r;
bool found = false;
@@ -293,12 +289,6 @@ RTE_DEFAULT_SYMBOL(26, int, rte_pmd_mlx5_driver_event_cb_unregister,
return 0;
}
-RTE_VERSION_EXPERIMENTAL_SYMBOL(int, rte_pmd_mlx5_driver_event_cb_unregister,
- (rte_pmd_mlx5_driver_event_callback_t cb))
-{
- return rte_pmd_mlx5_driver_event_cb_unregister(cb);
-}
-
RTE_FINI(rte_pmd_mlx5_driver_event_cb_cleanup) {
struct registered_cb *r;
diff --git a/drivers/net/mlx5/mlx5_flow.c b/drivers/net/mlx5/mlx5_flow.c
index e8141d2100..b0eac185b5 100644
--- a/drivers/net/mlx5/mlx5_flow.c
+++ b/drivers/net/mlx5/mlx5_flow.c
@@ -12537,7 +12537,9 @@ flow_disable_steering_run_on_related(struct rte_eth_dev *dev,
}
}
-RTE_DEFAULT_SYMBOL(26, void, rte_pmd_mlx5_disable_steering, (void))
+RTE_EXPORT_SYMBOL(rte_pmd_mlx5_disable_steering)
+void
+rte_pmd_mlx5_disable_steering(void)
{
uint16_t port_id;
@@ -12561,12 +12563,9 @@ RTE_DEFAULT_SYMBOL(26, void, rte_pmd_mlx5_disable_steering, (void))
mlx5_steering_disabled = true;
}
-RTE_VERSION_EXPERIMENTAL_SYMBOL(void, rte_pmd_mlx5_disable_steering, (void))
-{
- rte_pmd_mlx5_disable_steering();
-}
-
-RTE_DEFAULT_SYMBOL(26, int, rte_pmd_mlx5_enable_steering, (void))
+RTE_EXPORT_SYMBOL(rte_pmd_mlx5_enable_steering)
+int
+rte_pmd_mlx5_enable_steering(void)
{
uint16_t port_id;
@@ -12583,11 +12582,6 @@ RTE_DEFAULT_SYMBOL(26, int, rte_pmd_mlx5_enable_steering, (void))
return 0;
}
-RTE_VERSION_EXPERIMENTAL_SYMBOL(int, rte_pmd_mlx5_enable_steering, (void))
-{
- return rte_pmd_mlx5_enable_steering();
-}
-
bool
mlx5_vport_rx_metadata_passing_enabled(const struct mlx5_dev_ctx_shared *sh)
{
--
2.47.3
^ permalink raw reply related
* [PATCH 26.11] ethdev: remove flow metadata symbol aliases
From: Dariusz Sosnowski @ 2026-07-13 10:59 UTC (permalink / raw)
To: David Marchand, Thomas Monjalon, Andrew Rybchenko, Ori Kam; +Cc: dev
Version aliases for rte_flow_dynf_metadata_register
and EXPERIMENTAL version on rte_flow_dynf_metadata_offs
and rte_flow_dynf_metadata_mask symbols added in [1]
are not needed after ABI version bump.
This patch removes them.
[1]: 56045d198968 ("ethdev: add aliases for flow metadata symbols")
Signed-off-by: Dariusz Sosnowski <dsosnowski@nvidia.com>
---
lib/ethdev/meson.build | 2 --
lib/ethdev/rte_flow.c | 13 +++++--------
2 files changed, 5 insertions(+), 10 deletions(-)
diff --git a/lib/ethdev/meson.build b/lib/ethdev/meson.build
index 63fd866af9..8ba6c708a2 100644
--- a/lib/ethdev/meson.build
+++ b/lib/ethdev/meson.build
@@ -1,8 +1,6 @@
# SPDX-License-Identifier: BSD-3-Clause
# Copyright(c) 2017 Intel Corporation
-use_function_versioning = true
-
sources = files(
'ethdev_driver.c',
'ethdev_private.c',
diff --git a/lib/ethdev/rte_flow.c b/lib/ethdev/rte_flow.c
index 651630b2f8..60c9a3d06f 100644
--- a/lib/ethdev/rte_flow.c
+++ b/lib/ethdev/rte_flow.c
@@ -23,11 +23,11 @@
#define FLOW_LOG RTE_ETHDEV_LOG_LINE
/* Mbuf dynamic field name for metadata. */
-RTE_EXPORT_EXPERIMENTAL_SYMBOL(rte_flow_dynf_metadata_offs, 19.11)
+RTE_EXPORT_SYMBOL(rte_flow_dynf_metadata_offs)
int32_t rte_flow_dynf_metadata_offs = -1;
/* Mbuf dynamic field flag bit number for metadata. */
-RTE_EXPORT_EXPERIMENTAL_SYMBOL(rte_flow_dynf_metadata_mask, 19.11)
+RTE_EXPORT_SYMBOL(rte_flow_dynf_metadata_mask)
uint64_t rte_flow_dynf_metadata_mask;
/**
@@ -282,7 +282,9 @@ static const struct rte_flow_desc_data rte_flow_desc_action[] = {
MK_FLOW_ACTION(JUMP_TO_TABLE_INDEX, sizeof(struct rte_flow_action_jump_to_table_index)),
};
-RTE_DEFAULT_SYMBOL(26, int, rte_flow_dynf_metadata_register, (void))
+RTE_EXPORT_SYMBOL(rte_flow_dynf_metadata_register)
+int
+rte_flow_dynf_metadata_register(void)
{
int offset;
int flag;
@@ -315,11 +317,6 @@ RTE_DEFAULT_SYMBOL(26, int, rte_flow_dynf_metadata_register, (void))
return -rte_errno;
}
-RTE_VERSION_EXPERIMENTAL_SYMBOL(int, rte_flow_dynf_metadata_register, (void))
-{
- return rte_flow_dynf_metadata_register();
-}
-
static inline void
fts_enter(struct rte_eth_dev *dev)
{
--
2.47.3
^ permalink raw reply related
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