* [PATCH 08/10] net/e1000/base: propagate PHY control register write error
From: Ciara Loftus @ 2026-05-20 12:52 UTC (permalink / raw)
To: dev; +Cc: Dima Ruinskiy, stable, Ciara Loftus
In-Reply-To: <20260520125256.354336-1-ciara.loftus@intel.com>
From: Dima Ruinskiy <dima.ruinskiy@intel.com>
During HV PHY workaround handling, a failure writing to the PHY control
register was silently discarded rather than returned to the caller. Add
the missing early return so the error is correctly propagated.
Fixes: 5a32a257f957 ("e1000: more NICs in base driver")
Cc: stable@dpdk.org
Signed-off-by: Dima Ruinskiy <dima.ruinskiy@intel.com>
Signed-off-by: Ciara Loftus <ciara.loftus@intel.com>
---
drivers/net/intel/e1000/base/e1000_ich8lan.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/intel/e1000/base/e1000_ich8lan.c b/drivers/net/intel/e1000/base/e1000_ich8lan.c
index e62847fb4e..0290a7dcb4 100644
--- a/drivers/net/intel/e1000/base/e1000_ich8lan.c
+++ b/drivers/net/intel/e1000/base/e1000_ich8lan.c
@@ -2696,6 +2696,8 @@ STATIC s32 e1000_hv_phy_workarounds_ich8lan(struct e1000_hw *hw)
e1000_phy_sw_reset_generic(hw);
ret_val = hw->phy.ops.write_reg(hw, PHY_CONTROL,
0x3140);
+ if (ret_val)
+ return ret_val;
}
}
--
2.43.0
^ permalink raw reply related
* [PATCH 09/10] net/e1000/base: auto-negotiation status for 1000BASE-T
From: Ciara Loftus @ 2026-05-20 12:52 UTC (permalink / raw)
To: dev; +Cc: Mateusz Fryze, Ciara Loftus
In-Reply-To: <20260520125256.354336-1-ciara.loftus@intel.com>
From: Mateusz Fryze <mateusz.fryze@intel.com>
Add functionality to find auto-negotiation status on 1000BASE-T PHYs
based on specific PHY registers.
Signed-off-by: Mateusz Fryze <mateusz.fryze@intel.com>
Signed-off-by: Ciara Loftus <ciara.loftus@intel.com>
---
.mailmap | 1 +
drivers/net/intel/e1000/base/e1000_82575.c | 1 +
drivers/net/intel/e1000/base/e1000_api.c | 16 ++++
drivers/net/intel/e1000/base/e1000_api.h | 1 +
drivers/net/intel/e1000/base/e1000_defines.h | 22 ++++++
drivers/net/intel/e1000/base/e1000_hw.h | 9 +++
drivers/net/intel/e1000/base/e1000_phy.c | 81 ++++++++++++++++++++
drivers/net/intel/e1000/base/e1000_phy.h | 2 +
8 files changed, 133 insertions(+)
diff --git a/.mailmap b/.mailmap
index f3130df686..4a211b1211 100644
--- a/.mailmap
+++ b/.mailmap
@@ -1033,6 +1033,7 @@ Masoud Hasanifard <masoudhasanifard@gmail.com>
Masoumeh Farhadi Nia <masoumeh.farhadinia@gmail.com>
Matan Azrad <matan@nvidia.com> <matan@mellanox.com>
Matej Vido <matejvido@gmail.com> <vido@cesnet.cz>
+Mateusz Fryze <mateusz.fryze@intel.com>
Mateusz Kowalski <mateusz.kowalski@intel.com>
Mateusz Pacuszka <mateuszx.pacuszka@intel.com>
Mateusz Polchlopek <mateusz.polchlopek@intel.com>
diff --git a/drivers/net/intel/e1000/base/e1000_82575.c b/drivers/net/intel/e1000/base/e1000_82575.c
index 8ae2b77d5f..a2b563975e 100644
--- a/drivers/net/intel/e1000/base/e1000_82575.c
+++ b/drivers/net/intel/e1000/base/e1000_82575.c
@@ -233,6 +233,7 @@ STATIC s32 e1000_init_phy_params_82575(struct e1000_hw *hw)
phy->ops.set_d3_lplu_state = e1000_set_d3_lplu_state_82580;
phy->ops.force_speed_duplex =
e1000_phy_force_speed_duplex_82577;
+ phy->ops.get_an_status = e1000_1gbase_t_autoneg_status;
break;
case I210_I_PHY_ID:
phy->type = e1000_phy_i210;
diff --git a/drivers/net/intel/e1000/base/e1000_api.c b/drivers/net/intel/e1000/base/e1000_api.c
index a7877613e3..83b3d6c439 100644
--- a/drivers/net/intel/e1000/base/e1000_api.c
+++ b/drivers/net/intel/e1000/base/e1000_api.c
@@ -1138,6 +1138,22 @@ s32 e1000_get_phy_info(struct e1000_hw *hw)
return E1000_SUCCESS;
}
+/**
+ * e1000_get_an_status - Finds Auto-negotiation status based on PHY registers
+ * @hw: pointer to the HW structure
+ * @an_status: AN status
+ *
+ * This function gets information from the PHY specific registers to determine
+ * Auto-negotiation status.
+ **/
+s32 e1000_get_an_status(struct e1000_hw *hw, u8 *an_status)
+{
+ if (hw->phy.ops.get_an_status)
+ return hw->phy.ops.get_an_status(hw, an_status);
+
+ return E1000_SUCCESS;
+}
+
/**
* e1000_phy_hw_reset - Hard PHY reset
* @hw: pointer to the HW structure
diff --git a/drivers/net/intel/e1000/base/e1000_api.h b/drivers/net/intel/e1000/base/e1000_api.h
index ca3248c214..1f81f49bd5 100644
--- a/drivers/net/intel/e1000/base/e1000_api.h
+++ b/drivers/net/intel/e1000/base/e1000_api.h
@@ -59,6 +59,7 @@ s32 e1000_write_phy_reg(struct e1000_hw *hw, u32 offset, u16 data);
s32 e1000_write_8bit_ctrl_reg(struct e1000_hw *hw, u32 reg, u32 offset,
u8 data);
s32 e1000_get_phy_info(struct e1000_hw *hw);
+s32 e1000_get_an_status(struct e1000_hw *hw, u8 *an_status);
void e1000_release_phy(struct e1000_hw *hw);
s32 e1000_acquire_phy(struct e1000_hw *hw);
s32 e1000_cfg_on_link_up(struct e1000_hw *hw);
diff --git a/drivers/net/intel/e1000/base/e1000_defines.h b/drivers/net/intel/e1000/base/e1000_defines.h
index 6c710300a6..ba12dde770 100644
--- a/drivers/net/intel/e1000/base/e1000_defines.h
+++ b/drivers/net/intel/e1000/base/e1000_defines.h
@@ -1103,6 +1103,28 @@
#define PHY_1000T_STATUS 0x0A /* 1000Base-T Status Reg */
#define PHY_EXT_STATUS 0x0F /* Extended Status Reg */
+/* PHY Status Register */
+#define PHY_STATUS_LINK_STATUS_SHIFT 2
+#define PHY_STATUS_AN_ABILITY_SHIFT 3
+#define PHY_STATUS_REMOTE_FAULT_SHIFT 4
+#define PHY_STATUS_AN_COMPLETE_SHIFT 5
+#define PHY_STATUS_LINK_STATUS_MASK (0x01 << PHY_STATUS_LINK_STATUS_SHIFT)
+#define PHY_STATUS_AN_ABILITY_MASK (0x01 << PHY_STATUS_AN_ABILITY_SHIFT)
+#define PHY_STATUS_REMOTE_FAULT_MASK (0x01 << PHY_STATUS_REMOTE_FAULT_SHIFT)
+#define PHY_STATUS_AN_COMPLETE_MASK (0x01 << PHY_STATUS_AN_COMPLETE_SHIFT)
+
+/* Auto negotiation Expansion Register */
+#define PHY_AUTONEG_EXP_LP_AN_ABLE_SHIFT 0
+#define PHY_AUTONEG_EXP_PAGE_RECVD_SHIFT 1
+#define PHY_AUTONEG_EXP_NEXT_PAGE_ABLE_SHIFT 2
+#define PHY_AUTONEG_EXP_LP_NEXT_PAGE_ABLE_SHIFT 3
+#define PHY_AUTONEG_EXP_PARALLEL_DETECT_FLT_SHIFT 4
+#define PHY_AUTONEG_EXP_LP_AN_ABLE_MASK (0x01 << PHY_AUTONEG_EXP_LP_AN_ABLE_SHIFT)
+#define PHY_AUTONEG_EXP_PAGE_RECVD_MASK (0x01 << PHY_AUTONEG_EXP_PAGE_RECVD_SHIFT)
+#define PHY_AUTONEG_EXP_NEXT_PAGE_ABLE_MASK (0x01 << PHY_AUTONEG_EXP_NEXT_PAGE_ABLE_SHIFT)
+#define PHY_AUTONEG_EXP_LP_NEXT_PAGE_ABLE_MASK (0x01 << PHY_AUTONEG_EXP_LP_NEXT_PAGE_ABLE_SHIFT)
+#define PHY_AUTONEG_EXP_PARALLEL_DETECT_FLT_MASK (0x01 << PHY_AUTONEG_EXP_PARALLEL_DETECT_FLT_SHIFT)
+
/* PHY GPY 211 registers */
#define STANDARD_AN_REG_MASK 0x0007 /* MMD */
#define ANEG_MULTIGBT_AN_CTRL 0x0020 /* MULTI GBT AN Control Register */
diff --git a/drivers/net/intel/e1000/base/e1000_hw.h b/drivers/net/intel/e1000/base/e1000_hw.h
index 9b1fafd75c..99c2195916 100644
--- a/drivers/net/intel/e1000/base/e1000_hw.h
+++ b/drivers/net/intel/e1000/base/e1000_hw.h
@@ -409,6 +409,14 @@ enum e1000_serdes_link_state {
e1000_serdes_link_forced_up
};
+enum e1000_autoneg_status {
+ e1000_an_off = 0, /* No conn.; AN unsupported, disabled, or disabled on the LP */
+ e1000_an_failed, /* Remote Fault or Parallel Detection Fault reported */
+ e1000_an_in_progress,
+ e1000_an_complete,
+ e1000_an_status_unavailable /* AN status could not be obtained */
+};
+
enum e1000_invm_structure_type {
e1000_invm_uninitialized_structure = 0x00,
e1000_invm_word_autoload_structure = 0x01,
@@ -803,6 +811,7 @@ struct e1000_phy_operations {
s32 (*write_reg_page)(struct e1000_hw *, u32, u16);
void (*power_up)(struct e1000_hw *);
void (*power_down)(struct e1000_hw *);
+ s32 (*get_an_status)(struct e1000_hw *, u8 *);
s32 (*read_i2c_byte)(struct e1000_hw *, u8, u8, u8 *);
s32 (*write_i2c_byte)(struct e1000_hw *, u8, u8, u8);
};
diff --git a/drivers/net/intel/e1000/base/e1000_phy.c b/drivers/net/intel/e1000/base/e1000_phy.c
index 31ef5089ba..c66ae44e7a 100644
--- a/drivers/net/intel/e1000/base/e1000_phy.c
+++ b/drivers/net/intel/e1000/base/e1000_phy.c
@@ -63,6 +63,7 @@ void e1000_init_phy_ops_generic(struct e1000_hw *hw)
phy->ops.write_reg_page = e1000_null_write_reg;
phy->ops.power_up = e1000_null_phy_generic;
phy->ops.power_down = e1000_null_phy_generic;
+ phy->ops.get_an_status = e1000_null_an_status;
phy->ops.read_i2c_byte = e1000_read_i2c_byte_null;
phy->ops.write_i2c_byte = e1000_write_i2c_byte_null;
phy->ops.cfg_on_link_up = e1000_null_ops_generic;
@@ -133,6 +134,21 @@ s32 e1000_null_write_reg(struct e1000_hw E1000_UNUSEDARG *hw,
return E1000_SUCCESS;
}
+/**
+ * e1000_null_link_info - No-op function, return 0
+ * @hw: pointer to the HW structure
+ * @status: dummy variable
+ **/
+s32 e1000_null_an_status(struct e1000_hw E1000_UNUSEDARG *hw,
+ u8 *status)
+{
+ DEBUGFUNC("e1000_null_an_status");
+ UNREFERENCED_1PARAMETER(hw);
+ *status = e1000_an_status_unavailable;
+
+ return E1000_SUCCESS;
+}
+
/**
* e1000_read_i2c_byte_null - No-op function, return 0
* @hw: pointer to hardware structure
@@ -2427,6 +2443,71 @@ STATIC s32 e1000_wait_autoneg(struct e1000_hw *hw)
return ret_val;
}
+/**
+ * e1000_1gbase_t_autoneg_status - Gets information on current AN status.
+ * @hw: pointer to the HW structure
+ * @an_status: pointer to the AN status
+ *
+ * The function finds the Auto-negotiation status of 1000BASE-T PHY based on
+ * the data from PHY Status (PSTATUS) and Auto–Negotiation Expansion (ANE)
+ * PHY registers.
+ *
+ * @note The function will report Auto-negotiation OFF when there is no
+ * media connected to the port. When used during the PHY reset, it might not
+ * report a valid status.
+ **/
+s32 e1000_1gbase_t_autoneg_status(struct e1000_hw *hw, u8 *an_status)
+{
+ s32 ret_val = E1000_SUCCESS;
+ u16 phy_reg = 0;
+
+ DEBUGFUNC("e1000_1gbase_t_autoneg_status\n");
+
+ do {
+ *an_status = e1000_an_status_unavailable;
+ ret_val = e1000_read_phy_reg(hw, PHY_STATUS, &phy_reg);
+ if (ret_val) {
+ DEBUGOUT1("Reading PHY STATUS register returned error: %X\n", ret_val);
+ break;
+ }
+
+ if (!(phy_reg & PHY_STATUS_AN_ABILITY_MASK)) {
+ *an_status = e1000_an_off;
+ break;
+ }
+
+ if (phy_reg & (PHY_STATUS_AN_COMPLETE_MASK | PHY_STATUS_LINK_STATUS_MASK)) {
+ *an_status = e1000_an_complete;
+ break;
+ }
+
+ if (phy_reg & PHY_STATUS_REMOTE_FAULT_MASK) {
+ *an_status = e1000_an_failed;
+ break;
+ }
+
+ ret_val = e1000_read_phy_reg(hw, PHY_AUTONEG_EXP, &phy_reg);
+ if (ret_val) {
+ DEBUGOUT1("Reading PHY ANE register returned error: %X\n", ret_val);
+ break;
+ }
+
+ if (!(phy_reg & PHY_AUTONEG_EXP_LP_AN_ABLE_MASK)) {
+ *an_status = e1000_an_off;
+ break;
+ }
+
+ if (phy_reg & PHY_AUTONEG_EXP_PARALLEL_DETECT_FLT_MASK) {
+ *an_status = e1000_an_failed;
+ break;
+ }
+
+ *an_status = e1000_an_in_progress;
+ } while (0);
+
+ return ret_val;
+}
+
/**
* e1000_phy_has_link_generic - Polls PHY for link
* @hw: pointer to the HW structure
diff --git a/drivers/net/intel/e1000/base/e1000_phy.h b/drivers/net/intel/e1000/base/e1000_phy.h
index 4c0b93c18f..d8fcc7ae10 100644
--- a/drivers/net/intel/e1000/base/e1000_phy.h
+++ b/drivers/net/intel/e1000/base/e1000_phy.h
@@ -11,6 +11,7 @@ void e1000_null_phy_generic(struct e1000_hw *hw);
s32 e1000_null_lplu_state(struct e1000_hw *hw, bool active);
s32 e1000_null_write_reg(struct e1000_hw *hw, u32 offset, u16 data);
s32 e1000_null_set_page(struct e1000_hw *hw, u16 data);
+s32 e1000_null_an_status(struct e1000_hw *hw, u8 *status);
s32 e1000_read_i2c_byte_null(struct e1000_hw *hw, u8 byte_offset,
u8 dev_addr, u8 *data);
s32 e1000_write_i2c_byte_null(struct e1000_hw *hw, u8 byte_offset,
@@ -22,6 +23,7 @@ s32 e1000_check_polarity_ife(struct e1000_hw *hw);
s32 e1000_check_reset_block_generic(struct e1000_hw *hw);
s32 e1000_phy_setup_autoneg(struct e1000_hw *hw);
s32 e1000_copper_link_autoneg(struct e1000_hw *hw);
+s32 e1000_1gbase_t_autoneg_status(struct e1000_hw *hw, u8 *an_status);
s32 e1000_copper_link_setup_igp(struct e1000_hw *hw);
s32 e1000_copper_link_setup_m88(struct e1000_hw *hw);
s32 e1000_copper_link_setup_m88_gen2(struct e1000_hw *hw);
--
2.43.0
^ permalink raw reply related
* [PATCH 10/10] net/e1000/base: update version info
From: Ciara Loftus @ 2026-05-20 12:52 UTC (permalink / raw)
To: dev; +Cc: Ciara Loftus
In-Reply-To: <20260520125256.354336-1-ciara.loftus@intel.com>
Update the last shared code update date.
Signed-off-by: Ciara Loftus <ciara.loftus@intel.com>
---
drivers/net/intel/e1000/base/README | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/intel/e1000/base/README b/drivers/net/intel/e1000/base/README
index 976391b170..f0c1e4af48 100644
--- a/drivers/net/intel/e1000/base/README
+++ b/drivers/net/intel/e1000/base/README
@@ -1,9 +1,9 @@
/* SPDX-License-Identifier: BSD-3-Clause
- * Copyright(c) 2010-2025 Intel Corporation
+ * Copyright(c) 2010-2026 Intel Corporation
*/
This directory contains source code of the base driver code for em/igb/igc,
-with this snapshot generated on 2025-06-04-14.40.
+with this snapshot generated on 2026-05-07-13.50.
This driver is valid for the product(s) listed below
* Intel® Ethernet Controller 82540
--
2.43.0
^ permalink raw reply related
* [PATCH] linux/mem: atomically prefault hugepages in alloc_seg
From: Michal Sieron @ 2026-05-20 12:57 UTC (permalink / raw)
To: dev; +Cc: Michal Sieron
In rare cases, when a secondary process calls rte_eal_init() it can
cause a data race during page prefaulting in alloc_seg().
An atomic compare-exchange in a loop should eliminate the data race.
Signed-off-by: Michal Sieron <michal.sieron@nokia.com>
---
lib/eal/linux/eal_memalloc.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/lib/eal/linux/eal_memalloc.c b/lib/eal/linux/eal_memalloc.c
index a39bc31c7b..cb92fda2e8 100644
--- a/lib/eal/linux/eal_memalloc.c
+++ b/lib/eal/linux/eal_memalloc.c
@@ -30,6 +30,7 @@
#include <rte_eal.h>
#include <rte_memory.h>
#include <rte_cycles.h>
+#include <rte_atomic.h>
#include "eal_filesystem.h"
#include "eal_internal_cfg.h"
@@ -600,7 +601,9 @@ alloc_seg(struct rte_memseg *ms, void *addr, int socket_id,
* that is already there, so read the old value, and write itback.
* kernel populates the page with zeroes initially.
*/
- *(volatile int *)addr = *(volatile int *)addr;
+ int snapshot = *(volatile int *)addr;
+ while (!rte_atomic_compare_exchange_strong((volatile int *)addr, &snapshot, snapshot))
+ ;
iova = rte_mem_virt2iova(addr);
if (iova == RTE_BAD_PHYS_ADDR) {
--
2.43.0
^ permalink raw reply related
* [PATCH] net/mlx5: remove nonsensical flow action class_id checks
From: Adrian Schollmeyer @ 2026-05-20 13:25 UTC (permalink / raw)
To: Dariusz Sosnowski, Viacheslav Ovsiienko, Bing Zhao, Ori Kam,
Suanming Mou, Matan Azrad, Michael Baum
Cc: dev, Michael Pfeiffer, stable, Adrian Schollmeyer
From: Michael Pfeiffer <m.pfeiffer@syseleven.de>
For a MODIFY_FIELD action, flow_hw_validate_action_modify_field() is
invoked and enforces class_id == 0 in the action's source and
destination, if the modified field is none of
RTE_FLOW_FIELD_GENEVE_OPT_*, as the value is used solely for GENEVE
fields.
However, this check is flawed due to the way rte_flow_field_data is
initialized. As it consists of unions and anonymous structs as members,
empty initialization of this struct or initializing just the tag_index
only guarantees initialization of the first union member, while the
remaining member's default initialization behavior is unspecified.
Therefore, depending on the compiler type, version and configuration,
the remaining members may either be default-initialized as well or
contain bytes from uninitialized memory. This causes the check to fail
depending on how the struct is initialized wherever it is used.
For example, rte_flow_configure() sometimes fails on mlx5 under these
circumstances with an error "destination class id is not supported"
during creation of representor tagging rules, as these internally use
MODIFY_FIELD actions in the following call stack:
1. rte_flow_configure
2. mlx5_flow_port_configure
3. flow_hw_configure
4. __flow_hw_configure
5. flow_hw_setup_tx_repr_tagging
6. flow_hw_create_tx_repr_tag_jump_acts_tmpl
--> various rte_flow_action_modify_field are initialized here, but
class_id remains uninitialized
7. __flow_hw_actions_template_create
8. mlx5_flow_hw_actions_validate
9. flow_hw_validate_action_modify_field
--> invoked with class_id containing uninitialized bytes and
non-GENEVE field type
Remove the two checks for class_id in the non-GENEVE case, as this field
is unused for these actions and avoids additional implicit dependencies
on the correct ordering of union members.
Fixes: 1caa89ec1891 ("net/mlx5: support GENEVE options modification")
Cc: stable@dpdk.org
Signed-off-by: Michael Pfeiffer <m.pfeiffer@syseleven.de>
Signed-off-by: Adrian Schollmeyer <a.schollmeyer@syseleven.de>
---
drivers/net/mlx5/mlx5_flow_hw.c | 8 --------
1 file changed, 8 deletions(-)
diff --git a/drivers/net/mlx5/mlx5_flow_hw.c b/drivers/net/mlx5/mlx5_flow_hw.c
index bca5b2769e..add48d7c8f 100644
--- a/drivers/net/mlx5/mlx5_flow_hw.c
+++ b/drivers/net/mlx5/mlx5_flow_hw.c
@@ -6264,10 +6264,6 @@ flow_hw_validate_action_modify_field(struct rte_eth_dev *dev,
return rte_flow_error_set(error, EINVAL,
RTE_FLOW_ERROR_TYPE_ACTION, action,
"destination tag index is not supported");
- if (action_conf->dst.class_id)
- return rte_flow_error_set(error, EINVAL,
- RTE_FLOW_ERROR_TYPE_ACTION, action,
- "destination class id is not supported");
}
if (mask_conf->dst.level != UINT8_MAX)
return rte_flow_error_set(error, EINVAL,
@@ -6290,10 +6286,6 @@ flow_hw_validate_action_modify_field(struct rte_eth_dev *dev,
return rte_flow_error_set(error, EINVAL,
RTE_FLOW_ERROR_TYPE_ACTION, action,
"source tag index is not supported");
- if (action_conf->src.class_id)
- return rte_flow_error_set(error, EINVAL,
- RTE_FLOW_ERROR_TYPE_ACTION, action,
- "source class id is not supported");
}
if (mask_conf->src.level != UINT8_MAX)
return rte_flow_error_set(error, EINVAL,
--
2.34.1
^ permalink raw reply related
* RE: [PATCH v2 2/2] ethdev: add telemetry endpoint for list names
From: Morten Brørup @ 2026-05-20 13:29 UTC (permalink / raw)
To: Chengwen Feng, thomas, stephen; +Cc: dev, andrew.rybchenko, bruce.richardson
In-Reply-To: <20260520093804.29102-3-fengchengwen@huawei.com>
> From: Chengwen Feng [mailto:fengchengwen@huawei.com]
> Sent: Wednesday, 20 May 2026 11.38
>
> Add /ethdev/list_names telemetry endpoint which returns a dictionary
> keyed by port ID with device name as the value, so users can
> identify ports by name directly from the telemetry output.
>
> Original /ethdev/list output:
> {"/ethdev/list": [0, 1]}
>
> New /ethdev/list_names output:
> {"/ethdev/list_names": {"0": "0000:7d:00.0",
> "1": "0000:7d:00.1"}}
>
<rant>
Unfortunately, the telemetry protocol in DPDK is not using a common design, but takes parameters specific to each path.
It should have used OData or something similar, to standardize listing, filtering, etc.
Then we could have queried this like:
/ethdev/info?$select=port_id,name
And return something like:
[
{
"port_id": 0,
"name": "0000:7d:00.0"
},
{
"port_id": 1,
"name": "0000:7d:00.1"
}
]
or:
[
{
0,
"0000:7d:00.0"
},
{
1,
"0000:7d:00.1"
}
]
But now we are stuck with what we have.
</rant>
So /etdev/list_names is OK.
I'm not really familiar with the DPDK telemetry, so I wonder if indexed arrays are normally returned as an object, like in this patch?
I would have expected a list function (such as list_names) to return an array.
Either a simple list:
{
"/ethdev/list_names":
[
"0000:7d:00.0",
"0000:7d:00.1"
]
}
Or a list of objects:
{
"/ethdev/list_names":
[
{
"port_id": 0,
"name": "0000:7d:00.0"
},
{
"port_id": 1,
"name": "0000:7d:00.1"
}
]
}
^ permalink raw reply
* RE: [RFC PATCH 0/8] remove use of rte_memcpy from net/intel
From: Morten Brørup @ 2026-05-20 13:50 UTC (permalink / raw)
To: Bruce Richardson, Stephen Hemminger; +Cc: dev
In-Reply-To: <ag1me_1XSByq3p9V@bricha3-mobl1.ger.corp.intel.com>
> From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> Sent: Wednesday, 20 May 2026 09.45
PATCH 0/8] remove use of rte_memcpy from net/intel
>
> On Tue, May 19, 2026 at 12:43:32PM -0700, Stephen Hemminger wrote:
> > On Tue, 19 May 2026 16:05:57 +0000
> > Bruce Richardson <bruce.richardson@intel.com> wrote:
> >
> > > This RFC proposed to replace all instances of rte_memcpy in Intel
> > > (and former-Intel) net drivers with just regular memcpy. This is
> > > done on the basis that the memcpy use is not datapath, but is used
> > > for flow configuration, virt-channel (to firmware or PF) messaging
> > > and other control path functions.
> >
> > Makes sense. You might also want to look for where structure
> > assignment can be used instead of memcpy. Keeping data types
> > is a good thing.
>
> Yes, it would be nice to use in places. However, it's not a mechanical
> change so I've not taken the time to do the analysis. Just a quick set
> of sed replacements for this RFC.
If you consider structure assignment, look out for fixed-size structures ending with field[1]; they are really (ill defined) flex-arrays.
^ permalink raw reply
* Re: [PATCH v5 0/2] Update Rx Timestamp in IAVF PMD
From: Bruce Richardson @ 2026-05-20 14:52 UTC (permalink / raw)
To: Soumyadeep Hore; +Cc: manoj.kumar.subbarao, aman.deep.singh, dev
In-Reply-To: <20260520184350.81934-1-soumyadeep.hore@intel.com>
On Wed, May 20, 2026 at 02:43:48PM -0400, Soumyadeep Hore wrote:
> PHC Polling from Rx Datapath is removed and existing alarm handlers are
> used to fix latency issues in IAVF PMD.
> ---
Series-acked-by: Bruce Richardson <bruce.richardson@intel.com>
Applied to next-net-intel.
Thanks,
/Bruce
^ permalink raw reply
* Re: [RFC PATCH 0/8] remove use of rte_memcpy from net/intel
From: Bruce Richardson @ 2026-05-20 14:53 UTC (permalink / raw)
To: Morten Brørup; +Cc: Stephen Hemminger, dev
In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35F65888@smartserver.smartshare.dk>
On Wed, May 20, 2026 at 03:50:34PM +0200, Morten Brørup wrote:
> > From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> > Sent: Wednesday, 20 May 2026 09.45
> PATCH 0/8] remove use of rte_memcpy from net/intel
> >
> > On Tue, May 19, 2026 at 12:43:32PM -0700, Stephen Hemminger wrote:
> > > On Tue, 19 May 2026 16:05:57 +0000
> > > Bruce Richardson <bruce.richardson@intel.com> wrote:
> > >
> > > > This RFC proposed to replace all instances of rte_memcpy in Intel
> > > > (and former-Intel) net drivers with just regular memcpy. This is
> > > > done on the basis that the memcpy use is not datapath, but is used
> > > > for flow configuration, virt-channel (to firmware or PF) messaging
> > > > and other control path functions.
> > >
> > > Makes sense. You might also want to look for where structure
> > > assignment can be used instead of memcpy. Keeping data types
> > > is a good thing.
> >
> > Yes, it would be nice to use in places. However, it's not a mechanical
> > change so I've not taken the time to do the analysis. Just a quick set
> > of sed replacements for this RFC.
>
> If you consider structure assignment, look out for fixed-size structures ending with field[1]; they are really (ill defined) flex-arrays.
>
Yep, they were mentioned in a previous discussion on-list with Anatoly too.
Three is always more cleanup to be done! :-)
^ permalink raw reply
* Re: [PATCH 0/2] enhance telemetry list endpoint with device name
From: Stephen Hemminger @ 2026-05-20 14:54 UTC (permalink / raw)
To: Bruce Richardson; +Cc: fengchengwen, Morten Brørup, thomas, dev
In-Reply-To: <ag1nny7mJpM1pum6@bricha3-mobl1.ger.corp.intel.com>
On Wed, 20 May 2026 08:49:51 +0100
Bruce Richardson <bruce.richardson@intel.com> wrote:
> On Wed, May 20, 2026 at 03:31:57PM +0800, fengchengwen wrote:
> > On 5/20/2026 1:40 PM, Morten Brørup wrote:
> > >> From: Chengwen Feng [mailto:fengchengwen@huawei.com]
> > >> Sent: Wednesday, 20 May 2026 05.57
> > >>
> > >> Currently, the /dmadev/list and /ethdev/list telemetry endpoints return
> > >> only integer IDs, making it hard to identify devices. This series
> > >> changes
> > >> both to output strings in "ID NAME" format for better usability.
> > >
> > > For machine reading of the JSON output, it would be better returning an object with an integer and a string field, {ID, "NAME"}.
> >
> > The TEL_DICT could do {"ID", "NAME"}, which like:
> > "/ethdev/list": {
> > "0": "0000:7d:00.0",
> > "1": "0000:7d:00.1"
> > }
> >
> > Maybe we could add one TEL_INT_DICT which is int-value pairs, we may get:
> > "/ethdev/list": {
> > 0: "0000:7d:00.0",
> > 1: "0000:7d:00.1"
> > }
> >
> > I prefer the first one, However, the capacity is reduced from 512 (RTE_TEL_MAX_ARRAY_ENTRIES) to 256 (RTE_TEL_MAX_DICT_ENTRIES), but I think it is enough.
> >
> > What's your opinion?
> >
>
> I'm not sure about this change at all. This change is only relevant for
> those using the script interactively, for any other use, I would expect the
> the /ethdev/list call would be followed by the /ethdev/info calls for each
> port to get the name. That was the basic design in mind for this, the list
> call was purely to provide the ids, any other info you make separate calls
> for.
>
> Also, while not officially part of the ABI of DPDK, I think it would be
> wrong to go changing the types of the returned data from this /ethdev/list
> call. Any user-written interfaces to telemetry will be relying on the
> current behaviour to list and query ports. If you really want to have an
> easy way to get the names of the ports, I suggest adding instead an
> "/ethdev/list_names" API, which can either return the objects above, or
> else simply an array of names.
>
> /Bruce
The new wireshark extcap needs similar device list.
Ideally returning similar format to existing dpdk-dumpcap -D
^ permalink raw reply
* Re: [PATCH] linux/mem: atomically prefault hugepages in alloc_seg
From: Stephen Hemminger @ 2026-05-20 14:57 UTC (permalink / raw)
To: Michal Sieron; +Cc: dev
In-Reply-To: <20260520125756.530808-1-michal.sieron@nokia.com>
On Wed, 20 May 2026 14:57:56 +0200
Michal Sieron <michal.sieron@nokia.com> wrote:
> In rare cases, when a secondary process calls rte_eal_init() it can
> cause a data race during page prefaulting in alloc_seg().
>
> An atomic compare-exchange in a loop should eliminate the data race.
>
> Signed-off-by: Michal Sieron <michal.sieron@nokia.com>
> ---
> lib/eal/linux/eal_memalloc.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/lib/eal/linux/eal_memalloc.c b/lib/eal/linux/eal_memalloc.c
> index a39bc31c7b..cb92fda2e8 100644
> --- a/lib/eal/linux/eal_memalloc.c
> +++ b/lib/eal/linux/eal_memalloc.c
> @@ -30,6 +30,7 @@
> #include <rte_eal.h>
> #include <rte_memory.h>
> #include <rte_cycles.h>
> +#include <rte_atomic.h>
>
> #include "eal_filesystem.h"
> #include "eal_internal_cfg.h"
> @@ -600,7 +601,9 @@ alloc_seg(struct rte_memseg *ms, void *addr, int socket_id,
> * that is already there, so read the old value, and write itback.
> * kernel populates the page with zeroes initially.
> */
> - *(volatile int *)addr = *(volatile int *)addr;
> + int snapshot = *(volatile int *)addr;
> + while (!rte_atomic_compare_exchange_strong((volatile int *)addr, &snapshot, snapshot))
> + ;
>
> iova = rte_mem_virt2iova(addr);
> if (iova == RTE_BAD_PHYS_ADDR) {
No don't use a loop with compare_exchange_strong here.
It could get stuck.
Should just a an relaxed load be enough to get the page in?
^ permalink raw reply
* Re: [PATCH v2 2/2] ethdev: add telemetry endpoint for list names
From: Bruce Richardson @ 2026-05-20 14:58 UTC (permalink / raw)
To: Morten Brørup; +Cc: Chengwen Feng, thomas, stephen, dev, andrew.rybchenko
In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35F65887@smartserver.smartshare.dk>
On Wed, May 20, 2026 at 03:29:36PM +0200, Morten Brørup wrote:
> > From: Chengwen Feng [mailto:fengchengwen@huawei.com]
> > Sent: Wednesday, 20 May 2026 11.38
> >
> > Add /ethdev/list_names telemetry endpoint which returns a dictionary
> > keyed by port ID with device name as the value, so users can
> > identify ports by name directly from the telemetry output.
> >
> > Original /ethdev/list output:
> > {"/ethdev/list": [0, 1]}
> >
> > New /ethdev/list_names output:
> > {"/ethdev/list_names": {"0": "0000:7d:00.0",
> > "1": "0000:7d:00.1"}}
> >
>
> <rant>
>
> Unfortunately, the telemetry protocol in DPDK is not using a common design, but takes parameters specific to each path.
> It should have used OData or something similar, to standardize listing, filtering, etc.
> Then we could have queried this like:
> /ethdev/info?$select=port_id,name
If you are up for implementing something like that, it should be possible
to have syntax like the above work alongside our existing syntax too.
The current telemetry scheme was set up with the overarching objective
being simplicity.
> And return something like:
> [
> {
> "port_id": 0,
> "name": "0000:7d:00.0"
> },
> {
> "port_id": 1,
> "name": "0000:7d:00.1"
> }
> ]
> or:
> [
> {
> 0,
> "0000:7d:00.0"
> },
> {
> 1,
> "0000:7d:00.1"
> }
> ]
>
> But now we are stuck with what we have.
>
> </rant>
>
> So /etdev/list_names is OK.
>
> I'm not really familiar with the DPDK telemetry, so I wonder if indexed arrays are normally returned as an object, like in this patch?
>
> I would have expected a list function (such as list_names) to return an array.
> Either a simple list:
> {
> "/ethdev/list_names":
> [
> "0000:7d:00.0",
> "0000:7d:00.1"
> ]
> }
>
I think it would prefer this, but it does get a bit harder to read with a
long list.
> Or a list of objects:
> {
> "/ethdev/list_names":
> [
> {
> "port_id": 0,
> "name": "0000:7d:00.0"
> },
> {
> "port_id": 1,
> "name": "0000:7d:00.1"
> }
> ]
> }
>
Agree that this also would be slightly better.
However, a *completely* different approach would be to instead solve this
issue by adding additional functionality to the interactive telemetry
script itself. After all, the data for the list of names of ethdevs is
already available from the telemetry endpoints already present in DPDK. All
we need to do is to extend the python script to have "virtual endpoints" if
you will, which do the necessary queries in the background and then present
the data to the user. I think that would be a cleaner approach to things
like this, rather than always adding more C code.
/Bruce
^ permalink raw reply
* Re: [PATCH 1/2] dmadev: include device name in telemetry list output
From: Stephen Hemminger @ 2026-05-20 15:03 UTC (permalink / raw)
To: Chengwen Feng; +Cc: thomas, dev
In-Reply-To: <20260520035641.50555-2-fengchengwen@huawei.com>
On Wed, 20 May 2026 11:56:40 +0800
Chengwen Feng <fengchengwen@huawei.com> wrote:
> After this commit:
> {
> "/dmadev/list": [
> "0 hisi_sec2-0-dma0",
> "1 hisi_sec2-0-dma1"
> ]
> }
That is awkward JSON. Better to not have the 0 and 1 prefixes.
Typical usage will read JSON in python and array index would
be implicit.
^ permalink raw reply
* RE: [PATCH] net/ice: fix TM node ID validation against configured queues
From: Loftus, Ciara @ 2026-05-20 15:03 UTC (permalink / raw)
To: Richardson, Bruce; +Cc: dev@dpdk.org, stable@dpdk.org
In-Reply-To: <agx6kiQyvHZJ96ob@bricha3-mobl1.ger.corp.intel.com>
> >
> > Fixes: 715d449a965b ("net/ice: enhance Tx scheduler hierarchy support")
>
> I think this fix will cause other issues when we want to use large numbers
> of queues. From the commit log for 715d449a965b:
>
> "If the HW/firmware allows it, allow creating up to 2k child
> nodes per scheduler node. Also expand the number of supported layers to
> the max available, rather than always just having 3 layers. One
> restriction on this change is that the topology needs to be configured
> and enabled before port queue setup"
>
> The last part is significant - the number of configured queues must be
> supported by a scheduler hierarchy with enough nodes at the next,
> queue-group level. Therefore, before configuring large numbers of queues we
> need to configure a non-default hierarchy. Therefore, when running this
> check the value of nb_txq is not known, which is why the original patch
> changed the check to RTE_MAX_QUEUES_PER_PORT.
>
> However, you correctly point out in this fix, that that is not according to
> the spec for rte_tm. Therefore, I suggest changing the check, if possible:
>
> * if nb_txq == 0 (i.e. no queues configured yet), then keep as-is with
> MAX_QUEUES
> * for cases where nb_txq != 0, then use nb_txq.
>
> Does that seem sensible, or any better alternatives you can see?
That makes sense Bruce, I cannot think of a better alternative.
I'll submit a v2 with your suggestion in place.
Thanks,
Ciara
>
> /Bruce
>
>
^ permalink raw reply
* Re: [V1 1/1] net/hinic3: Add VXLAN TSO function
From: Stephen Hemminger @ 2026-05-20 15:06 UTC (permalink / raw)
To: Feifei Wang; +Cc: dev, Feifei Wang
In-Reply-To: <20260520065817.931-2-wff_light@vip.163.com>
On Wed, 20 May 2026 14:58:15 +0800
Feifei Wang <wff_light@vip.163.com> wrote:
> The RTE_ETH_TX_OFFLOAD_VXLAN_TNL_TSO flag is added to support the VXLAN TSO function
>
> Signed-off-by: Feifei Wang <wangfeifei40@huawei.com>
> ---
You need to do more than just advertise the capability to get the driver
to actually work right.
AI explanation:
Error: VXLAN TSO is advertised unconditionally but the underlying hardware
feature is not. The patch adds RTE_ETH_TX_OFFLOAD_VXLAN_TNL_TSO to the
unconditional tx_offload_capa assignment in hinic3_dev_infos_get(), but
the Tx path in drivers/net/hinic3/hinic3_tx.c:306-313 rejects every VXLAN
tunnel mbuf when the hardware does not have NIC_F_VXLAN_OFFLOAD:
^ permalink raw reply
* [PATCH v2] net/ice: fix TM node ID validation against configured queues
From: Ciara Loftus @ 2026-05-20 15:07 UTC (permalink / raw)
To: dev; +Cc: Ciara Loftus, stable
In-Reply-To: <20260505123157.1387791-1-ciara.loftus@intel.com>
The leaf node ID boundary is checked against the compile-time constant
`RTE_MAX_QUEUES_PER_PORT` (1024) rather than the number of configured Tx
queues. The rte_tm specification reserves IDs 0 to N-1 for leaf nodes
where N is the configured queue count, so using the constant produces
wrong results whenever N is less than 1024.
Fix by using `nb_tx_queues` as the boundary when queues have been
configured, falling back to `RTE_MAX_QUEUES_PER_PORT` when `nb_tx_queues`
is zero. The zero case arises when the TM hierarchy is built before port
queue configuration, which is required to support queue counts beyond
the hardware default.
Also add an explicit check in the non-leaf validation path that rejects
IDs in the leaf-reserved range. This condition can be triggered two ways:
adding a leaf node before its parent chain is complete (the node resolves
to a non-leaf level), or assigning a leaf-range ID to a node intended
as non-leaf.
Fixes: 715d449a965b ("net/ice: enhance Tx scheduler hierarchy support")
Cc: stable@dpdk.org
Signed-off-by: Ciara Loftus <ciara.loftus@intel.com>
---
drivers/net/intel/ice/ice_tm.c | 16 +++++++++++++---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/net/intel/ice/ice_tm.c b/drivers/net/intel/ice/ice_tm.c
index 015a827d7a..bf2ac117b1 100644
--- a/drivers/net/intel/ice/ice_tm.c
+++ b/drivers/net/intel/ice/ice_tm.c
@@ -88,8 +88,11 @@ ice_node_param_check(uint32_t node_id,
uint32_t priority, uint32_t weight,
const struct rte_tm_node_params *params,
bool is_leaf,
+ uint16_t nb_txq,
struct rte_tm_error *error)
{
+ uint32_t max_leaf_id = (nb_txq != 0) ? nb_txq : RTE_MAX_QUEUES_PER_PORT;
+
/* checked all the unsupported parameter */
if (node_id == RTE_TM_NODE_ID_NULL) {
error->type = RTE_TM_ERROR_TYPE_NODE_ID;
@@ -123,6 +126,11 @@ ice_node_param_check(uint32_t node_id,
/* for non-leaf node */
if (!is_leaf) {
+ if (node_id < max_leaf_id) {
+ error->type = RTE_TM_ERROR_TYPE_NODE_ID;
+ error->message = "node ID is reserved for leaf nodes";
+ return -EINVAL;
+ }
if (params->nonleaf.wfq_weight_mode) {
error->type =
RTE_TM_ERROR_TYPE_NODE_PARAMS_WFQ_WEIGHT_MODE;
@@ -146,7 +154,7 @@ ice_node_param_check(uint32_t node_id,
}
/* for leaf node */
- if (node_id >= RTE_MAX_QUEUES_PER_PORT) {
+ if (node_id >= max_leaf_id) {
error->type = RTE_TM_ERROR_TYPE_NODE_ID;
error->message = "Node ID out of range for a leaf node.";
return -EINVAL;
@@ -440,7 +448,8 @@ ice_tm_node_add(struct rte_eth_dev *dev, uint32_t node_id,
return -EINVAL;
}
- ret = ice_node_param_check(node_id, priority, weight, params, false, error);
+ ret = ice_node_param_check(node_id, priority, weight, params, false,
+ dev->data->nb_tx_queues, error);
if (ret)
return ret;
@@ -481,7 +490,8 @@ ice_tm_node_add(struct rte_eth_dev *dev, uint32_t node_id,
}
ret = ice_node_param_check(node_id, priority, weight,
- params, level_id == ice_get_leaf_level(pf), error);
+ params, level_id == ice_get_leaf_level(pf),
+ dev->data->nb_tx_queues, error);
if (ret)
return ret;
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v2] net/ice: fix TM node ID validation against configured queues
From: Bruce Richardson @ 2026-05-20 15:24 UTC (permalink / raw)
To: Ciara Loftus; +Cc: dev, stable
In-Reply-To: <20260520150717.365942-1-ciara.loftus@intel.com>
On Wed, May 20, 2026 at 03:07:16PM +0000, Ciara Loftus wrote:
> The leaf node ID boundary is checked against the compile-time constant
> `RTE_MAX_QUEUES_PER_PORT` (1024) rather than the number of configured Tx
> queues. The rte_tm specification reserves IDs 0 to N-1 for leaf nodes
> where N is the configured queue count, so using the constant produces
> wrong results whenever N is less than 1024.
>
> Fix by using `nb_tx_queues` as the boundary when queues have been
> configured, falling back to `RTE_MAX_QUEUES_PER_PORT` when `nb_tx_queues`
> is zero. The zero case arises when the TM hierarchy is built before port
> queue configuration, which is required to support queue counts beyond
> the hardware default.
>
> Also add an explicit check in the non-leaf validation path that rejects
> IDs in the leaf-reserved range. This condition can be triggered two ways:
> adding a leaf node before its parent chain is complete (the node resolves
> to a non-leaf level), or assigning a leaf-range ID to a node intended
> as non-leaf.
>
> Fixes: 715d449a965b ("net/ice: enhance Tx scheduler hierarchy support")
> Cc: stable@dpdk.org
>
> Signed-off-by: Ciara Loftus <ciara.loftus@intel.com>
> ---
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
^ permalink raw reply
* Re: [PATCH v19 00/11]net/sxe2: fix logic errors and address feedback
From: Stephen Hemminger @ 2026-05-20 15:38 UTC (permalink / raw)
To: liujie5; +Cc: dev
In-Reply-To: <20260520021809.4019054-1-liujie5@linkdatatechnology.com>
On Wed, 20 May 2026 10:17:58 +0800
liujie5@linkdatatechnology.com wrote:
> From: Jie Liu <liujie5@linkdatatechnology.com>
>
> This patch set addresses the feedback received on the v10 and v18
> submissions for the sxe2 PMD. The primary focus is on fixing vector
> path selection, ensuring memory safety during mbuf initialization,
> and cleaning up redundant logic in the configuration functions.
>
> v19 Changes:
> - Fixed vector Rx burst function being overwritten by scalar selection.
> - Refactored Rx/Tx mode set functions to seed flags from caps first,
> eliminating tautological checks.
> - Added memset for mbuf_def in vector init to avoid uninitialized reads.
> - Converted pci_map_addr_info to designated initializers.
> - Removed dead Windows-only code in meson.build.
> - Added NULL checks for mbuf free for driver-wide consistency.
> - Updated burst_mode_get to accurately report AVX paths.
> - Adjusted SXE2_ETH_OVERHEAD to match actual VLAN capabilities.
>
> Jie Liu (11):
> mailmap: add Jie Liu
> doc: add sxe2 guide and release notes
> common/sxe2: add sxe2 basic structures
> drivers: add base driver skeleton
> drivers: add base driver probe skeleton
> drivers: support PCI BAR mapping
> common/sxe2: add ioctl interface for DMA map and unmap
> net/sxe2: support queue setup and control
> drivers: add data path for Rx and Tx
> net/sxe2: add vectorized Rx and Tx
> net/sxe2: implement Tx done cleanup
>
> .mailmap | 1 +
> doc/guides/nics/features/sxe2.ini | 23 +
> doc/guides/nics/index.rst | 1 +
> doc/guides/nics/sxe2.rst | 34 +
> doc/guides/rel_notes/release_26_07.rst | 4 +
> drivers/common/sxe2/meson.build | 15 +
> drivers/common/sxe2/sxe2_common.c | 683 +++++++++++++
> drivers/common/sxe2/sxe2_common.h | 85 ++
> drivers/common/sxe2/sxe2_common_log.h | 81 ++
> drivers/common/sxe2/sxe2_host_regs.h | 707 +++++++++++++
> drivers/common/sxe2/sxe2_internal_ver.h | 33 +
> drivers/common/sxe2/sxe2_ioctl_chnl.c | 325 ++++++
> drivers/common/sxe2/sxe2_ioctl_chnl.h | 130 +++
> drivers/common/sxe2/sxe2_ioctl_chnl_func.h | 62 ++
> drivers/common/sxe2/sxe2_osal.h | 153 +++
> drivers/meson.build | 1 +
> drivers/net/meson.build | 1 +
> drivers/net/sxe2/meson.build | 32 +
> drivers/net/sxe2/sxe2_cmd_chnl.c | 323 ++++++
> drivers/net/sxe2/sxe2_cmd_chnl.h | 37 +
> drivers/net/sxe2/sxe2_drv_cmd.h | 388 ++++++++
> drivers/net/sxe2/sxe2_ethdev.c | 968 ++++++++++++++++++
> drivers/net/sxe2/sxe2_ethdev.h | 318 ++++++
> drivers/net/sxe2/sxe2_irq.h | 48 +
> drivers/net/sxe2/sxe2_queue.c | 66 ++
> drivers/net/sxe2/sxe2_queue.h | 195 ++++
> drivers/net/sxe2/sxe2_rx.c | 554 +++++++++++
> drivers/net/sxe2/sxe2_rx.h | 32 +
> drivers/net/sxe2/sxe2_tx.c | 420 ++++++++
> drivers/net/sxe2/sxe2_tx.h | 32 +
> drivers/net/sxe2/sxe2_txrx.c | 352 +++++++
> drivers/net/sxe2/sxe2_txrx.h | 23 +
> drivers/net/sxe2/sxe2_txrx_common.h | 540 ++++++++++
> drivers/net/sxe2/sxe2_txrx_poll.c | 1044 ++++++++++++++++++++
> drivers/net/sxe2/sxe2_txrx_poll.h | 20 +
> drivers/net/sxe2/sxe2_txrx_vec.c | 201 ++++
> drivers/net/sxe2/sxe2_txrx_vec.h | 63 ++
> drivers/net/sxe2/sxe2_txrx_vec_common.h | 235 +++++
> drivers/net/sxe2/sxe2_txrx_vec_sse.c | 549 ++++++++++
> drivers/net/sxe2/sxe2_vsi.c | 214 ++++
> drivers/net/sxe2/sxe2_vsi.h | 204 ++++
> 41 files changed, 9197 insertions(+)
> create mode 100644 doc/guides/nics/features/sxe2.ini
> create mode 100644 doc/guides/nics/sxe2.rst
> create mode 100644 drivers/common/sxe2/meson.build
> create mode 100644 drivers/common/sxe2/sxe2_common.c
> create mode 100644 drivers/common/sxe2/sxe2_common.h
> create mode 100644 drivers/common/sxe2/sxe2_common_log.h
> create mode 100644 drivers/common/sxe2/sxe2_host_regs.h
> create mode 100644 drivers/common/sxe2/sxe2_internal_ver.h
> create mode 100644 drivers/common/sxe2/sxe2_ioctl_chnl.c
> create mode 100644 drivers/common/sxe2/sxe2_ioctl_chnl.h
> create mode 100644 drivers/common/sxe2/sxe2_ioctl_chnl_func.h
> create mode 100644 drivers/common/sxe2/sxe2_osal.h
> create mode 100644 drivers/net/sxe2/meson.build
> create mode 100644 drivers/net/sxe2/sxe2_cmd_chnl.c
> create mode 100644 drivers/net/sxe2/sxe2_cmd_chnl.h
> create mode 100644 drivers/net/sxe2/sxe2_drv_cmd.h
> create mode 100644 drivers/net/sxe2/sxe2_ethdev.c
> create mode 100644 drivers/net/sxe2/sxe2_ethdev.h
> create mode 100644 drivers/net/sxe2/sxe2_irq.h
> create mode 100644 drivers/net/sxe2/sxe2_queue.c
> create mode 100644 drivers/net/sxe2/sxe2_queue.h
> create mode 100644 drivers/net/sxe2/sxe2_rx.c
> create mode 100644 drivers/net/sxe2/sxe2_rx.h
> create mode 100644 drivers/net/sxe2/sxe2_tx.c
> create mode 100644 drivers/net/sxe2/sxe2_tx.h
> create mode 100644 drivers/net/sxe2/sxe2_txrx.c
> create mode 100644 drivers/net/sxe2/sxe2_txrx.h
> create mode 100644 drivers/net/sxe2/sxe2_txrx_common.h
> create mode 100644 drivers/net/sxe2/sxe2_txrx_poll.c
> create mode 100644 drivers/net/sxe2/sxe2_txrx_poll.h
> create mode 100644 drivers/net/sxe2/sxe2_txrx_vec.c
> create mode 100644 drivers/net/sxe2/sxe2_txrx_vec.h
> create mode 100644 drivers/net/sxe2/sxe2_txrx_vec_common.h
> create mode 100644 drivers/net/sxe2/sxe2_txrx_vec_sse.c
> create mode 100644 drivers/net/sxe2/sxe2_vsi.c
> create mode 100644 drivers/net/sxe2/sxe2_vsi.h
>
Applied to next-net with minor merge fixup to release note
^ permalink raw reply
* Re: [PATCH] net/ice: improve log messages for DDP loading
From: David Marchand @ 2026-05-20 15:44 UTC (permalink / raw)
To: Bruce Richardson; +Cc: dev, patrick.mahan, Anatoly Burakov
In-Reply-To: <agykrWAcEnOBZvY-@bricha3-mobl1.ger.corp.intel.com>
On Tue, 19 May 2026 at 19:58, Bruce Richardson
<bruce.richardson@intel.com> wrote:
>
> On Sat, May 16, 2026 at 12:19:41PM +0200, David Marchand wrote:
> > Some nics may not provide a serial number (PCI capability
> > RTE_PCI_EXT_CAP_ID_DSN).
> >
> > This results in a confusing ERROR log:
> > ICE_INIT: ice_dev_init(): Failed to read device serial number
> >
> > This is confusing as DDP loading does *not* require the serial number to
> > be present for the port to be functional afterwards.
> >
> > Besides, after trying various path, if the default DDP is not present on
> > the runtime system, the port initialisation ends up with a vague error:
> > ICE_INIT: ice_load_pkg(): failed to search file path
> >
> > Improve the situation with adjusting the log level when reading the
> > SN fails, then add more debug context to DDP file loading and end up
> > with a ERROR log mentioning the expected file.
> >
> > ICE_INIT: ice_firmware_read(): Cannot read DDP file
> > /lib/firmware/updates/intel/ice/ddp/ice-b49691ffffe6e69c.pkg
> > ICE_INIT: ice_firmware_read(): Cannot read DDP file
> > /lib/firmware/intel/ice/ddp/ice-b49691ffffe6e69c.pkg
> > ICE_INIT: ice_firmware_read(): Cannot read DDP file
> > /lib/firmware/updates/intel/ice/ddp/ice.pkg
> > ICE_INIT: ice_firmware_read(): Cannot read DDP file
> > /lib/firmware/intel/ice/ddp/ice.pkg
> > ICE_INIT: ice_load_pkg(): Failed to load default DDP package
> > /lib/firmware/intel/ice/ddp/ice.pkg
> >
> > Signed-off-by: David Marchand <david.marchand@redhat.com>
> > ---
> > drivers/net/intel/ice/ice_ethdev.c | 31 ++++++++++++++++++++----------
> > 1 file changed, 21 insertions(+), 10 deletions(-)
> >
> On top of the changes made in this patch, how about something like the
> below to extend things?
>
> Rather than just debug logging the failed paths, we change the debug logs
> to always log each load attempt. We also record the path as it's attempted,
> and then on failure to load any path we use that record to print out an
> error message for each failure, so the user can see in the error logs ALL
> the failed paths, rather than having to re-run the app at debug level to
> find them.
>
> WDYT?
That's a lot of code for something that is usually detected right at
the first installation/run of your DPDK application.
When you are at this point, restarting testpmd with the right debug
level is the usual way.
But let's say you can't restart your application, log levels can be
changed dynamically (possible with testpmd, grout and OVS)
before/after trying to probe the E810 device.
--
David Marchand
^ permalink raw reply
* Re: [PATCH] net/ice: improve log messages for DDP loading
From: Bruce Richardson @ 2026-05-20 15:52 UTC (permalink / raw)
To: David Marchand; +Cc: dev, patrick.mahan, Anatoly Burakov
In-Reply-To: <CAJFAV8yLBFGVqOvfQ4SEZmy61g7xR4vrra7vyxG_NCc=4y1O7g@mail.gmail.com>
On Wed, May 20, 2026 at 05:44:14PM +0200, David Marchand wrote:
> On Tue, 19 May 2026 at 19:58, Bruce Richardson
> <bruce.richardson@intel.com> wrote:
> >
> > On Sat, May 16, 2026 at 12:19:41PM +0200, David Marchand wrote:
> > > Some nics may not provide a serial number (PCI capability
> > > RTE_PCI_EXT_CAP_ID_DSN).
> > >
> > > This results in a confusing ERROR log:
> > > ICE_INIT: ice_dev_init(): Failed to read device serial number
> > >
> > > This is confusing as DDP loading does *not* require the serial number to
> > > be present for the port to be functional afterwards.
> > >
> > > Besides, after trying various path, if the default DDP is not present on
> > > the runtime system, the port initialisation ends up with a vague error:
> > > ICE_INIT: ice_load_pkg(): failed to search file path
> > >
> > > Improve the situation with adjusting the log level when reading the
> > > SN fails, then add more debug context to DDP file loading and end up
> > > with a ERROR log mentioning the expected file.
> > >
> > > ICE_INIT: ice_firmware_read(): Cannot read DDP file
> > > /lib/firmware/updates/intel/ice/ddp/ice-b49691ffffe6e69c.pkg
> > > ICE_INIT: ice_firmware_read(): Cannot read DDP file
> > > /lib/firmware/intel/ice/ddp/ice-b49691ffffe6e69c.pkg
> > > ICE_INIT: ice_firmware_read(): Cannot read DDP file
> > > /lib/firmware/updates/intel/ice/ddp/ice.pkg
> > > ICE_INIT: ice_firmware_read(): Cannot read DDP file
> > > /lib/firmware/intel/ice/ddp/ice.pkg
> > > ICE_INIT: ice_load_pkg(): Failed to load default DDP package
> > > /lib/firmware/intel/ice/ddp/ice.pkg
> > >
> > > Signed-off-by: David Marchand <david.marchand@redhat.com>
> > > ---
> > > drivers/net/intel/ice/ice_ethdev.c | 31 ++++++++++++++++++++----------
> > > 1 file changed, 21 insertions(+), 10 deletions(-)
> > >
> > On top of the changes made in this patch, how about something like the
> > below to extend things?
> >
> > Rather than just debug logging the failed paths, we change the debug logs
> > to always log each load attempt. We also record the path as it's attempted,
> > and then on failure to load any path we use that record to print out an
> > error message for each failure, so the user can see in the error logs ALL
> > the failed paths, rather than having to re-run the app at debug level to
> > find them.
> >
> > WDYT?
>
> That's a lot of code for something that is usually detected right at
> the first installation/run of your DPDK application.
> When you are at this point, restarting testpmd with the right debug
> level is the usual way.
>
> But let's say you can't restart your application, log levels can be
> changed dynamically (possible with testpmd, grout and OVS)
> before/after trying to probe the E810 device.
>
Yes, true. Probably not worth the effort at this point.
/Bruce
^ permalink raw reply
* Re: [PATCH] net/ice: improve log messages for DDP loading
From: Bruce Richardson @ 2026-05-20 15:52 UTC (permalink / raw)
To: David Marchand; +Cc: dev, patrick.mahan, Anatoly Burakov
In-Reply-To: <20260516101942.443871-1-david.marchand@redhat.com>
On Sat, May 16, 2026 at 12:19:41PM +0200, David Marchand wrote:
> Some nics may not provide a serial number (PCI capability
> RTE_PCI_EXT_CAP_ID_DSN).
>
> This results in a confusing ERROR log:
> ICE_INIT: ice_dev_init(): Failed to read device serial number
>
> This is confusing as DDP loading does *not* require the serial number to
> be present for the port to be functional afterwards.
>
> Besides, after trying various path, if the default DDP is not present on
> the runtime system, the port initialisation ends up with a vague error:
> ICE_INIT: ice_load_pkg(): failed to search file path
>
> Improve the situation with adjusting the log level when reading the
> SN fails, then add more debug context to DDP file loading and end up
> with a ERROR log mentioning the expected file.
>
> ICE_INIT: ice_firmware_read(): Cannot read DDP file
> /lib/firmware/updates/intel/ice/ddp/ice-b49691ffffe6e69c.pkg
> ICE_INIT: ice_firmware_read(): Cannot read DDP file
> /lib/firmware/intel/ice/ddp/ice-b49691ffffe6e69c.pkg
> ICE_INIT: ice_firmware_read(): Cannot read DDP file
> /lib/firmware/updates/intel/ice/ddp/ice.pkg
> ICE_INIT: ice_firmware_read(): Cannot read DDP file
> /lib/firmware/intel/ice/ddp/ice.pkg
> ICE_INIT: ice_load_pkg(): Failed to load default DDP package
> /lib/firmware/intel/ice/ddp/ice.pkg
>
> Signed-off-by: David Marchand <david.marchand@redhat.com>
> ---
> drivers/net/intel/ice/ice_ethdev.c | 31 ++++++++++++++++++++----------
> 1 file changed, 21 insertions(+), 10 deletions(-)
>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
^ permalink raw reply
* Re: [RFC PATCH 0/8] remove use of rte_memcpy from net/intel
From: Stephen Hemminger @ 2026-05-20 16:45 UTC (permalink / raw)
To: Bruce Richardson; +Cc: dev
In-Reply-To: <ag1me_1XSByq3p9V@bricha3-mobl1.ger.corp.intel.com>
On Wed, 20 May 2026 08:44:59 +0100
Bruce Richardson <bruce.richardson@intel.com> wrote:
> On Tue, May 19, 2026 at 12:43:32PM -0700, Stephen Hemminger wrote:
> > On Tue, 19 May 2026 16:05:57 +0000
> > Bruce Richardson <bruce.richardson@intel.com> wrote:
> >
> > > This RFC proposed to replace all instances of rte_memcpy in Intel
> > > (and former-Intel) net drivers with just regular memcpy. This is
> > > done on the basis that the memcpy use is not datapath, but is used
> > > for flow configuration, virt-channel (to firmware or PF) messaging
> > > and other control path functions.
> >
> > Makes sense. You might also want to look for where structure
> > assignment can be used instead of memcpy. Keeping data types
> > is a good thing.
>
> Yes, it would be nice to use in places. However, it's not a mechanical
> change so I've not taken the time to do the analysis. Just a quick set of
> sed replacements for this RFC.
>
> /Bruce
There is a coccinelle script already to do this.
It is slow but does find things.
There doesn't seem to find any matches even after this patchset
^ permalink raw reply
* Re: [PATCH] linux/mem: atomically prefault hugepages in alloc_seg
From: Stephen Hemminger @ 2026-05-20 16:47 UTC (permalink / raw)
To: Michal Sieron; +Cc: dev
In-Reply-To: <20260520125756.530808-1-michal.sieron@nokia.com>
On Wed, 20 May 2026 14:57:56 +0200
Michal Sieron <michal.sieron@nokia.com> wrote:
> In rare cases, when a secondary process calls rte_eal_init() it can
> cause a data race during page prefaulting in alloc_seg().
>
> An atomic compare-exchange in a loop should eliminate the data race.
>
> Signed-off-by: Michal Sieron <michal.sieron@nokia.com>
> ---
Build fails. Fix and resubmit.
Looks like you did this against older version of DPDK before stdatomic.
FAILED: [code=1] lib/librte_eal.a.p/eal_linux_eal_memalloc.c.o
ccache clang -Ilib/librte_eal.a.p -Ilib -I../lib -Ilib/eal/common -I../lib/eal/common -I. -I.. -Iconfig -I../config -Ilib/eal/include -I../lib/eal/include -Ilib/eal/linux/include -I../lib/eal/linux/include -Ilib/eal/x86/include -I../lib/eal/x86/include -I../kernel/linux -Ilib/eal -I../lib/eal -Ilib/kvargs -I../lib/kvargs -Ilib/log -I../lib/log -Ilib/metrics -I../lib/metrics -Ilib/telemetry -I../lib/telemetry -Ilib/argparse -I../lib/argparse -Xclang -fcolor-diagnostics -fsanitize=undefined -pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wextra -Werror -std=c11 -include rte_config.h -Wvla -Wcast-qual -Wcomma -Wdeprecated -Wformat -Wformat-nonliteral -Wformat-security -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wold-style-definition -Wpointer-arith -Wshadow -Wsign-compare -Wstrict-prototypes -Wundef -Wwrite-strings -Wno-missing-field-initializers -D_GNU_SOURCE -fPIC -march=corei7 -mrtm -DALLOW_EXPERIMENTAL_API -DALLOW_INTERNAL_API '-DABI_VERSION="26.2"' -DRTE_EAL_PTHREAD_ATTR_SETAFFINITY_NP -DRTE_LOG_DEFAULT_LOGTYPE=lib.eal -DRTE_ANNOTATE_LOCKS -Wthread-safety -MD -MQ lib/librte_eal.a.p/eal_linux_eal_memalloc.c.o -MF lib/librte_eal.a.p/eal_linux_eal_memalloc.c.o.d -o lib/librte_eal.a.p/eal_linux_eal_memalloc.c.o -c ../lib/eal/linux/eal_memalloc.c
../lib/eal/linux/eal_memalloc.c:605:10: error: implicit declaration of function 'rte_atomic_compare_exchange_strong' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
while (!rte_atomic_compare_exchange_strong((volatile int *)addr, &snapshot, snapshot))
^
../lib/eal/linux/eal_memalloc.c:605:10: note: did you mean '__atomic_compare_exchange_n'?
../lib/eal/include/generic/rte_rwlock.h:189:6: note: '__atomic_compare_exchange_n' declared here
rte_atomic_compare_exchange_weak_explicit(&rwl->cnt, &x, x + RTE_RWLOCK_WRITE,
^
../lib/eal/include/rte_stdatomic.h:151:2: note: expanded from macro 'rte_atomic_compare_exchange_weak_explicit'
__atomic_compare_exchange_n(ptr, expected, desired, 1, \
^
1 error generated.
^ permalink raw reply
* Re: [PATCH] linux/mem: atomically prefault hugepages in alloc_seg
From: Stephen Hemminger @ 2026-05-20 17:07 UTC (permalink / raw)
To: Michal Sieron; +Cc: dev
In-Reply-To: <20260520125756.530808-1-michal.sieron@nokia.com>
On Wed, 20 May 2026 14:57:56 +0200
Michal Sieron <michal.sieron@nokia.com> wrote:
> In rare cases, when a secondary process calls rte_eal_init() it can
> cause a data race during page prefaulting in alloc_seg().
>
> An atomic compare-exchange in a loop should eliminate the data race.
>
> Signed-off-by: Michal Sieron <michal.sieron@nokia.com>
> ---
AI had good suggestion when reviewing this.
Your version is still racy (on the read side).
A simple non-racy, and no loop version would be:
rte_atomic_fetch_or_explicit((int *)addr, 0, rte_memory_order_relaxed);
^ permalink raw reply
* [PATCH] eal: fix data race in hugepage prefault
From: Stephen Hemminger @ 2026-05-20 17:08 UTC (permalink / raw)
To: dev
Cc: Stephen Hemminger, stable, Michal Sieron, Thomas Monjalon,
Anatoly Burakov, Bruce Richardson
In-Reply-To: <20260520125756.530808-1-michal.sieron@nokia.com>
The prefault step in alloc_seg() reads a value from the hugepage and
writes it back unchanged to force the kernel to commit the backing
page. The read and write were not atomic, which races with concurrent
access to the same physical page from a secondary process attaching
to the hugetlbfs-backed mapping during rte_eal_init().
Replace the non-atomic load+store with a single atomic fetch-or of
zero. This touches the page with an atomic read-modify-write without
changing its contents, eliminating the race while preserving the
original intent of forcing a write fault.
Fixes: 0f1631be24bd ("mem: fix page fault trigger")
Cc: stable@dpdk.org
Reported-by: Michal Sieron <michal.sieron@nokia.com>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
.mailmap | 1 +
lib/eal/linux/eal_memalloc.c | 7 ++++---
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/.mailmap b/.mailmap
index 4d26d9c286..07c49eb32f 100644
--- a/.mailmap
+++ b/.mailmap
@@ -1086,6 +1086,7 @@ Michal Mazurek <maz@semihalf.com>
Michal Michalik <michal.michalik@intel.com>
Michal Nowak <michal2.nowak@intel.com>
Michal Schmidt <mschmidt@redhat.com>
+Michal Sieron <michal.sieron@nokia.com>
Michal Swiatkowski <michal.swiatkowski@intel.com>
Michal Wilczynski <michal.wilczynski@intel.com>
Michał Mirosław <michal.miroslaw@atendesoftware.pl> <mirq-linux@rere.qmqm.pl>
diff --git a/lib/eal/linux/eal_memalloc.c b/lib/eal/linux/eal_memalloc.c
index a39bc31c7b..e73a0c11a6 100644
--- a/lib/eal/linux/eal_memalloc.c
+++ b/lib/eal/linux/eal_memalloc.c
@@ -25,6 +25,7 @@
#include <linux/falloc.h>
#include <linux/mman.h> /* for hugetlb-related mmap flags */
+#include <rte_atomic.h>
#include <rte_common.h>
#include <rte_log.h>
#include <rte_eal.h>
@@ -597,10 +598,10 @@ alloc_seg(struct rte_memseg *ms, void *addr, int socket_id,
/* we need to trigger a write to the page to enforce page fault and
* ensure that page is accessible to us, but we can't overwrite value
- * that is already there, so read the old value, and write itback.
- * kernel populates the page with zeroes initially.
+ * that is already there.
+ * Use an atomic OR with zero to touch the page without changing its contents.
*/
- *(volatile int *)addr = *(volatile int *)addr;
+ (void)rte_atomic_fetch_or_explicit((int *)addr, 0, rte_memory_order_relaxed);
iova = rte_mem_virt2iova(addr);
if (iova == RTE_BAD_PHYS_ADDR) {
--
2.53.0
^ 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