* Re: [PATCH v3 4/6] net/ice: timestamp all received packets when PTP is enabled
From: Bruce Richardson @ 2026-06-30 15:39 UTC (permalink / raw)
To: Dawid Wesierski; +Cc: dev, thomas, stephen, marek.kasiewicz
In-Reply-To: <20260630120657.1046588-5-dawid.wesierski@intel.com>
On Tue, Jun 30, 2026 at 08:06:54AM -0400, Dawid Wesierski wrote:
> From: Marek Kasiewicz <marek.kasiewicz@intel.com>
>
> When PTP is enabled on the ICE PMD, hardware RX timestamps are only
> applied to packets classified as IEEE 1588 (Ethertype 0x88F7). This
> prevents applications from obtaining hardware timestamps on regular
> UDP/IP traffic.
>
> Remove the TIMESYNC packet type filter so that all received packets
> get hardware timestamps when PTP is enabled. This is required for
> time-sensitive networking applications that need per-packet arrival
> timing on media traffic, such as ST 2110-21 receiver compliance
> monitoring.
>
> The change affects all three RX paths: scan, scattered, and single
> packet receive functions.
>
> Signed-off-by: Marek Kasiewicz <marek.kasiewicz@intel.com>
> Signed-off-by: Dawid Wesierski <dawid.wesierski@intel.com>
> ---
> drivers/net/intel/ice/ice_rxtx.c | 9 +++------
> 1 file changed, 3 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/net/intel/ice/ice_rxtx.c b/drivers/net/intel/ice/ice_rxtx.c
> index c4b5454c53..8d709125f7 100644
> --- a/drivers/net/intel/ice/ice_rxtx.c
> +++ b/drivers/net/intel/ice/ice_rxtx.c
> @@ -2023,8 +2023,7 @@ ice_rx_scan_hw_ring(struct ci_rx_queue *rxq)
> pkt_flags |= rxq->ts_flag;
> }
>
> - if (ad->ptp_ena && ((mb->packet_type &
> - RTE_PTYPE_L2_MASK) == RTE_PTYPE_L2_ETHER_TIMESYNC)) {
> + if (ad->ptp_ena) {
Dropping this condition means that all packets are now marked as PTP
packets, even though they are not, which is incorrect. At minimum we need
to check the packet type before setting the PTP flag on them.
However, at a higher level again, I think if we want timestamps for all
packets that that should be a separate feature from PTP support, which
should be more limited in scope. I see there is already an
RTE_ETH_RX_OFFLOAD_TIMESTAMP block above this in the code - does specifying
that offload flag not cause all packets to get properly timestamped? If
not, I would suggest that that be enhanced rather than pretending all
packets are PTP. If that doesn't work, do we need a third alternative,
perhaps?
Regards,
/Bruce
> rxq->time_high =
> rte_le_to_cpu_32(rxdp[j].wb.flex_ts.ts_high);
> mb->timesync = rxq->queue_id;
> @@ -2390,8 +2389,7 @@ ice_recv_scattered_pkts(void *rx_queue,
> pkt_flags |= rxq->ts_flag;
> }
>
> - if (ad->ptp_ena && ((first_seg->packet_type & RTE_PTYPE_L2_MASK)
> - == RTE_PTYPE_L2_ETHER_TIMESYNC)) {
> + if (ad->ptp_ena) {
> rxq->time_high =
> rte_le_to_cpu_32(rxd.wb.flex_ts.ts_high);
> first_seg->timesync = rxq->queue_id;
> @@ -2881,8 +2879,7 @@ ice_recv_pkts(void *rx_queue,
> pkt_flags |= rxq->ts_flag;
> }
>
> - if (ad->ptp_ena && ((rxm->packet_type & RTE_PTYPE_L2_MASK) ==
> - RTE_PTYPE_L2_ETHER_TIMESYNC)) {
> + if (ad->ptp_ena) {
> rxq->time_high =
> rte_le_to_cpu_32(rxd.wb.flex_ts.ts_high);
> rxm->timesync = rxq->queue_id;
> --
> 2.47.3
>
> ---------------------------------------------------------------------
> Intel Technology Poland sp. z o.o.
> ul. Slowackiego 173 | 80-298 Gdansk | Sad Rejonowy Gdansk Polnoc | VII Wydzial Gospodarczy Krajowego Rejestru Sadowego - KRS 101882 | NIP 957-07-52-316 | Kapital zakladowy 200.000 PLN.
> Spolka oswiadcza, ze posiada status duzego przedsiebiorcy w rozumieniu ustawy z dnia 8 marca 2013 r. o przeciwdzialaniu nadmiernym opoznieniom w transakcjach handlowych.
>
> Ta wiadomosc wraz z zalacznikami jest przeznaczona dla okreslonego adresata i moze zawierac informacje poufne. W razie przypadkowego otrzymania tej wiadomosci, prosimy o powiadomienie nadawcy oraz trwale jej usuniecie; jakiekolwiek przegladanie lub rozpowszechnianie jest zabronione.
> This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). If you are not the intended recipient, please contact the sender and delete all copies; any review or distribution by others is strictly prohibited.
>
^ permalink raw reply
* Re: [PATCH v3 5/6] net/iavf: disable runtime queue setup capability
From: Bruce Richardson @ 2026-06-30 15:44 UTC (permalink / raw)
To: Dawid Wesierski; +Cc: dev, thomas, stephen, marek.kasiewicz
In-Reply-To: <20260630120657.1046588-6-dawid.wesierski@intel.com>
On Tue, Jun 30, 2026 at 08:06:55AM -0400, Dawid Wesierski wrote:
> From: Marek Kasiewicz <marek.kasiewicz@intel.com>
>
> Remove the advertisement of RTE_ETH_DEV_CAPA_RUNTIME_RX_QUEUE_SETUP
> and RTE_ETH_DEV_CAPA_RUNTIME_TX_QUEUE_SETUP capabilities from the
> iavf VF driver.
>
> Runtime queue setup on E810 VFs causes queue state corruption when
> queues are dynamically reconfigured while the hardware rate limiter
> is actively pacing TX queues. Queue configuration messages to the PF
> via virtchnl can race with ongoing TX operations, leading to undefined
> behavior.
>
> By not advertising these capabilities, all queues are configured at
> port start and remain stable throughout the port lifecycle.
>
> Signed-off-by: Marek Kasiewicz <marek.kasiewicz@intel.com>
> Signed-off-by: Dawid Wesierski <dawid.wesierski@intel.com>
> ---
> doc/guides/nics/intel_vf.rst | 9 +++++++++
> doc/guides/rel_notes/release_26_07.rst | 2 ++
> drivers/net/intel/iavf/iavf.h | 1 +
> drivers/net/intel/iavf/iavf_ethdev.c | 22 ++++++++++++++++++----
> 4 files changed, 30 insertions(+), 4 deletions(-)
>
> diff --git a/doc/guides/nics/intel_vf.rst b/doc/guides/nics/intel_vf.rst
> index e010f852cf..86878330f2 100644
> --- a/doc/guides/nics/intel_vf.rst
> +++ b/doc/guides/nics/intel_vf.rst
> @@ -131,6 +131,15 @@ IAVF PMD parameters
> * ``segment``: Check number of mbuf segments does not exceed HW limits.
> * ``offload``: Check for use of an unsupported offload flag.
>
> +``no_runtime_queue_setup``
> + Runtime (post-start) Rx/Tx queue setup can race with the hardware Tx rate
> + limiter on E810 VFs and corrupt queue state.
> + It is advertised by default.
> + Applications that pace queues through the traffic manager can opt out
> + of advertising the runtime queue setup capability
> + by setting ``no_runtime_queue_setup`` to 1,
> + for example, ``-a 18:01.0,no_runtime_queue_setup=1``.
> +
Do we really need a commandline arg for this? If it's known enough to have
the extra arg passed at device init, is it not also known enough to have
the app not do dynamic reconfiguration in the first place?
Alternatively, if the user configures packet pacing through rte_tm, can we
not at that point adjust the driver to disallow runtime config by returning
-ENOTSUP when reconfig is attempted, and no longer advertising the capabilities?
Runtime configuration, whether with or without user interaction, should be
preferred over devargs whenever possible.
/Bruce
^ permalink raw reply
* Re: [RFC] doc: updating doxy-api-index.md and doxy-api.conf.in
From: Thomas Monjalon @ 2026-06-30 16:10 UTC (permalink / raw)
To: Marat Khalili; +Cc: dev@dpdk.org
In-Reply-To: <f0e4ffa90e57467cb292d7888caa697e@huawei.com>
Hello,
30/06/2026 11:03, Marat Khalili:
> I noticed that a few header files contain docstring-like comments but are not
> present in doc/api/doxy-api-index.md and/or (fewer) in doc/api/doxy-api.conf.in
> There seem to be no checks anywhere in the process that would make sure these
> index files are updated. Do we even care, or is it unsupported legacy? If we do
> care, would a check or an automatic generation fix be more promising?
Some internal files have doxygen comments, not sure why,
probably to run Doxygen manually on these files.
In the scope of our public documentation,
the goal was to document all and only public API.
If you see some public API not referenced, it is a bug.
And yes a script to check this may be useful.
^ permalink raw reply
* [PATCH] net/e1000: align device IDs with base code
From: Bruce Richardson @ 2026-06-30 16:16 UTC (permalink / raw)
To: dev; +Cc: Bruce Richardson
The e1000 base header lists multiple PCI device IDs in e1000_hw.h that
are not present in the em PCI ID table. Add the missing IDs so DPDK can
probe all e1000 devices defined by the shared base code.
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
---
drivers/net/intel/e1000/em_ethdev.c | 70 +++++++++++++++++++++++++++++
1 file changed, 70 insertions(+)
diff --git a/drivers/net/intel/e1000/em_ethdev.c b/drivers/net/intel/e1000/em_ethdev.c
index 62ab57268f..c02d09e500 100644
--- a/drivers/net/intel/e1000/em_ethdev.c
+++ b/drivers/net/intel/e1000/em_ethdev.c
@@ -187,6 +187,76 @@ static const struct rte_pci_id pci_id_em_map[] = {
{ RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_PCH_RPL_I219_V23) },
{ RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_PCH_ARL_I219_LM24) },
{ RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_PCH_ARL_I219_V24) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_PCH_PTP_I219_LM25) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_PCH_PTP_I219_V25) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_PCH_WCL_I219_LM27) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_PCH_WCL_I219_V27) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_PCH_NVL_I219_LM29) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_PCH_NVL_I219_V29) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_80003ES2LAN_COPPER_DPT) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_80003ES2LAN_COPPER_SPT) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_80003ES2LAN_SERDES_DPT) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_80003ES2LAN_SERDES_SPT) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_82540EM_LOM) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_82540EP) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_82540EP_LOM) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_82540EP_LP) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_82541EI) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_82541EI_MOBILE) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_82541ER) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_82541ER_LOM) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_82541GI) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_82541GI_LF) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_82541GI_MOBILE) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_82542) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_82543GC_COPPER) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_82543GC_FIBER) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_82544EI_COPPER) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_82544EI_FIBER) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_82544GC_COPPER) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_82544GC_LOM) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_82545GM_COPPER) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_82545GM_FIBER) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_82545GM_SERDES) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_82546GB_COPPER) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_82546GB_FIBER) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_82546GB_PCIE) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_82546GB_QUAD_COPPER) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_82546GB_QUAD_COPPER_KSP3) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_82546GB_SERDES) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_82547EI) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_82547EI_MOBILE) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_82547GI) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_82573E) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_82573E_IAMT) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_ICH10_D_BM_LF) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_ICH10_D_BM_LM) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_ICH10_D_BM_V) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_ICH10_R_BM_LF) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_ICH10_R_BM_LM) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_ICH10_R_BM_V) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_ICH8_82567V_3) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_ICH8_IFE) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_ICH8_IFE_G) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_ICH8_IFE_GT) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_ICH8_IGP_AMT) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_ICH8_IGP_C) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_ICH8_IGP_M) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_ICH8_IGP_M_AMT) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_ICH9_BM) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_ICH9_IFE) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_ICH9_IFE_G) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_ICH9_IFE_GT) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_ICH9_IGP_AMT) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_ICH9_IGP_C) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_ICH9_IGP_M) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_ICH9_IGP_M_AMT) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_ICH9_IGP_M_V) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_PCH2_LV_V) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_PCH_D_HV_DC) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_PCH_D_HV_DM) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_PCH_M_HV_LC) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_PCH_M_HV_LM) },
{ .vendor_id = 0, /* sentinel */ },
};
--
2.53.0
^ permalink raw reply related
* Re: [RFC] doc: updating doxy-api-index.md and doxy-api.conf.in
From: Bruce Richardson @ 2026-06-30 16:45 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: Marat Khalili, dev@dpdk.org
In-Reply-To: <cesJxiasRY6aqEM1iZ_leA@monjalon.net>
On Tue, Jun 30, 2026 at 06:10:59PM +0200, Thomas Monjalon wrote:
> Hello,
>
> 30/06/2026 11:03, Marat Khalili:
> > I noticed that a few header files contain docstring-like comments but are not
> > present in doc/api/doxy-api-index.md and/or (fewer) in doc/api/doxy-api.conf.in
> > There seem to be no checks anywhere in the process that would make sure these
> > index files are updated. Do we even care, or is it unsupported legacy? If we do
> > care, would a check or an automatic generation fix be more promising?
>
> Some internal files have doxygen comments, not sure why,
> probably to run Doxygen manually on these files.
>
> In the scope of our public documentation,
> the goal was to document all and only public API.
>
> If you see some public API not referenced, it is a bug.
> And yes a script to check this may be useful.
>
Something like this could work as a quick check that all public headers are
getting indexed. Doesn't help with verifying that all contents within the
files have comments, but maybe its an easy start point:
diff --git a/drivers/meson.build b/drivers/meson.build
index 4d95604ecd..5a9ba68d54 100644
--- a/drivers/meson.build
+++ b/drivers/meson.build
@@ -278,6 +278,23 @@ foreach subpath:subdirs
dpdk_headers += headers
dpdk_drivers_headers += driver_sdk_headers
+ # On Linux, best-effort check that public headers are named correctly
+ # and that the driver directory is referenced in the Doxygen config so
+ # that its API gets indexed.
+ if is_linux and meson.version().version_compare('>= 0.59.0') and headers.length() > 0
+ foreach h:headers
+ hname = fs.name(h)
+ if not hname.startswith('rte_')
+ warning('drivers/@0@: public header "@1@" does not start with "rte_"'.format(drv_path, hname))
+ endif
+ endforeach
+ if run_command('grep', '-qF', '@TOPDIR@/drivers/' + drv_path,
+ dpdk_source_root / 'doc' / 'api' / 'doxy-api.conf.in',
+ check: false).returncode() != 0
+ warning('drivers/@0@: has public headers but not listed in doxy-api.conf.in'.format(drv_path))
+ endif
+ endif
+
if headers.length() > 0
dpdk_includes += include_directories(drv_path)
endif
diff --git a/lib/meson.build b/lib/meson.build
index af5c160cb8..d897b2c73a 100644
--- a/lib/meson.build
+++ b/lib/meson.build
@@ -209,6 +209,23 @@ foreach l:libraries
dpdk_indirect_headers += indirect_headers
dpdk_drivers_headers += driver_sdk_headers
+ # On Linux, best-effort check that public headers are named correctly
+ # and that the library directory is referenced in the Doxygen config so
+ # that its API gets indexed.
+ if is_linux and meson.version().version_compare('>= 0.59.0') and headers.length() > 0
+ foreach h:headers
+ hname = fs.name(h)
+ if not (hname.startswith('rte_') or hname.startswith('cmdline'))
+ warning('lib/@0@: public header "@1@" does not start with "rte_" or "cmdline"'.format(l, hname))
+ endif
+ endforeach
+ if run_command('grep', '-qF', '@TOPDIR@/lib/' + l,
+ dpdk_source_root / 'doc' / 'api' / 'doxy-api.conf.in',
+ check: false).returncode() != 0
+ warning('lib/@0@: has public headers but not listed in doxy-api.conf.in'.format(l))
+ endif
+ endif
+
libname = 'rte_' + name
includes += include_directories(l)
dpdk_includes += include_directories(l)
^ permalink raw reply related
* RE: [PATCH v2 0/6] crypto: use timing-safe digest comparison
From: Morten Brørup @ 2026-06-30 17:22 UTC (permalink / raw)
To: Stephen Hemminger, dev
In-Reply-To: <20260629190027.2071745-1-stephen@networkplumber.org>
Series-acked-by: Morten Brørup <mb@smartsharesystems.com>
^ permalink raw reply
* Re: [PATCH] net/idpf: fix Tx of large mbuf segments
From: Medvedkin, Vladimir @ 2026-06-30 17:35 UTC (permalink / raw)
To: Bruce Richardson, dev
Cc: anatoly.burakov, stable, Jingjing Wu, Praveen Shetty, Xiaoyun Li,
Beilei Xing, Junfeng Guo
In-Reply-To: <20260626134440.2108591-1-bruce.richardson@intel.com>
Hi Bruce,
There is possible tx ring overflow after a new internal loop is added.
I'd suggest to add into account "nb_used" by moving "if (txq->nb_tx_free
< tx_pkt->nb_segs)" check right after "nb_used" was calculated.
On 6/26/2026 2:43 PM, Bruce Richardson wrote:
> When TSO is enabled, and we get a packet to transmit where an individual
> mbuf segment is longer than 16k, we need to split that segment across
> multiple Tx descriptors. This support is present in the single-queue
> mode of idpf - since it shares common code with the other Intel drivers
> - but was missing from the splitq path.
>
> This patch adds the proper data path handling. Previous work ensured
> that the descriptor count calculation took over-sized segments into
> account but the actual descriptor writing part was overlooked.
>
> Fixes: 770f4dfe0f79 ("net/idpf: support basic Tx data path")
> Fixes: 2904020f8313 ("net/intel: add common function to calculate needed descs")
> Cc: stable@dpdk.org
>
> Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> ---
> v2: rework implementation based on changes to the idpf driver
> since v1 was submitted.
> ---
> drivers/net/intel/idpf/idpf_common_rxtx.c | 37 ++++++++++++++++++++---
> 1 file changed, 32 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/net/intel/idpf/idpf_common_rxtx.c b/drivers/net/intel/idpf/idpf_common_rxtx.c
> index a123d969ee..8aa61a2af4 100644
> --- a/drivers/net/intel/idpf/idpf_common_rxtx.c
> +++ b/drivers/net/intel/idpf/idpf_common_rxtx.c
> @@ -994,16 +994,43 @@ idpf_dp_splitq_xmit_pkts(void *tx_queue, struct rte_mbuf **tx_pkts,
> uint16_t first_sw_id = sw_id;
>
> do {
> + uint16_t slen = tx_pkt->data_len;
> + rte_iova_t buf_dma_addr = rte_mbuf_data_iova(tx_pkt);
> +
> + /* Split segment across multiple descriptors if needed
> + * for TSO packets where segment exceeds max buf size.
> + */
> + while ((ol_flags & RTE_MBUF_F_TX_TCP_SEG) &&
> + unlikely(slen > CI_MAX_DATA_PER_TXD)) {
> + txd = &txr[tx_id];
> + txn = &sw_ring[txe->next_id];
> + txe->mbuf = NULL;
> +
> + txd->buf_addr = rte_cpu_to_le_64(buf_dma_addr);
> + txd->qw1.cmd_dtype = cmd_dtype |
> + IDPF_TX_DESC_DTYPE_FLEX_FLOW_SCHE;
> + txd->qw1.rxr_bufsize = CI_MAX_DATA_PER_TXD;
> + txd->qw1.compl_tag = sw_id;
> +
> + buf_dma_addr += CI_MAX_DATA_PER_TXD;
> + slen -= CI_MAX_DATA_PER_TXD;
> +
> + tx_id++;
> + if (tx_id == txq->nb_tx_desc)
> + tx_id = 0;
> + sw_id = txe->next_id;
> + txe = txn;
> + }
> +
> txd = &txr[tx_id];
> txn = &sw_ring[txe->next_id];
> txe->mbuf = tx_pkt;
>
> /* Setup TX descriptor */
> - txd->buf_addr =
> - rte_cpu_to_le_64(rte_mbuf_data_iova(tx_pkt));
> - cmd_dtype |= IDPF_TX_DESC_DTYPE_FLEX_FLOW_SCHE;
> - txd->qw1.cmd_dtype = cmd_dtype;
> - txd->qw1.rxr_bufsize = tx_pkt->data_len;
> + txd->buf_addr = rte_cpu_to_le_64(buf_dma_addr);
> + txd->qw1.cmd_dtype = cmd_dtype |
> + IDPF_TX_DESC_DTYPE_FLEX_FLOW_SCHE;
> + txd->qw1.rxr_bufsize = slen;
> txd->qw1.compl_tag = sw_id;
> tx_id++;
> if (tx_id == txq->nb_tx_desc)
--
Regards,
Vladimir
^ permalink raw reply
* Re: [PATCH v2 8/8] doc: add release note about ip_frag changes
From: Stephen Hemminger @ 2026-06-30 19:19 UTC (permalink / raw)
To: dev
In-Reply-To: <20260630153723.525167-9-stephen@networkplumber.org>
On Tue, 30 Jun 2026 08:36:20 -0700
Stephen Hemminger <stephen@networkplumber.org> wrote:
> The changes to ip_frag might impact some conformance or
> performance tests.
>
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> ---
Recheck-request: github-robot: build
^ permalink raw reply
* RE: [PATCH v4 0/4] Wangxun fixes and new features
From: Zaiyu Wang @ 2026-07-01 2:08 UTC (permalink / raw)
To: 'Stephen Hemminger'; +Cc: dev
In-Reply-To: <20260630071555.0b0287b6@phoenix.local>
> On Tue, 30 Jun 2026 19:16:00 +0800
> Zaiyu Wang <zaiyuwang@trustnetic.com> wrote:
>
> > This patchset introduces three new features and critical fixes for our
> > recent release cycle.
> >
> > Patches 1-2 add support for UDP Segmentation Offload (USO) to improve
> > large-packet transmission performance for UDP workloads.
> >
> > Patch 3 enables VFs to sense PF ifconfig down/up events, allowing
> > better fault tolerance and fast recovery in virtualized environments.
> >
> > Patch 4 adds the missing VF support for the Amber-Lite 40G NICs, which
> > was previously omitted in the initial integration.
>
> Applied to net-next. Had to resolve a code merge conflict from earlier
> changes in net-next and also release note conflicts.
>
Thanks.
^ permalink raw reply
* [PATCH] pdump: fix request timeout on unresponsive secondary
From: Pushpendra Kumar @ 2026-07-01 6:02 UTC (permalink / raw)
To: dev; +Cc: pushpendra.kumar, reshma.pattan, stephen, stable,
Pushpendra Kumar
When a primary handles a pdump enable/disable request from a secondary
(e.g. dpdk-dumpcap), it applies the callbacks locally and forwards the
request to the other secondaries before replying. The forward used
rte_mp_request_sync(), blocking up to MP_TIMEOUT_S for every secondary
to acknowledge.
A secondary that is attached but has not called rte_pdump_init() never
registers the mp_pdump action and silently drops the message (logging
only "Cannot find action: mp_pdump"). Commit c3ceb8742295 ("pdump:
forward callback enable to secondary process"), which added this
broadcast, appears to assume every secondary calls rte_pdump_init();
when one does not, the primary cannot tell it from a slow or dead peer
and blocks for the full timeout. That delay pushes the reply past the
requester's own timeout, so dpdk-dumpcap reports "Packet dump enable
... failed Connection timed out".
Forward the request asynchronously with rte_mp_request_async() so an
unresponsive secondary can no longer block the reply; a callback logs a
warning if not all secondaries acknowledge. The forward is still issued
before the requester reply, preserving the ordering from commit
928f43e3f9c1 ("pdump: fix race in disabling").
This slightly weakens the happens-before guarantee: the sync call was a
full-acknowledgement barrier, whereas the async path relies on AF_UNIX
SOCK_DGRAM FIFO ordering and the single mp_handle thread processing the
forward before the reply that triggers teardown. This suffices for the
disable race fixed by 928f43e3f9c1, but reviewers should confirm they
are comfortable with the weaker guarantee.
Fixes: c3ceb8742295 ("pdump: forward callback enable to secondary process")
Cc: stable@dpdk.org
Signed-off-by: Pushpendra Kumar <pushpendra1x.kumar@intel.com>
---
.mailmap | 1 +
lib/pdump/rte_pdump.c | 23 ++++++++++++++---------
2 files changed, 15 insertions(+), 9 deletions(-)
diff --git a/.mailmap b/.mailmap
index c5bc728fae..c1313c7148 100644
--- a/.mailmap
+++ b/.mailmap
@@ -1332,6 +1332,7 @@ Przemyslaw Gierszynski <przemyslaw.gierszynski@intel.com>
Przemyslaw Patynowski <przemyslawx.patynowski@intel.com>
Przemyslaw Zegan <przemyslawx.zegan@intel.com>
Pu Xu <583493798@qq.com>
+Pushpendra Kumar <pushpendra1x.kumar@intel.com>
Qi Fu <qi.fu@intel.com>
Qi Zhang <qi.z.zhang@intel.com>
Qian Hao <qi_an_hao@126.com>
diff --git a/lib/pdump/rte_pdump.c b/lib/pdump/rte_pdump.c
index ac94efe7ff..f2d5b70111 100644
--- a/lib/pdump/rte_pdump.c
+++ b/lib/pdump/rte_pdump.c
@@ -477,11 +477,21 @@ set_pdump_rxtx_cbs(const struct pdump_request *p)
return ret;
}
+/* Async reply handler; warns if any secondary did not respond. */
+static int
+pdump_secondary_reply(const struct rte_mp_msg *request __rte_unused,
+ const struct rte_mp_reply *reply)
+{
+ if (reply->nb_sent != reply->nb_received)
+ PDUMP_LOG_LINE(ERR, "not all secondary's replied (sent %u recv %u)",
+ reply->nb_sent, reply->nb_received);
+ return 0;
+}
+
static void
pdump_request_to_secondary(const struct pdump_request *req)
{
struct rte_mp_msg mp_req = { };
- struct rte_mp_reply mp_reply;
struct timespec ts = {.tv_sec = MP_TIMEOUT_S, .tv_nsec = 0};
PDUMP_LOG_LINE(DEBUG, "forward req %s to secondary", pdump_opname(req->op));
@@ -490,14 +500,9 @@ pdump_request_to_secondary(const struct pdump_request *req)
strlcpy(mp_req.name, PDUMP_MP, sizeof(mp_req.name));
mp_req.len_param = sizeof(*req);
- if (rte_mp_request_sync(&mp_req, &mp_reply, &ts) != 0)
- PDUMP_LOG_LINE(ERR, "rte_mp_request_sync failed");
-
- else if (mp_reply.nb_sent != mp_reply.nb_received)
- PDUMP_LOG_LINE(ERR, "not all secondary's replied (sent %u recv %u)",
- mp_reply.nb_sent, mp_reply.nb_received);
-
- free(mp_reply.msgs);
+ /* Forward asynchronously so an unresponsive secondary cannot block the requester reply. */
+ if (rte_mp_request_async(&mp_req, &ts, pdump_secondary_reply) != 0)
+ PDUMP_LOG_LINE(ERR, "rte_mp_request_async failed");
}
/* Allocate temporary storage for passing state to the alarm thread for deferred handling */
--
2.43.0
^ permalink raw reply related
* [PATCH] net/vhost: support queue info query
From: Liangxing Wang @ 2026-07-01 6:14 UTC (permalink / raw)
To: maxime.coquelin, chenbox; +Cc: dev, Liangxing Wang
Add Rx and Tx queue info callbacks to report the vhost-user vring
size as the queue descriptor number.
The vhost-user PMD does not use the descriptor count passed by
rte_eth_rx_queue_setup() and rte_eth_tx_queue_setup(). The actual queue
depth is negotiated with the virtio frontend and maintained by the
vhost library. Query the vhost vring and report its size through
rxq_info_get and txq_info_get.
With this change, testpmd using vhost-user PMD can display the correct
Rx and Tx queue descriptor number in the port start log.
Signed-off-by: Liangxing Wang <wangliangxing@hygon.cn>
---
drivers/net/vhost/rte_eth_vhost.c | 38 +++++++++++++++++++++++++++++++
1 file changed, 38 insertions(+)
diff --git a/drivers/net/vhost/rte_eth_vhost.c b/drivers/net/vhost/rte_eth_vhost.c
index 05940f2461..af023c7639 100644
--- a/drivers/net/vhost/rte_eth_vhost.c
+++ b/drivers/net/vhost/rte_eth_vhost.c
@@ -1480,12 +1480,50 @@ vhost_dev_priv_dump(struct rte_eth_dev *dev, FILE *f)
return 0;
}
+static void
+eth_rxq_info_get(struct rte_eth_dev *dev, uint16_t rx_queue_id,
+ struct rte_eth_rxq_info *qinfo)
+{
+ struct rte_vhost_vring vring;
+ struct vhost_queue *vq = dev->data->rx_queues[rx_queue_id];
+
+ qinfo->nb_desc = 0;
+
+ if (vq == NULL || vq->vid < 0)
+ return;
+
+ if (rte_vhost_get_vhost_vring(vq->vid, vq->virtqueue_id, &vring) < 0)
+ return;
+
+ qinfo->nb_desc = vring.size;
+}
+
+static void
+eth_txq_info_get(struct rte_eth_dev *dev, uint16_t tx_queue_id,
+ struct rte_eth_txq_info *qinfo)
+{
+ struct rte_vhost_vring vring;
+ struct vhost_queue *vq = dev->data->tx_queues[tx_queue_id];
+
+ qinfo->nb_desc = 0;
+
+ if (vq == NULL || vq->vid < 0)
+ return;
+
+ if (rte_vhost_get_vhost_vring(vq->vid, vq->virtqueue_id, &vring) < 0)
+ return;
+
+ qinfo->nb_desc = vring.size;
+}
+
static const struct eth_dev_ops ops = {
.dev_start = eth_dev_start,
.dev_stop = eth_dev_stop,
.dev_close = eth_dev_close,
.dev_configure = eth_dev_configure,
.dev_infos_get = eth_dev_info,
+ .rxq_info_get = eth_rxq_info_get,
+ .txq_info_get = eth_txq_info_get,
.rx_queue_setup = eth_rx_queue_setup,
.tx_queue_setup = eth_tx_queue_setup,
.rx_queue_release = eth_rx_queue_release,
--
2.43.0
^ permalink raw reply related
* Re: [PATCH 0/2] fix dmadev incomplete ABI validation
From: David Marchand @ 2026-07-01 8:11 UTC (permalink / raw)
To: datshan; +Cc: thomas, dev, Chengwen Feng
In-Reply-To: <tencent_FD79B9DBEB2FD074BFAAACCC6DD7A6EBB906@qq.com>
Hello,
On Tue, 30 Jun 2026 at 15:24, <datshan@qq.com> wrote:
>
> From: datshan <datshan@qq.com>
>
> Fix dmadev incomplete ABI validation.
>
> Chengwen Feng (2):
> dmadev: fix incomplete configuration validation
> test/dmadev: add config and vchan validation tests
>
> app/test/test_dmadev_api.c | 186 ++++++++++++++++++++++++++++++++++---
> lib/dmadev/rte_dmadev.c | 156 +++++++++++++++++++++----------
> 2 files changed, 283 insertions(+), 59 deletions(-)
>
This series is not versionned, but I guess this is a new revision.
Don't forget to flag your submissions with a version number in the future.
I marked the previous patches as superseded in patchwork.
Also provide a high level summary of the differences between versions.
All of those steps are listed in the contributing guide, I suggest
(re-)reading the whole guide, with a highlight on:
https://doc.dpdk.org/guides/contributing/patches.html#steps-to-getting-your-patch-merged
Thanks, I'll try to find some time to review this week.
--
David Marchand
^ permalink raw reply
* RE: [PATCH v2 2/8] ip_frag: discard datagrams with overlapping fragments
From: Konstantin Ananyev @ 2026-07-01 8:13 UTC (permalink / raw)
To: Stephen Hemminger, dev@dpdk.org; +Cc: stable@dpdk.org
In-Reply-To: <20260630153723.525167-3-stephen@networkplumber.org>
> Existing code does not handle overlapping fragments.
>
> RFC 8200 (IPv6) requires that on overlap all reassembly is abandoned
> and all received fragments are dropped. RFC 791 (IPv4) originally called
> for trimming and rewriting, but Linux discards for IPv4 as well, since
> overlap has no legitimate use and is a known attack vector.
>
> Depends on the duplicate-tolerance change so that an exact duplicate is
> dropped on its own rather than discarding the whole datagram.
>
> Fixes: cc8f4d020c0b ("examples/ip_reassembly: initial import")
> Cc: stable@dpdk.org
I think you forgot to remove cc; stable.
>
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> Acked-by: Konstantin Ananyev <konstantin.ananyev@huawei.com>
> ---
> lib/ip_frag/ip_frag_internal.c | 38 +++++++++++++++++++++++++++-------
> 1 file changed, 30 insertions(+), 8 deletions(-)
>
> diff --git a/lib/ip_frag/ip_frag_internal.c b/lib/ip_frag/ip_frag_internal.c
> index 9a03ef995a..55fc4e9343 100644
> --- a/lib/ip_frag/ip_frag_internal.c
> +++ b/lib/ip_frag/ip_frag_internal.c
> @@ -92,16 +92,38 @@ ip_frag_process(struct ip_frag_pkt *fp, struct
> rte_ip_frag_death_row *dr,
> uint32_t i, idx;
>
> /*
> - * Discard an exact duplicate fragment. If a previously stored fragment
> - * already covers the same offset and length, this fragment carries no
> - * new data. Reassembly is tolerant of duplicates (RFC 791), so drop
> - * only this mbuf and keep the reassembly entry intact rather than
> - * treating it as an error. Fragments overlapping an existing one with
> - * different bounds are not handled here.
> + * Scan the fragments already collected for this datagram before
> + * storing the new one. The stored set is kept free of duplicates and
> + * overlaps, so a single pass is sufficient.
> */
> for (i = 0; i != fp->last_idx; i++) {
> - if (fp->frags[i].mb != NULL && fp->frags[i].ofs == ofs &&
> - fp->frags[i].len == len) {
> + if (fp->frags[i].mb == NULL)
> + continue;
> +
> + /*
> + * Exact duplicate: carries no new data. Reassembly tolerates
> + * duplicates (RFC 791), so drop only this mbuf and keep the
> + * entry.
> + */
> + if (fp->frags[i].ofs == ofs && fp->frags[i].len == len) {
> + IP_FRAG_MBUF2DR(dr, mb);
> + return NULL;
> + }
> +
> + /*
> + * Overlap with an existing fragment. Per RFC 8200 section 4.5
> + * (and RFC 5722) the datagram must be discarded; the same is
> + * applied to IPv4. Free all collected fragments, drop this one,
> + * and invalidate the entry.
> + */
> + if (ofs < fp->frags[i].ofs + fp->frags[i].len && fp->frags[i].ofs < ofs +
> len) {
> + IP_FRAG_LOG(DEBUG,
> + "%s:%d overlap ofs: %u len: %u\n"
> + "fragment: %p ofs: %u len %u\n\n",
> + __func__, __LINE__, ofs, len,
> + fp, fp->frags[i].ofs, fp->frags[i].len);
> + ip_frag_free(fp, dr);
> + ip_frag_key_invalidate(&fp->key);
> IP_FRAG_MBUF2DR(dr, mb);
> return NULL;
> }
> --
> 2.53.0
^ permalink raw reply
* RE: [PATCH v2 8/8] doc: add release note about ip_frag changes
From: Konstantin Ananyev @ 2026-07-01 8:22 UTC (permalink / raw)
To: Stephen Hemminger, dev@dpdk.org
In-Reply-To: <20260630153723.525167-9-stephen@networkplumber.org>
> The changes to ip_frag might impact some conformance or
> performance tests.
>
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> ---
> doc/guides/rel_notes/release_26_07.rst | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/doc/guides/rel_notes/release_26_07.rst
> b/doc/guides/rel_notes/release_26_07.rst
> index 4ca0a9ac77..a419803401 100644
> --- a/doc/guides/rel_notes/release_26_07.rst
> +++ b/doc/guides/rel_notes/release_26_07.rst
> @@ -241,6 +241,12 @@ API Changes
> - ``rte_pmd_mlx5_enable_steering``
> - ``rte_pmd_mlx5_disable_steering``
>
> +* **ip_frag: hardened IP reassembly against malformed fragments.**
> +
> + Duplicate, overlapping, oversized, and (for IPv6) per-fragment-header
> + fragments are now rejected rather than mis-reassembled. This changes which
> + fragment streams reassemble and may affect throughput.
That doesn't look entirely correct:
Current implementation doesn't allow both duplicate or overlapping fragments either,
though it postpones it's detection till reassembly stage.
Might be something like that:
**ip_frag: hardened IP reassembly against malformed fragments.**
* Tolerate packets with duplicate fragments,
* Determine duplicate overlapping and oversized fragments at arrival. That change
can cause multiple extra scans over already received fragments and might affect
overall system throughput.
?
> +
>
> ABI Changes
> -----------
> --
> 2.53.0
^ permalink raw reply
* [PATCH v2] net/idpf: fix Tx of large mbuf segments
From: Bruce Richardson @ 2026-07-01 8:23 UTC (permalink / raw)
To: dev; +Cc: vladimir.medvedkin, Bruce Richardson, stable
In-Reply-To: <20260626134440.2108591-1-bruce.richardson@intel.com>
When TSO is enabled, and we get a packet to transmit where an individual
mbuf segment is longer than 16k, we need to split that segment across
multiple Tx descriptors. This support is present in the single-queue
mode of idpf - since it shares common code with the other Intel drivers
- but was missing from the splitq path.
This patch adds the proper data path handling. Previous work ensured
that the descriptor count calculation took over-sized segments into
account but the actual descriptor writing part was overlooked.
Fixes: 770f4dfe0f79 ("net/idpf: support basic Tx data path")
Fixes: 2904020f8313 ("net/intel: add common function to calculate needed descs")
Cc: stable@dpdk.org
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
---
V2: change check for number of free descriptor slots to use the correct
count, rather than just the number of mbuf segments passed
---
drivers/net/intel/idpf/idpf_common_rxtx.c | 43 ++++++++++++++++++-----
1 file changed, 35 insertions(+), 8 deletions(-)
diff --git a/drivers/net/intel/idpf/idpf_common_rxtx.c b/drivers/net/intel/idpf/idpf_common_rxtx.c
index a123d969ee..2c87e02c98 100644
--- a/drivers/net/intel/idpf/idpf_common_rxtx.c
+++ b/drivers/net/intel/idpf/idpf_common_rxtx.c
@@ -952,9 +952,6 @@ idpf_dp_splitq_xmit_pkts(void *tx_queue, struct rte_mbuf **tx_pkts,
idpf_split_tx_free(txq->complq);
}
- if (txq->nb_tx_free < tx_pkt->nb_segs)
- break;
-
cmd_dtype = 0;
ol_flags = tx_pkt->ol_flags;
tx_offload.l2_len = tx_pkt->l2_len;
@@ -976,6 +973,9 @@ idpf_dp_splitq_xmit_pkts(void *tx_queue, struct rte_mbuf **tx_pkts,
else
nb_used = tx_pkt->nb_segs + nb_ctx;
+ if (txq->nb_tx_free < nb_used)
+ break;
+
if (ol_flags & CI_TX_CKSUM_OFFLOAD_MASK)
cmd_dtype = IDPF_TXD_FLEX_FLOW_CMD_CS_EN;
@@ -994,16 +994,43 @@ idpf_dp_splitq_xmit_pkts(void *tx_queue, struct rte_mbuf **tx_pkts,
uint16_t first_sw_id = sw_id;
do {
+ uint16_t slen = tx_pkt->data_len;
+ rte_iova_t buf_dma_addr = rte_mbuf_data_iova(tx_pkt);
+
+ /* Split segment across multiple descriptors if needed
+ * for TSO packets where segment exceeds max buf size.
+ */
+ while ((ol_flags & RTE_MBUF_F_TX_TCP_SEG) &&
+ unlikely(slen > CI_MAX_DATA_PER_TXD)) {
+ txd = &txr[tx_id];
+ txn = &sw_ring[txe->next_id];
+ txe->mbuf = NULL;
+
+ txd->buf_addr = rte_cpu_to_le_64(buf_dma_addr);
+ txd->qw1.cmd_dtype = cmd_dtype |
+ IDPF_TX_DESC_DTYPE_FLEX_FLOW_SCHE;
+ txd->qw1.rxr_bufsize = CI_MAX_DATA_PER_TXD;
+ txd->qw1.compl_tag = sw_id;
+
+ buf_dma_addr += CI_MAX_DATA_PER_TXD;
+ slen -= CI_MAX_DATA_PER_TXD;
+
+ tx_id++;
+ if (tx_id == txq->nb_tx_desc)
+ tx_id = 0;
+ sw_id = txe->next_id;
+ txe = txn;
+ }
+
txd = &txr[tx_id];
txn = &sw_ring[txe->next_id];
txe->mbuf = tx_pkt;
/* Setup TX descriptor */
- txd->buf_addr =
- rte_cpu_to_le_64(rte_mbuf_data_iova(tx_pkt));
- cmd_dtype |= IDPF_TX_DESC_DTYPE_FLEX_FLOW_SCHE;
- txd->qw1.cmd_dtype = cmd_dtype;
- txd->qw1.rxr_bufsize = tx_pkt->data_len;
+ txd->buf_addr = rte_cpu_to_le_64(buf_dma_addr);
+ txd->qw1.cmd_dtype = cmd_dtype |
+ IDPF_TX_DESC_DTYPE_FLEX_FLOW_SCHE;
+ txd->qw1.rxr_bufsize = slen;
txd->qw1.compl_tag = sw_id;
tx_id++;
if (tx_id == txq->nb_tx_desc)
--
2.53.0
^ permalink raw reply related
* [PATCH] net/ixgbe: fix EEPROM read failure on copper media
From: Mingjin Ye @ 2026-07-01 9:07 UTC (permalink / raw)
To: dev
Cc: Mingjin Ye, stable, Anatoly Burakov, Vladimir Medvedkin,
Remy Horton, Ferruh Yigit, Zijie Pan
The ixgbe_get_module_info() and ixgbe_get_module_eeprom() functions
attempt to read SFF EEPROM data for all port types. However, copper
media ports do not have SFF EEPROMs, causing invalid I2C operations
and generating error logs.
This patch adds a media type check at the beginning of both functions.
If the media type is ixgbe_media_type_copper, return -ENOTSUP to
safely skip the EEPROM read.
Fixes: b74d0cd43e37 ("net/ixgbe: add module EEPROM callbacks for ixgbe")
Cc: stable@dpdk.org
Signed-off-by: Mingjin Ye <mingjinx.ye@intel.com>
---
drivers/net/intel/ixgbe/ixgbe_ethdev.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/drivers/net/intel/ixgbe/ixgbe_ethdev.c b/drivers/net/intel/ixgbe/ixgbe_ethdev.c
index f9de95e4fc..44c29f0642 100644
--- a/drivers/net/intel/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/intel/ixgbe/ixgbe_ethdev.c
@@ -7424,6 +7424,12 @@ ixgbe_get_module_info(struct rte_eth_dev *dev,
if (rte_eal_process_type() != RTE_PROC_PRIMARY)
return -E_RTE_SECONDARY;
+ if (hw->phy.media_type == ixgbe_media_type_copper) {
+ PMD_DRV_LOG(DEBUG, "Port %u is Base-T (copper), no SFF module info.",
+ dev->data->port_id);
+ return -ENOTSUP;
+ }
+
/* Check whether we support SFF-8472 or not */
status = hw->phy.ops.read_i2c_eeprom(hw,
IXGBE_SFF_SFF_8472_COMP,
@@ -7477,6 +7483,12 @@ ixgbe_get_module_eeprom(struct rte_eth_dev *dev,
if (rte_eal_process_type() != RTE_PROC_PRIMARY)
return -E_RTE_SECONDARY;
+ if (hw->phy.media_type == ixgbe_media_type_copper) {
+ PMD_DRV_LOG(DEBUG, "Port %u is Base-T (copper), cannot read module EEPROM.",
+ dev->data->port_id);
+ return -ENOTSUP;
+ }
+
for (i = info->offset; i < info->offset + info->length; i++) {
if (i < RTE_ETH_MODULE_SFF_8079_LEN)
status = hw->phy.ops.read_i2c_eeprom(hw, i, &databyte);
--
2.47.1
^ permalink raw reply related
* Re: [PATCH v2] net/idpf: fix Tx of large mbuf segments
From: Medvedkin, Vladimir @ 2026-07-01 8:44 UTC (permalink / raw)
To: Bruce Richardson, dev; +Cc: stable
In-Reply-To: <20260701082337.3176970-1-bruce.richardson@intel.com>
Acked-by: Vladimir Medvedkin <vladimir.medvedkin@intel.com>
On 7/1/2026 9:23 AM, Bruce Richardson wrote:
> When TSO is enabled, and we get a packet to transmit where an individual
> mbuf segment is longer than 16k, we need to split that segment across
> multiple Tx descriptors. This support is present in the single-queue
> mode of idpf - since it shares common code with the other Intel drivers
> - but was missing from the splitq path.
>
> This patch adds the proper data path handling. Previous work ensured
> that the descriptor count calculation took over-sized segments into
> account but the actual descriptor writing part was overlooked.
>
> Fixes: 770f4dfe0f79 ("net/idpf: support basic Tx data path")
> Fixes: 2904020f8313 ("net/intel: add common function to calculate needed descs")
> Cc: stable@dpdk.org
>
> Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> ---
> V2: change check for number of free descriptor slots to use the correct
> count, rather than just the number of mbuf segments passed
> ---
> drivers/net/intel/idpf/idpf_common_rxtx.c | 43 ++++++++++++++++++-----
> 1 file changed, 35 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/net/intel/idpf/idpf_common_rxtx.c b/drivers/net/intel/idpf/idpf_common_rxtx.c
> index a123d969ee..2c87e02c98 100644
> --- a/drivers/net/intel/idpf/idpf_common_rxtx.c
> +++ b/drivers/net/intel/idpf/idpf_common_rxtx.c
> @@ -952,9 +952,6 @@ idpf_dp_splitq_xmit_pkts(void *tx_queue, struct rte_mbuf **tx_pkts,
> idpf_split_tx_free(txq->complq);
> }
>
> - if (txq->nb_tx_free < tx_pkt->nb_segs)
> - break;
> -
> cmd_dtype = 0;
> ol_flags = tx_pkt->ol_flags;
> tx_offload.l2_len = tx_pkt->l2_len;
> @@ -976,6 +973,9 @@ idpf_dp_splitq_xmit_pkts(void *tx_queue, struct rte_mbuf **tx_pkts,
> else
> nb_used = tx_pkt->nb_segs + nb_ctx;
>
> + if (txq->nb_tx_free < nb_used)
> + break;
> +
> if (ol_flags & CI_TX_CKSUM_OFFLOAD_MASK)
> cmd_dtype = IDPF_TXD_FLEX_FLOW_CMD_CS_EN;
>
> @@ -994,16 +994,43 @@ idpf_dp_splitq_xmit_pkts(void *tx_queue, struct rte_mbuf **tx_pkts,
> uint16_t first_sw_id = sw_id;
>
> do {
> + uint16_t slen = tx_pkt->data_len;
> + rte_iova_t buf_dma_addr = rte_mbuf_data_iova(tx_pkt);
> +
> + /* Split segment across multiple descriptors if needed
> + * for TSO packets where segment exceeds max buf size.
> + */
> + while ((ol_flags & RTE_MBUF_F_TX_TCP_SEG) &&
> + unlikely(slen > CI_MAX_DATA_PER_TXD)) {
> + txd = &txr[tx_id];
> + txn = &sw_ring[txe->next_id];
> + txe->mbuf = NULL;
> +
> + txd->buf_addr = rte_cpu_to_le_64(buf_dma_addr);
> + txd->qw1.cmd_dtype = cmd_dtype |
> + IDPF_TX_DESC_DTYPE_FLEX_FLOW_SCHE;
> + txd->qw1.rxr_bufsize = CI_MAX_DATA_PER_TXD;
> + txd->qw1.compl_tag = sw_id;
> +
> + buf_dma_addr += CI_MAX_DATA_PER_TXD;
> + slen -= CI_MAX_DATA_PER_TXD;
> +
> + tx_id++;
> + if (tx_id == txq->nb_tx_desc)
> + tx_id = 0;
> + sw_id = txe->next_id;
> + txe = txn;
> + }
> +
> txd = &txr[tx_id];
> txn = &sw_ring[txe->next_id];
> txe->mbuf = tx_pkt;
>
> /* Setup TX descriptor */
> - txd->buf_addr =
> - rte_cpu_to_le_64(rte_mbuf_data_iova(tx_pkt));
> - cmd_dtype |= IDPF_TX_DESC_DTYPE_FLEX_FLOW_SCHE;
> - txd->qw1.cmd_dtype = cmd_dtype;
> - txd->qw1.rxr_bufsize = tx_pkt->data_len;
> + txd->buf_addr = rte_cpu_to_le_64(buf_dma_addr);
> + txd->qw1.cmd_dtype = cmd_dtype |
> + IDPF_TX_DESC_DTYPE_FLEX_FLOW_SCHE;
> + txd->qw1.rxr_bufsize = slen;
> txd->qw1.compl_tag = sw_id;
> tx_id++;
> if (tx_id == txq->nb_tx_desc)
--
Regards,
Vladimir
^ permalink raw reply
* Re: [PATCH] net/e1000: align device IDs with base code
From: Medvedkin, Vladimir @ 2026-07-01 8:45 UTC (permalink / raw)
To: Bruce Richardson, dev
In-Reply-To: <20260630161623.3131518-1-bruce.richardson@intel.com>
Acked-by: Vladimir Medvedkin <vladimir.medvedkin@intel.com>
On 6/30/2026 5:16 PM, Bruce Richardson wrote:
> The e1000 base header lists multiple PCI device IDs in e1000_hw.h that
> are not present in the em PCI ID table. Add the missing IDs so DPDK can
> probe all e1000 devices defined by the shared base code.
>
> Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> ---
> drivers/net/intel/e1000/em_ethdev.c | 70 +++++++++++++++++++++++++++++
> 1 file changed, 70 insertions(+)
>
> diff --git a/drivers/net/intel/e1000/em_ethdev.c b/drivers/net/intel/e1000/em_ethdev.c
> index 62ab57268f..c02d09e500 100644
> --- a/drivers/net/intel/e1000/em_ethdev.c
> +++ b/drivers/net/intel/e1000/em_ethdev.c
> @@ -187,6 +187,76 @@ static const struct rte_pci_id pci_id_em_map[] = {
> { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_PCH_RPL_I219_V23) },
> { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_PCH_ARL_I219_LM24) },
> { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_PCH_ARL_I219_V24) },
> + { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_PCH_PTP_I219_LM25) },
> + { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_PCH_PTP_I219_V25) },
> + { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_PCH_WCL_I219_LM27) },
> + { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_PCH_WCL_I219_V27) },
> + { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_PCH_NVL_I219_LM29) },
> + { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_PCH_NVL_I219_V29) },
> + { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_80003ES2LAN_COPPER_DPT) },
> + { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_80003ES2LAN_COPPER_SPT) },
> + { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_80003ES2LAN_SERDES_DPT) },
> + { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_80003ES2LAN_SERDES_SPT) },
> + { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_82540EM_LOM) },
> + { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_82540EP) },
> + { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_82540EP_LOM) },
> + { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_82540EP_LP) },
> + { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_82541EI) },
> + { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_82541EI_MOBILE) },
> + { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_82541ER) },
> + { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_82541ER_LOM) },
> + { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_82541GI) },
> + { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_82541GI_LF) },
> + { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_82541GI_MOBILE) },
> + { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_82542) },
> + { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_82543GC_COPPER) },
> + { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_82543GC_FIBER) },
> + { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_82544EI_COPPER) },
> + { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_82544EI_FIBER) },
> + { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_82544GC_COPPER) },
> + { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_82544GC_LOM) },
> + { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_82545GM_COPPER) },
> + { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_82545GM_FIBER) },
> + { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_82545GM_SERDES) },
> + { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_82546GB_COPPER) },
> + { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_82546GB_FIBER) },
> + { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_82546GB_PCIE) },
> + { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_82546GB_QUAD_COPPER) },
> + { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_82546GB_QUAD_COPPER_KSP3) },
> + { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_82546GB_SERDES) },
> + { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_82547EI) },
> + { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_82547EI_MOBILE) },
> + { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_82547GI) },
> + { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_82573E) },
> + { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_82573E_IAMT) },
> + { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_ICH10_D_BM_LF) },
> + { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_ICH10_D_BM_LM) },
> + { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_ICH10_D_BM_V) },
> + { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_ICH10_R_BM_LF) },
> + { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_ICH10_R_BM_LM) },
> + { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_ICH10_R_BM_V) },
> + { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_ICH8_82567V_3) },
> + { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_ICH8_IFE) },
> + { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_ICH8_IFE_G) },
> + { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_ICH8_IFE_GT) },
> + { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_ICH8_IGP_AMT) },
> + { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_ICH8_IGP_C) },
> + { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_ICH8_IGP_M) },
> + { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_ICH8_IGP_M_AMT) },
> + { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_ICH9_BM) },
> + { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_ICH9_IFE) },
> + { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_ICH9_IFE_G) },
> + { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_ICH9_IFE_GT) },
> + { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_ICH9_IGP_AMT) },
> + { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_ICH9_IGP_C) },
> + { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_ICH9_IGP_M) },
> + { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_ICH9_IGP_M_AMT) },
> + { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_ICH9_IGP_M_V) },
> + { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_PCH2_LV_V) },
> + { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_PCH_D_HV_DC) },
> + { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_PCH_D_HV_DM) },
> + { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_PCH_M_HV_LC) },
> + { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_PCH_M_HV_LM) },
> { .vendor_id = 0, /* sentinel */ },
> };
>
--
Regards,
Vladimir
^ permalink raw reply
* Re: [PATCH] net/e1000: align device IDs with base code
From: Bruce Richardson @ 2026-07-01 9:45 UTC (permalink / raw)
To: Medvedkin, Vladimir; +Cc: dev
In-Reply-To: <845b63eb-a2d3-4605-98c0-76c8173ee522@intel.com>
On Wed, Jul 01, 2026 at 09:45:45AM +0100, Medvedkin, Vladimir wrote:
>
> On 6/30/2026 5:16 PM, Bruce Richardson wrote:
> > The e1000 base header lists multiple PCI device IDs in e1000_hw.h that
> > are not present in the em PCI ID table. Add the missing IDs so DPDK can
> > probe all e1000 devices defined by the shared base code.
> >
> > Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> Acked-by: Vladimir Medvedkin <vladimir.medvedkin@intel.com>
> > ---
> > drivers/net/intel/e1000/em_ethdev.c | 70 +++++++++++++++++++++++++++++
> > 1 file changed, 70 insertions(+)
> >
Applied to dpdk-next-net-intel.
/Bruce
^ permalink raw reply
* Re: [PATCH v7 4/6] eal: fix async IPC memory leaks on partial failure
From: David Marchand @ 2026-07-01 9:47 UTC (permalink / raw)
To: Anatoly Burakov; +Cc: dev, Jianfeng Tan
In-Reply-To: <c4564e3c9e7ad675c60655b80cac1a077ad24bb1.1782469943.git.anatoly.burakov@intel.com>
On Fri, 26 Jun 2026 at 12:34, Anatoly Burakov <anatoly.burakov@intel.com> wrote:
>
> When rte_mp_request_async() fails to send requests to all peers,
> copy and param can lose ownership and leak.
>
> However, we cannot simply free them unconditionally, as "partial failure"
> means some requests were already queued and thus still reference `copy` and
> `param`, so freeing them directly on the error path can cause
> use-after-free when those requests are later handled by the async timeout.
>
> Fix this by rolling back queued requests from the current batch, and reset
> nb_sent to 0. Freeing the requests is now safe even if some requests were
> sent, as any responses or timeouts will not find the request ID in the
> queue and will safely exit without doing anything.
>
> Coverity issue: 501503
>
> Fixes: f05e26051c15 ("eal: add IPC asynchronous request")
> Cc: stable@dpdk.org
>
> Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
> ---
> lib/eal/common/eal_common_proc.c | 31 +++++++++++++++++++++++++++++++
> 1 file changed, 31 insertions(+)
>
> diff --git a/lib/eal/common/eal_common_proc.c b/lib/eal/common/eal_common_proc.c
> index 991bf215a3..0cffc7a127 100644
> --- a/lib/eal/common/eal_common_proc.c
> +++ b/lib/eal/common/eal_common_proc.c
> @@ -1245,6 +1245,32 @@ rte_mp_request_async(struct rte_mp_msg *req, const struct timespec *ts,
> } else if (mp_request_async(path, copy, param, ts))
> ret = -1;
> }
> +
> + /*
> + * On partial failure, roll back all queued requests. We hold the lock
> + * so no one else touches the queue. All requests in this batch share
> + * the same param pointer. Stale alarms will fire and harmlessly find
> + * nothing via ID-based lookup.
> + */
> + if (ret != 0 && reply->nb_sent > 0) {
> + struct pending_request *r, *next;
> +
> + for (r = TAILQ_FIRST(&pending_requests.requests);
> + r != NULL; r = next) {
> + next = TAILQ_NEXT(r, next);
> + if (r->type == REQUEST_TYPE_ASYNC &&
> + r->async.param == param) {
> + TAILQ_REMOVE(&pending_requests.requests,
> + r, next);
> + free(r->reply);
> + /* r->request == copy, freed below after the loop */
> + free(r);
> + }
> + }
> + /* requests on the queue were removed so keep things consistent */
> + reply->nb_sent = 0;
> + }
> +
Please, don't reimplement the safe macro.
I plan to update this with:
@@ -1252,15 +1252,11 @@ rte_mp_request_async(struct rte_mp_msg *req,
const struct timespec *ts,
* nothing via ID-based lookup.
*/
if (ret != 0 && reply->nb_sent > 0) {
- struct pending_request *r, *next;
-
- for (r = TAILQ_FIRST(&pending_requests.requests);
- r != NULL; r = next) {
- next = TAILQ_NEXT(r, next);
- if (r->type == REQUEST_TYPE_ASYNC &&
- r->async.param == param) {
- TAILQ_REMOVE(&pending_requests.requests,
- r, next);
+ struct pending_request *r, *tmp;
+
+ RTE_TAILQ_FOREACH_SAFE(r, &pending_requests.requests,
next, tmp) {
+ if (r->type == REQUEST_TYPE_ASYNC &&
r->async.param == param) {
+
TAILQ_REMOVE(&pending_requests.requests, r, next);
free(r->reply);
/* r->request == copy, freed below
after the loop */
free(r);
Objection?
If not, I'll update while applying.
--
David Marchand
^ permalink raw reply
* Re: [PATCH v2] net/idpf: fix Tx of large mbuf segments
From: Bruce Richardson @ 2026-07-01 9:47 UTC (permalink / raw)
To: Medvedkin, Vladimir; +Cc: dev, stable
In-Reply-To: <838a36a9-654f-4b32-b3d4-3457dd024b58@intel.com>
On Wed, Jul 01, 2026 at 09:44:52AM +0100, Medvedkin, Vladimir wrote:
>
> On 7/1/2026 9:23 AM, Bruce Richardson wrote:
> > When TSO is enabled, and we get a packet to transmit where an individual
> > mbuf segment is longer than 16k, we need to split that segment across
> > multiple Tx descriptors. This support is present in the single-queue
> > mode of idpf - since it shares common code with the other Intel drivers
> > - but was missing from the splitq path.
> >
> > This patch adds the proper data path handling. Previous work ensured
> > that the descriptor count calculation took over-sized segments into
> > account but the actual descriptor writing part was overlooked.
> >
> > Fixes: 770f4dfe0f79 ("net/idpf: support basic Tx data path")
> > Fixes: 2904020f8313 ("net/intel: add common function to calculate needed descs")
> > Cc: stable@dpdk.org
> >
> > Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> Acked-by: Vladimir Medvedkin <vladimir.medvedkin@intel.com>
> > ---
> > V2: change check for number of free descriptor slots to use the correct
> > count, rather than just the number of mbuf segments passed
> > ---
> > drivers/net/intel/idpf/idpf_common_rxtx.c | 43 ++++++++++++++++++-----
> > 1 file changed, 35 insertions(+), 8 deletions(-)
> >
Patch applied to dpdk-next-net-intel.
/Bruce
^ permalink raw reply
* Re: [PATCH v7 4/6] eal: fix async IPC memory leaks on partial failure
From: Bruce Richardson @ 2026-07-01 9:53 UTC (permalink / raw)
To: David Marchand; +Cc: Anatoly Burakov, dev, Jianfeng Tan
In-Reply-To: <CAJFAV8wmRsznO6S6gz0cmnhAs+QHW1k=7oFo3DhR9--A-Myo5Q@mail.gmail.com>
On Wed, Jul 01, 2026 at 11:47:05AM +0200, David Marchand wrote:
> On Fri, 26 Jun 2026 at 12:34, Anatoly Burakov <anatoly.burakov@intel.com> wrote:
> >
> > When rte_mp_request_async() fails to send requests to all peers,
> > copy and param can lose ownership and leak.
> >
> > However, we cannot simply free them unconditionally, as "partial failure"
> > means some requests were already queued and thus still reference `copy` and
> > `param`, so freeing them directly on the error path can cause
> > use-after-free when those requests are later handled by the async timeout.
> >
> > Fix this by rolling back queued requests from the current batch, and reset
> > nb_sent to 0. Freeing the requests is now safe even if some requests were
> > sent, as any responses or timeouts will not find the request ID in the
> > queue and will safely exit without doing anything.
> >
> > Coverity issue: 501503
> >
> > Fixes: f05e26051c15 ("eal: add IPC asynchronous request")
> > Cc: stable@dpdk.org
> >
> > Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
> > ---
> > lib/eal/common/eal_common_proc.c | 31 +++++++++++++++++++++++++++++++
> > 1 file changed, 31 insertions(+)
> >
> > diff --git a/lib/eal/common/eal_common_proc.c b/lib/eal/common/eal_common_proc.c
> > index 991bf215a3..0cffc7a127 100644
> > --- a/lib/eal/common/eal_common_proc.c
> > +++ b/lib/eal/common/eal_common_proc.c
> > @@ -1245,6 +1245,32 @@ rte_mp_request_async(struct rte_mp_msg *req, const struct timespec *ts,
> > } else if (mp_request_async(path, copy, param, ts))
> > ret = -1;
> > }
> > +
> > + /*
> > + * On partial failure, roll back all queued requests. We hold the lock
> > + * so no one else touches the queue. All requests in this batch share
> > + * the same param pointer. Stale alarms will fire and harmlessly find
> > + * nothing via ID-based lookup.
> > + */
> > + if (ret != 0 && reply->nb_sent > 0) {
> > + struct pending_request *r, *next;
> > +
> > + for (r = TAILQ_FIRST(&pending_requests.requests);
> > + r != NULL; r = next) {
> > + next = TAILQ_NEXT(r, next);
> > + if (r->type == REQUEST_TYPE_ASYNC &&
> > + r->async.param == param) {
> > + TAILQ_REMOVE(&pending_requests.requests,
> > + r, next);
> > + free(r->reply);
> > + /* r->request == copy, freed below after the loop */
> > + free(r);
> > + }
> > + }
> > + /* requests on the queue were removed so keep things consistent */
> > + reply->nb_sent = 0;
> > + }
> > +
>
> Please, don't reimplement the safe macro.
>
> I plan to update this with:
>
> @@ -1252,15 +1252,11 @@ rte_mp_request_async(struct rte_mp_msg *req,
> const struct timespec *ts,
> * nothing via ID-based lookup.
> */
> if (ret != 0 && reply->nb_sent > 0) {
> - struct pending_request *r, *next;
> -
> - for (r = TAILQ_FIRST(&pending_requests.requests);
> - r != NULL; r = next) {
> - next = TAILQ_NEXT(r, next);
> - if (r->type == REQUEST_TYPE_ASYNC &&
> - r->async.param == param) {
> - TAILQ_REMOVE(&pending_requests.requests,
> - r, next);
> + struct pending_request *r, *tmp;
> +
> + RTE_TAILQ_FOREACH_SAFE(r, &pending_requests.requests,
> next, tmp) {
> + if (r->type == REQUEST_TYPE_ASYNC &&
> r->async.param == param) {
> +
> TAILQ_REMOVE(&pending_requests.requests, r, next);
> free(r->reply);
> /* r->request == copy, freed below
> after the loop */
> free(r);
>
> Objection?
> If not, I'll update while applying.
>
+1 to this suggestion from me.
^ permalink raw reply
* Re: [PATCH v7 0/6] IPC fixes
From: David Marchand @ 2026-07-01 10:09 UTC (permalink / raw)
To: Anatoly Burakov; +Cc: dev, Bruce Richardson, Thomas Monjalon
In-Reply-To: <cover.1782469943.git.anatoly.burakov@intel.com>
Hello Anatoly,
On Fri, 26 Jun 2026 at 12:34, Anatoly Burakov <anatoly.burakov@intel.com> wrote:
>
> Coverity has reported (issue ID 501503) a memory leak, but there
> actually were a few more problems with IPC than that. This patchset
> addresses said problems.
>
> 1. Using pointer as async request identity is unsafe
>
> Because asynchronous requests can fail at arbitrary points while
> having arbitrary number of requests or alarms already in flight,
> using pointer as request identity can create use-after-free risks.
> Patchset replaces this with using numeric request ID instead.
>
> 2. Alarm cancel can deadlock
>
> Async request handler may attempt to cancel the alarm, but an alarm
> might have already been in progress blocking on the same lock that
> is held by async request, leading to a deadlock. Patchset removes
> the alarm cancel call, and allows the alarm to fire. This is fine,
> because due to fix #1 the worst that can happen from calling stale
> alarm is a noop, as request ID would not be found.
>
> 3. Memory leaks
>
> There are a couple of memory leaks in failure paths. Patchset fixes
> those.
>
> 4. Zero-peer async request does not trigger alarm
>
> When async requests are performed but no peers exist, we created
> a dummy request and put it on the queue, but we never set the
> dummy alarm that is supposed to handle that request. Patchset adds
> the alarm set in dummy paths where none was present before.
>
> v7:
> - Moved request ID reservation till after allocation
> - Added build check for request ID size matching pointer size
> - Moved comment about minimum delay alarm from patch 4 to patch 6
>
> Note: AI review had a bunch of false positive "errors", all of them
> looked at and verified as such.
>
> v6:
>
> Moved pieces around, namely:
>
> 1) apply request ID refactor first as a standalone patch
> 2) fix the deadlock immediately after
> 3) fix memory leaks next
> 4) add missing callback as a final step
>
> Contents of the patchset remain the same.
>
> Anatoly Burakov (6):
> eal: fix wrong log message in async IPC request
> eal: use request ID instead of pointers
> eal: avoid deadlock in async IPC alarm callback
> eal: fix async IPC memory leaks on partial failure
> eal: fix memory leak in async IPC secondary path
> eal: fix async IPC callback not fired when no peers
>
> lib/eal/common/eal_common_proc.c | 137 +++++++++++++++++++++++--------
> 1 file changed, 103 insertions(+), 34 deletions(-)
Series applied with my suggestion on patch 4, thanks for the fixes.
--
David Marchand
^ permalink raw reply
* Re: [PATCH v2 0/3] fib6: fix tbl8 reservation drift
From: David Marchand @ 2026-07-01 10:27 UTC (permalink / raw)
To: Maxime Leroy; +Cc: Vladimir Medvedkin, dev
In-Reply-To: <20260617082400.142129-1-maxime@leroys.fr>
Hello Maxime,
On Wed, 17 Jun 2026 at 10:24, Maxime Leroy <maxime@leroys.fr> wrote:
>
> trie_modify() maintained rsvd_tbl8s by computing a depth_diff from the
> current RIB topology at both ADD and DEL. The two values diverge when
> the RIB changes between an ADD and its later DEL (a covering parent
> added or removed), so rsvd_tbl8s eventually wraps to UINT32_MAX and
> rejects all subsequent /25+ ADDs with -ENOSPC. A zebra-kill /
> reconverge cycle on a live BGP router reproduces it.
>
> The fix computes the reservation from the RIB node shape:
> count_empty_levels() returns the number of byte boundaries between the
> prefix and its covering parent that no other prefix occupies
> (has_children + parent depth), in O(1). It is the count of tbl8 levels
> the current route set needs, so ADD/DEL accounting stays consistent and
> cannot drift.
>
> Patch 1 is the minimal self-contained fix (Fixes: + Cc: stable).
> Patches 2-3 add the reproducer and extended regression tests.
>
> Validated on a live BGP router (grout + FRR, 128 IPv6 prefixes):
> RSVD_TBL8 returned to its pre-cycle value (70) after a zebra-kill /
> reconverge cycle.
>
> Maxime Leroy (3):
> fib6: fix tbl8 reservation drift in trie
> test/fib6: add reproducer for tbl8 reservation drift
> test/fib6: extended drift test cases
>
> app/test/test_fib6.c | 335 ++++++++++++++++++++++++++++++++++++++++
> lib/fib/trie.c | 83 +++++-----
> lib/rib/rib6_internal.h | 22 +++
> lib/rib/rte_rib6.c | 15 ++
> 4 files changed, 415 insertions(+), 40 deletions(-)
> create mode 100644 lib/rib/rib6_internal.h
>
> ---
> v2:
> * Compute the empty-level count directly from the RIB node
> (rte_rib6_node_has_children + rte_rib6_get_parent, O(1)) instead of
> the v1 multi-level supernet scan over byte boundaries.
> * Drop v1 patches 4-5 (valid_descendants counter + single-descent
> helper): no longer needed, the node-based count is already O(1), so
> rte_rib6 needs no new per-node accounting field.
>
> v1:
> * Keep rsvd_tbl8s; recompute it via topology-stable empty-supernet
> count (dir24_8 pattern at 13 levels) instead of RIB-derived
> depth_diff.
> * Drop RFC patch 3/3 (no longer needed).
> * Add extended regression tests.
> * Add patches 4-5: RIB valid_descendants + single-descent helper
> (optional perf optimization; not for stable).
> * Production-validated on a live BGP router.
>
> --
> 2.43.0
>
Series applied, thanks.
--
David Marchand
^ permalink raw reply
* Re: [PATCH v3 0/6] Intel network drivers enhancements
From: Bruce Richardson @ 2026-07-01 10:42 UTC (permalink / raw)
To: Dawid Wesierski; +Cc: dev, thomas, stephen, marek.kasiewicz
In-Reply-To: <20260630120657.1046588-1-dawid.wesierski@intel.com>
On Tue, Jun 30, 2026 at 08:06:50AM -0400, Dawid Wesierski wrote:
> This series collects Intel E810 iavf and ice driver enhancements developed
> for the Media Transport Library (MTL) to support high-performance SMPTE
> ST 2110 media streaming workflows.
>
> The "new code" in this series (specifically the testpmd enhancement in
> patch 6) demonstrates how the standard DPDK buffer-split offload can be
> orchestrated with pinned external-buffer mempools
> (RTE_PKTMBUF_POOL_F_PINNED_EXT_BUF) to achieve this. By pinning mbufs to
> contiguous hugepages, the NIC DMAs RTP payloads directly into application-
> owned memory. This eliminates the need for the header-split.
>
> Documentation and a concrete configuration example for this workflow are
> included in the testpmd user guide (patch 6/6). The new 'create pinned-rxpool'
> command serves as both a test vehicle and a reference implementation for
> integrators.
>
> In this series:
> - iavf maximum ring descriptor count to raised 4096 (HW limit).
> - iavf queue rate limit enabled reconfiguration at runtime.
> - Added opt-in "rl_burst_size" ice devarg for tighter packet spacing (jitter reduction).
> - Enabled PTP timestamping for all packets on ice.
> - Added opt-in "no_runtime_queue_setup" iavf devarg to restore strict
> initialization semantics when required.
>
> - Dropped the ethdev and net/intel "header-split mbuf callback" API
> - Replaced the out-of-tree approach with a testpmd demonstration (patch 6)
> of the standard, upstream-preferred pinned-external-buffer workflow.
> - Fixed iavf error propagation and committed-state logic (Stephen Hemminger).
> - Converted the ice scheduler burst reduction and iavf runtime-config
> disabling into opt-in devargs to preserve default behavior.
> - Updated documentation, commit messages, and .mailmap.
>
> Dawid Wesierski (1):
> app/testpmd: add pinned external-buffer Rx pool command
>
> Marek Kasiewicz (5):
> net/iavf: increase max ring descriptors to hardware limit
> net/iavf: allow runtime queue rate limit configuration
> net/ice: add scheduler rate-limiter burst size devarg
> net/ice: timestamp all received packets when PTP is enabled
> net/iavf: disable runtime queue setup capability
>
Since RC2 is fast approaching, I've taken the first 3 patches of this
series into next-net-intel.
For the remaining 3 patches, the two driver patches need some more
discussion and probably rework. The final patch, for test-pmd, goes in a
different tree (not next-net-intel), so please send it as a separate
standalone patch.
Thanks,
/Bruce
^ 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