* [PATCH v4 09/20] net/txgbe: fix link flow control config for Sapphire
From: Zaiyu Wang @ 2026-05-11 10:35 UTC (permalink / raw)
To: dev; +Cc: Zaiyu Wang, stable, Jiawen Wu, Ferruh Yigit
In-Reply-To: <20260511103604.19724-1-zaiyuwang@trustnetic.com>
SP chips have a hardware bug preventing XON flow control support,
so the driver disables it.
Fixes: 69ce8c8a4ce3 ("net/txgbe: support flow control")
Cc: stable@dpdk.org
Signed-off-by: Zaiyu Wang <zaiyuwang@trustnetic.com>
---
drivers/net/txgbe/base/txgbe_hw.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/txgbe/base/txgbe_hw.c b/drivers/net/txgbe/base/txgbe_hw.c
index 0d3310e15c..b1a1483dab 100644
--- a/drivers/net/txgbe/base/txgbe_hw.c
+++ b/drivers/net/txgbe/base/txgbe_hw.c
@@ -1037,8 +1037,10 @@ s32 txgbe_fc_enable(struct txgbe_hw *hw)
for (i = 0; i < TXGBE_DCB_TC_MAX; i++) {
if ((hw->fc.current_mode & txgbe_fc_tx_pause) &&
hw->fc.high_water[i]) {
- fcrtl = TXGBE_FCWTRLO_TH(hw->fc.low_water[i]) |
- TXGBE_FCWTRLO_XON;
+ fcrtl = TXGBE_FCWTRLO_TH(hw->fc.low_water[i]);
+ /* SP doesn't support xon */
+ if (hw->mac.type == txgbe_mac_aml || hw->mac.type == txgbe_mac_aml40)
+ fcrtl |= TXGBE_FCWTRLO_XON;
fcrth = TXGBE_FCWTRHI_TH(hw->fc.high_water[i]) |
TXGBE_FCWTRHI_XOFF;
} else {
--
2.21.0.windows.1
^ permalink raw reply related
* [PATCH v4 08/20] net/txgbe: fix link flow control registers for Amber-Lite
From: Zaiyu Wang @ 2026-05-11 10:35 UTC (permalink / raw)
To: dev; +Cc: Zaiyu Wang, stable, Jiawen Wu
In-Reply-To: <20260511103604.19724-1-zaiyuwang@trustnetic.com>
The flow control counter registers on AML NICs differ from those on SP
NICs. Update the register offsets accordingly to ensure the counters
work correctly.
Fixes: fb6eb170dfa2 ("net/txgbe: add basic link configuration for Amber-Lite")
Cc: stable@dpdk.org
Signed-off-by: Zaiyu Wang <zaiyuwang@trustnetic.com>
---
drivers/net/txgbe/base/txgbe_hw.c | 7 ++++++
drivers/net/txgbe/base/txgbe_regs.h | 2 ++
drivers/net/txgbe/base/txgbe_type.h | 4 ++++
drivers/net/txgbe/txgbe_ethdev.c | 34 +++++++++++++++++++----------
4 files changed, 36 insertions(+), 11 deletions(-)
diff --git a/drivers/net/txgbe/base/txgbe_hw.c b/drivers/net/txgbe/base/txgbe_hw.c
index 0f3db3a1ad..0d3310e15c 100644
--- a/drivers/net/txgbe/base/txgbe_hw.c
+++ b/drivers/net/txgbe/base/txgbe_hw.c
@@ -394,6 +394,13 @@ s32 txgbe_clear_hw_cntrs(struct txgbe_hw *hw)
rd32(hw, TXGBE_PBTXLNKXON);
rd32(hw, TXGBE_PBTXLNKXOFF);
+ if (hw->mac.type == txgbe_mac_aml || hw->mac.type == txgbe_mac_aml40) {
+ wr32(hw, TXGBE_PBRXLNKXON_AML, 0);
+ wr32(hw, TXGBE_PBRXLNKXOFF_AML, 0);
+ hw->last_stats.rx_xon_packets = 0;
+ hw->last_stats.rx_xoff_packets = 0;
+ }
+
/* DMA Stats */
rd32(hw, TXGBE_DMARXPKT);
rd32(hw, TXGBE_DMATXPKT);
diff --git a/drivers/net/txgbe/base/txgbe_regs.h b/drivers/net/txgbe/base/txgbe_regs.h
index 060757323a..de382601c9 100644
--- a/drivers/net/txgbe/base/txgbe_regs.h
+++ b/drivers/net/txgbe/base/txgbe_regs.h
@@ -1085,6 +1085,8 @@ enum txgbe_5tuple_protocol {
#define TXGBE_PBRXDROP 0x019068
#define TXGBE_PBRXLNKXOFF 0x011988
#define TXGBE_PBRXLNKXON 0x011E0C
+#define TXGBE_PBRXLNKXOFF_AML 0x011F80
+#define TXGBE_PBRXLNKXON_AML 0x011F84
#define TXGBE_PBRXUPXON(up) (0x011E30 + (up) * 4)
#define TXGBE_PBRXUPXOFF(up) (0x011E10 + (up) * 4)
diff --git a/drivers/net/txgbe/base/txgbe_type.h b/drivers/net/txgbe/base/txgbe_type.h
index ede780321f..505f598fb7 100644
--- a/drivers/net/txgbe/base/txgbe_type.h
+++ b/drivers/net/txgbe/base/txgbe_type.h
@@ -876,6 +876,10 @@ struct txgbe_hw {
u64 tx_qp_bytes;
u64 rx_qp_mc_packets;
} qp_last[TXGBE_MAX_QP];
+ struct {
+ u64 rx_xon_packets;
+ u64 rx_xoff_packets;
+ } last_stats;
rte_spinlock_t phy_lock;
/*amlite: new SW-FW mbox */
diff --git a/drivers/net/txgbe/txgbe_ethdev.c b/drivers/net/txgbe/txgbe_ethdev.c
index 414107d7a7..3ae233f70a 100644
--- a/drivers/net/txgbe/txgbe_ethdev.c
+++ b/drivers/net/txgbe/txgbe_ethdev.c
@@ -2264,16 +2264,18 @@ txgbe_dev_reset(struct rte_eth_dev *dev)
return ret;
}
+#define TXGBE_UPDATE_COUNTER_32BIT_GENERIC(reg, last, count, reset) \
+ do { \
+ uint32_t current = rd32(hw, reg); \
+ if ((current) < (last)) \
+ current += 0x100000000ULL; \
+ if (reset) \
+ (last) = current; \
+ (count) = (uint32_t)((current) - (last)); \
+ } while (0)
+
#define UPDATE_QP_COUNTER_32bit(reg, last_counter, counter) \
- { \
- uint32_t current_counter = rd32(hw, reg); \
- if (current_counter < last_counter) \
- current_counter += 0x100000000LL; \
- if (!hw->offset_loaded) \
- last_counter = current_counter; \
- counter = current_counter - last_counter; \
- counter &= 0xFFFFFFFFLL; \
- }
+ TXGBE_UPDATE_COUNTER_32BIT_GENERIC(reg, last_counter, counter, !hw->offset_loaded)
#define UPDATE_QP_COUNTER_36bit(reg_lsb, reg_msb, last_counter, counter) \
{ \
@@ -2331,8 +2333,18 @@ txgbe_read_stats_registers(struct txgbe_hw *hw,
hw_stats->up[i].rx_up_dropped +=
rd32(hw, TXGBE_PBRXMISS(i));
}
- hw_stats->rx_xon_packets += rd32(hw, TXGBE_PBRXLNKXON);
- hw_stats->rx_xoff_packets += rd32(hw, TXGBE_PBRXLNKXOFF);
+
+ if (hw->mac.type == txgbe_mac_aml || hw->mac.type == txgbe_mac_aml40) {
+ TXGBE_UPDATE_COUNTER_32BIT_GENERIC(TXGBE_PBRXLNKXON_AML,
+ hw->last_stats.rx_xon_packets,
+ hw_stats->rx_xon_packets, !hw->offset_loaded);
+ TXGBE_UPDATE_COUNTER_32BIT_GENERIC(TXGBE_PBRXLNKXOFF_AML,
+ hw->last_stats.rx_xoff_packets,
+ hw_stats->rx_xoff_packets, !hw->offset_loaded);
+ } else {
+ hw_stats->rx_xon_packets += rd32(hw, TXGBE_PBRXLNKXON);
+ hw_stats->rx_xoff_packets += rd32(hw, TXGBE_PBRXLNKXOFF);
+ }
hw_stats->tx_xon_packets += rd32(hw, TXGBE_PBTXLNKXON);
hw_stats->tx_xoff_packets += rd32(hw, TXGBE_PBTXLNKXOFF);
--
2.21.0.windows.1
^ permalink raw reply related
* [PATCH v4 07/20] net/txgbe: fix Tx desc free logic
From: Zaiyu Wang @ 2026-05-11 10:35 UTC (permalink / raw)
To: dev; +Cc: Zaiyu Wang, stable, Jiawen Wu
In-Reply-To: <20260511103604.19724-1-zaiyuwang@trustnetic.com>
On some server environments, this driver caused TDM non-fatal errors
or PCIe request errors during Tx operation
In Amber-Lite NIC's Tx head write-back mode, the hardware periodically
writes back a head index pointing to the next descriptor it is adout
to process in Tx ring. All descriptors before the head are considered
processed by hardware and can be safely freed by the driver.
The root cause is that the driver can safely free a batch of descriptors
only when the hardware's write-back head pointer has advanced beyond all
descriptors in that batch, meaning they have all been processed by the
hardware. If the driver frees a descriptor before the hardware has
finished processing it, invalid memory access may occur, leading to the
observed bug.
To fix the issue, correct the boundary check in all three Tx cleanup
functions, each of which was missing the proper condition to prevent
freeing unprocessed descriptors.
Fixes: 8ada71d0bb7f ("net/txgbe: add Tx head write-back mode for Amber-Lite")
Cc: stable@dpdk.org
Signed-off-by: Zaiyu Wang <zaiyuwang@trustnetic.com>
---
drivers/net/txgbe/txgbe_rxtx.c | 9 ++++++++-
drivers/net/txgbe/txgbe_rxtx_vec_common.h | 7 +++++--
2 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/net/txgbe/txgbe_rxtx.c b/drivers/net/txgbe/txgbe_rxtx.c
index e2cd9b8841..72a4965693 100644
--- a/drivers/net/txgbe/txgbe_rxtx.c
+++ b/drivers/net/txgbe/txgbe_rxtx.c
@@ -100,7 +100,9 @@ txgbe_tx_free_bufs(struct txgbe_tx_queue *txq)
volatile uint16_t head = (uint16_t)*txq->headwb_mem;
- if (txq->tx_next_dd > head && head > tx_last_dd)
+ if (txq->tx_next_dd == head)
+ return 0;
+ else if (txq->tx_next_dd > head && head > tx_last_dd)
return 0;
else if (tx_last_dd > txq->tx_next_dd &&
(head > tx_last_dd || head < txq->tx_next_dd))
@@ -652,6 +654,11 @@ txgbe_xmit_cleanup(struct txgbe_tx_queue *txq)
/* we have caught up to head, no work left to do */
if (desc_to_clean_to == head)
return -(1);
+ else if (desc_to_clean_to > head && head > last_desc_cleaned)
+ return -(1);
+ else if (last_desc_cleaned > desc_to_clean_to &&
+ (head > last_desc_cleaned || head < desc_to_clean_to))
+ return -(1);
} else {
if (!(status & rte_cpu_to_le_32(TXGBE_TXD_DD))) {
PMD_TX_FREE_LOG(DEBUG,
diff --git a/drivers/net/txgbe/txgbe_rxtx_vec_common.h b/drivers/net/txgbe/txgbe_rxtx_vec_common.h
index 00847d087b..edf3586b77 100644
--- a/drivers/net/txgbe/txgbe_rxtx_vec_common.h
+++ b/drivers/net/txgbe/txgbe_rxtx_vec_common.h
@@ -94,8 +94,11 @@ txgbe_tx_free_bufs(struct txgbe_tx_queue *txq)
txq->tx_next_dd - txq->tx_free_thresh;
if (tx_last_dd >= txq->nb_tx_desc)
tx_last_dd -= txq->nb_tx_desc;
- volatile uint16_t head = (uint16_t)*txq->headwb_mem;
- if (txq->tx_next_dd > head && head > tx_last_dd)
+
+ volatile uint16_t head = (uint16_t)*txq->headwb_mem;
+ if (txq->tx_next_dd == head)
+ return 0;
+ else if (txq->tx_next_dd > head && head > tx_last_dd)
return 0;
else if (tx_last_dd > txq->tx_next_dd &&
(head > tx_last_dd || head < txq->tx_next_dd))
--
2.21.0.windows.1
^ permalink raw reply related
* [PATCH v4 06/20] net/txgbe: fix link status check condition
From: Zaiyu Wang @ 2026-05-11 10:35 UTC (permalink / raw)
To: dev; +Cc: Zaiyu Wang, stable, Jiawen Wu
In-Reply-To: <20260511103604.19724-1-zaiyuwang@trustnetic.com>
The original code incorrectly used 'if (link_up)' instead of
'if (*link_up)', causing the condition to always evaluate to true
because the pointer itself is non-NULL. This led to incorrect speed
assignment.
Fixes: fb6eb170dfa2 ("net/txgbe: add basic link configuration for Amber-Lite")
Cc: stable@dpdk.org
Signed-off-by: Zaiyu Wang <zaiyuwang@trustnetic.com>
---
drivers/net/txgbe/base/txgbe_aml.c | 2 +-
drivers/net/txgbe/base/txgbe_aml40.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/txgbe/base/txgbe_aml.c b/drivers/net/txgbe/base/txgbe_aml.c
index b376eca5b5..de9a1b1c93 100644
--- a/drivers/net/txgbe/base/txgbe_aml.c
+++ b/drivers/net/txgbe/base/txgbe_aml.c
@@ -67,7 +67,7 @@ s32 txgbe_check_mac_link_aml(struct txgbe_hw *hw, u32 *speed,
*link_up = false;
}
- if (link_up) {
+ if (*link_up) {
switch (links_reg & TXGBE_CFG_PORT_ST_AML_LINK_MASK) {
case TXGBE_CFG_PORT_ST_AML_LINK_25G:
*speed = TXGBE_LINK_SPEED_25GB_FULL;
diff --git a/drivers/net/txgbe/base/txgbe_aml40.c b/drivers/net/txgbe/base/txgbe_aml40.c
index 733bbac13a..eefd7119fd 100644
--- a/drivers/net/txgbe/base/txgbe_aml40.c
+++ b/drivers/net/txgbe/base/txgbe_aml40.c
@@ -68,7 +68,7 @@ s32 txgbe_check_mac_link_aml40(struct txgbe_hw *hw, u32 *speed,
*link_up = false;
}
- if (link_up) {
+ if (*link_up) {
if ((links_reg & TXGBE_CFG_PORT_ST_AML_LINK_40G) ==
TXGBE_CFG_PORT_ST_AML_LINK_40G)
*speed = TXGBE_LINK_SPEED_40GB_FULL;
--
2.21.0.windows.1
^ permalink raw reply related
* [PATCH v4 05/20] net/txgbe: fix inaccuracy in Tx rate limiting
From: Zaiyu Wang @ 2026-05-11 10:35 UTC (permalink / raw)
To: dev; +Cc: Zaiyu Wang, stable, Jiawen Wu
In-Reply-To: <20260511103604.19724-1-zaiyuwang@trustnetic.com>
Amber-lite NIC's TX rate limiting has large deviations for small
packets. To address this, the following changes are made:
1. Set TDM_RL_ADJ (0x1820c) to 21B (includes 7B Ethernet preamble,
1B SFD, 1B EFD, and 12B IPG).
2) Remove the rate offset in the driver (e.g., 105 / 100, a rough
compensation value from Linux kernel driver tests).
After these changes, accuracy deviation for 64B packets is within
~5%, while large packets show lower deviation.
Fixes: a309ab43acf3 ("net/txgbe: support Tx queue rate limiting for Amber-Lite")
Cc: stable@dpdk.org
Signed-off-by: Zaiyu Wang <zaiyuwang@trustnetic.com>
---
drivers/net/txgbe/base/txgbe_regs.h | 1 +
drivers/net/txgbe/txgbe_ethdev.c | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/txgbe/base/txgbe_regs.h b/drivers/net/txgbe/base/txgbe_regs.h
index 95c585a025..060757323a 100644
--- a/drivers/net/txgbe/base/txgbe_regs.h
+++ b/drivers/net/txgbe/base/txgbe_regs.h
@@ -1670,6 +1670,7 @@ enum txgbe_5tuple_protocol {
#define TXGBE_TDM_FACTOR_INT_SHIFT 16
#define TXGBE_TDM_FACTOR_FRA_SHIFT 2
+#define TXGBE_TDM_RL_ADJ 0x1820C
#define TXGBE_TDM_RL_VM_IDX 0x018218
#define TXGBE_TDM_RL_VM_CFG 0x01821C
#define TXGBE_TDM_RL_CFG 0x018400
diff --git a/drivers/net/txgbe/txgbe_ethdev.c b/drivers/net/txgbe/txgbe_ethdev.c
index 779874aac9..414107d7a7 100644
--- a/drivers/net/txgbe/txgbe_ethdev.c
+++ b/drivers/net/txgbe/txgbe_ethdev.c
@@ -4314,7 +4314,6 @@ txgbe_set_queue_rate_limit(struct rte_eth_dev *dev,
u16 frac;
link_speed = dev->data->dev_link.link_speed;
- tx_rate = tx_rate * 105 / 100;
/* Calculate the rate factor values to set */
factor_int = link_speed / tx_rate;
frac = (link_speed % tx_rate) * 10000 / tx_rate;
@@ -4324,6 +4323,7 @@ txgbe_set_queue_rate_limit(struct rte_eth_dev *dev,
factor_fra = 0;
}
+ wr32(hw, TXGBE_TDM_RL_ADJ, 21);
wr32(hw, TXGBE_TDM_RL_QUEUE_IDX, queue_idx);
wr32m(hw, TXGBE_TDM_RL_QUEUE_CFG,
TXGBE_TDM_FACTOR_INT_MASK, factor_int << TXGBE_TDM_FACTOR_INT_SHIFT);
--
2.21.0.windows.1
^ permalink raw reply related
* [PATCH v4 04/20] net/ngbe: fix VF promiscuous and allmulticast
From: Zaiyu Wang @ 2026-05-11 10:35 UTC (permalink / raw)
To: dev; +Cc: Zaiyu Wang, stable, Jiawen Wu
In-Reply-To: <20260511103604.19724-1-zaiyuwang@trustnetic.com>
The configuration of allmulti and promiscuous modes conflicts
together. For instance, if we enable promiscuous mode, then enable and
disable allmulti, then the promiscuous mode is wrongly disabled.
To resolve this, the following changes are made:
- do nothing when we set/unset allmulti if promiscuous mode is on
- restore the proper mode (none or allmulti) when we disable
promiscuous mode
Fixes: 7744e90805b5 ("net/ngbe: add promiscuous and allmulticast ops for VF device")
Cc: stable@dpdk.org
Signed-off-by: Zaiyu Wang <zaiyuwang@trustnetic.com>
---
drivers/net/ngbe/ngbe_ethdev_vf.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ngbe/ngbe_ethdev_vf.c b/drivers/net/ngbe/ngbe_ethdev_vf.c
index 6406df40d0..81511fed8a 100644
--- a/drivers/net/ngbe/ngbe_ethdev_vf.c
+++ b/drivers/net/ngbe/ngbe_ethdev_vf.c
@@ -1196,9 +1196,13 @@ static int
ngbevf_dev_promiscuous_disable(struct rte_eth_dev *dev)
{
struct ngbe_hw *hw = ngbe_dev_hw(dev);
+ int mode = NGBEVF_XCAST_MODE_NONE;
int ret;
- switch (hw->mac.update_xcast_mode(hw, NGBEVF_XCAST_MODE_NONE)) {
+ if (dev->data->all_multicast)
+ mode = NGBEVF_XCAST_MODE_ALLMULTI;
+
+ switch (hw->mac.update_xcast_mode(hw, mode)) {
case 0:
ret = 0;
break;
@@ -1219,7 +1223,7 @@ ngbevf_dev_allmulticast_enable(struct rte_eth_dev *dev)
struct ngbe_hw *hw = ngbe_dev_hw(dev);
int ret;
- if (dev->data->promiscuous == 1)
+ if (dev->data->promiscuous)
return 0;
switch (hw->mac.update_xcast_mode(hw, NGBEVF_XCAST_MODE_ALLMULTI)) {
@@ -1243,6 +1247,9 @@ ngbevf_dev_allmulticast_disable(struct rte_eth_dev *dev)
struct ngbe_hw *hw = ngbe_dev_hw(dev);
int ret;
+ if (dev->data->promiscuous)
+ return 0;
+
switch (hw->mac.update_xcast_mode(hw, NGBEVF_XCAST_MODE_MULTI)) {
case 0:
ret = 0;
--
2.21.0.windows.1
^ permalink raw reply related
* [PATCH v4 01/20] net/txgbe: remove duplicate xstats counters
From: Zaiyu Wang @ 2026-05-11 10:35 UTC (permalink / raw)
To: dev; +Cc: Zaiyu Wang, stable, Jiawen Wu, Ferruh Yigit
In-Reply-To: <20260511103604.19724-1-zaiyuwang@trustnetic.com>
Remove four redundant counters (tx_xon_packets, rx_xon_packets,
tx_xoff_packets and rx_xoff_packets) from xstats, as they were duplicates
of tx_flow_control_xon_packets and others. Both sets were reading the same
registers but being output twice under different names. After removing
these entries, the flow control counters in DPDK now align with those in
our Linux kernel driver.
Fixes: 91fe49c87d76 ("net/txgbe: support device xstats")
Cc: stable@dpdk.org
Signed-off-by: Zaiyu Wang <zaiyuwang@trustnetic.com>
---
drivers/net/txgbe/txgbe_ethdev.c | 5 -----
1 file changed, 5 deletions(-)
diff --git a/drivers/net/txgbe/txgbe_ethdev.c b/drivers/net/txgbe/txgbe_ethdev.c
index 5d360f8305..779874aac9 100644
--- a/drivers/net/txgbe/txgbe_ethdev.c
+++ b/drivers/net/txgbe/txgbe_ethdev.c
@@ -261,11 +261,6 @@ static const struct rte_txgbe_xstats_name_off rte_txgbe_stats_strings[] = {
HW_XSTAT(tx_size_1024_to_max_packets),
/* Flow Control */
- HW_XSTAT(tx_xon_packets),
- HW_XSTAT(rx_xon_packets),
- HW_XSTAT(tx_xoff_packets),
- HW_XSTAT(rx_xoff_packets),
-
HW_XSTAT_NAME(tx_xon_packets, "tx_flow_control_xon_packets"),
HW_XSTAT_NAME(rx_xon_packets, "rx_flow_control_xon_packets"),
HW_XSTAT_NAME(tx_xoff_packets, "tx_flow_control_xoff_packets"),
--
2.21.0.windows.1
^ permalink raw reply related
* [PATCH v4 03/20] net/ngbe: add missing CDR config for YT PHY
From: Zaiyu Wang @ 2026-05-11 10:35 UTC (permalink / raw)
To: dev; +Cc: Zaiyu Wang, stable, Jiawen Wu
In-Reply-To: <20260511103604.19724-1-zaiyuwang@trustnetic.com>
According to the PHY vendor, when YT8531S operates in UTP-to-Fiber or
RGMII-to-Fiber mode with auto-negotiation disabled (Force mode),
additional CDR (Clock Data Recovery) configuration is required to
improve link connectivity. Without this config, link may be unstable
or fail to establish.
Fixes: f1268369403d ("net/ngbe: support autoneg on/off for external PHY SFI mode")
Cc: stable@dpdk.org
Signed-off-by: Zaiyu Wang <zaiyuwang@trustnetic.com>
---
drivers/net/ngbe/base/ngbe_phy_yt.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/ngbe/base/ngbe_phy_yt.c b/drivers/net/ngbe/base/ngbe_phy_yt.c
index d110fbc8b2..ab0778d246 100644
--- a/drivers/net/ngbe/base/ngbe_phy_yt.c
+++ b/drivers/net/ngbe/base/ngbe_phy_yt.c
@@ -264,6 +264,9 @@ s32 ngbe_setup_phy_link_yt(struct ngbe_hw *hw, u32 speed,
value = YT_BCR_RESET | YT_BCR_ANE | YT_BCR_RESTART_AN |
YT_BCR_DUPLEX | YT_BCR_SPEED_SELECT1;
} else {
+ /* force mode need to config cdr */
+ ngbe_write_phy_reg_sds_ext_yt(hw, 0x3, 0, 0x1434);
+ ngbe_write_phy_reg_sds_ext_yt(hw, 0xe, 0, 0x163);
value = YT_BCR_RESET | YT_BCR_DUPLEX;
if (speed & NGBE_LINK_SPEED_1GB_FULL)
value |= YT_BCR_SPEED_SELECT1;
--
2.21.0.windows.1
^ permalink raw reply related
* [PATCH v4 02/20] net/ngbe: remove duplicate xstats counters
From: Zaiyu Wang @ 2026-05-11 10:35 UTC (permalink / raw)
To: dev; +Cc: Zaiyu Wang, stable, Jiawen Wu
In-Reply-To: <20260511103604.19724-1-zaiyuwang@trustnetic.com>
Remove four redundant counters (tx_xon_packets, rx_xon_packets,
tx_xoff_packets and rx_xoff_packets) from xstats, as they were duplicates
of tx_flow_control_xon_packets and others. Both sets were reading the same
registers but being output twice under different names. After removing
these entries, the flow control counters in DPDK now align with those in
our Linux kernel driver.
Fixes: 8b433d04adc9 ("net/ngbe: support device xstats")
Cc: stable@dpdk.org
Signed-off-by: Zaiyu Wang <zaiyuwang@trustnetic.com>
---
drivers/net/ngbe/ngbe_ethdev.c | 5 -----
1 file changed, 5 deletions(-)
diff --git a/drivers/net/ngbe/ngbe_ethdev.c b/drivers/net/ngbe/ngbe_ethdev.c
index 8b9d6371fb..6df53f3266 100644
--- a/drivers/net/ngbe/ngbe_ethdev.c
+++ b/drivers/net/ngbe/ngbe_ethdev.c
@@ -227,11 +227,6 @@ static const struct rte_ngbe_xstats_name_off rte_ngbe_stats_strings[] = {
HW_XSTAT(tx_size_1024_to_max_packets),
/* Flow Control */
- HW_XSTAT(tx_xon_packets),
- HW_XSTAT(rx_xon_packets),
- HW_XSTAT(tx_xoff_packets),
- HW_XSTAT(rx_xoff_packets),
-
HW_XSTAT_NAME(tx_xon_packets, "tx_flow_control_xon_packets"),
HW_XSTAT_NAME(rx_xon_packets, "rx_flow_control_xon_packets"),
HW_XSTAT_NAME(tx_xoff_packets, "tx_flow_control_xoff_packets"),
--
2.21.0.windows.1
^ permalink raw reply related
* [PATCH v4 00/20] Wangxun Fixes
From: Zaiyu Wang @ 2026-05-11 10:35 UTC (permalink / raw)
To: dev; +Cc: Zaiyu Wang
In-Reply-To: <20260423034024.14404-1-zaiyuwang@trustnetic.com>
This series fixes several issues found on Wangxun Emerald, Sapphire and
Amber-lite NICs, with a focus on link-related problems.
---
v4:
- Fixed issues identified by devtools scripts
---
v3:
- Addressed Stephen's comments
---
v2:
- Fixed compilation error and code style issues
---
Zaiyu Wang (20):
net/txgbe: remove duplicate xstats counters
net/ngbe: remove duplicate xstats counters
net/ngbe: add missing CDR config for YT PHY
net/ngbe: fix VF promiscuous and allmulticast
net/txgbe: fix inaccuracy in Tx rate limiting
net/txgbe: fix link status check condition
net/txgbe: fix Tx desc free logic
net/txgbe: fix link flow control registers for Amber-Lite
net/txgbe: fix link flow control config for Sapphire
net/txgbe: fix a mass of unknown interrupts
net/txgbe: fix traffic class priority configuration
net/txgbe: fix link stability for 25G NIC
net/txgbe: fix link stability for 40G NIC
net/txgbe: fix link stability for Amber-Lite backplane mode
net/txgbe: fix FEC mode configuration on 25G NIC
net/txgbe: fix SFP module identification
net/txgbe: fix get module info operation
net/txgbe: fix get EEPROM operation
net/txgbe: fix to reset Tx write-back pointer
net/txgbe: fix to enable Tx desc check
drivers/net/ngbe/base/ngbe_phy_yt.c | 3 +
drivers/net/ngbe/ngbe_ethdev.c | 5 -
drivers/net/ngbe/ngbe_ethdev_vf.c | 11 +-
drivers/net/txgbe/base/meson.build | 2 +
drivers/net/txgbe/base/txgbe.h | 2 +
drivers/net/txgbe/base/txgbe_aml.c | 187 +-
drivers/net/txgbe/base/txgbe_aml.h | 6 +-
drivers/net/txgbe/base/txgbe_aml40.c | 113 +-
drivers/net/txgbe/base/txgbe_aml40.h | 6 +-
drivers/net/txgbe/base/txgbe_dcb_hw.c | 2 +-
drivers/net/txgbe/base/txgbe_e56.c | 3778 +++++++++++++++++++++
drivers/net/txgbe/base/txgbe_e56.h | 1748 ++++++++++
drivers/net/txgbe/base/txgbe_e56_bp.c | 2597 ++++++++++++++
drivers/net/txgbe/base/txgbe_e56_bp.h | 282 ++
drivers/net/txgbe/base/txgbe_hw.c | 54 +-
drivers/net/txgbe/base/txgbe_hw.h | 4 +-
drivers/net/txgbe/base/txgbe_osdep.h | 4 +
drivers/net/txgbe/base/txgbe_phy.c | 360 +-
drivers/net/txgbe/base/txgbe_phy.h | 45 +-
drivers/net/txgbe/base/txgbe_regs.h | 11 +-
drivers/net/txgbe/base/txgbe_type.h | 43 +-
drivers/net/txgbe/txgbe_ethdev.c | 414 ++-
drivers/net/txgbe/txgbe_ethdev.h | 6 +-
drivers/net/txgbe/txgbe_rxtx.c | 102 +-
drivers/net/txgbe/txgbe_rxtx.h | 1 +
drivers/net/txgbe/txgbe_rxtx_vec_common.h | 14 +-
26 files changed, 9366 insertions(+), 434 deletions(-)
create mode 100644 drivers/net/txgbe/base/txgbe_e56.c
create mode 100644 drivers/net/txgbe/base/txgbe_e56.h
create mode 100644 drivers/net/txgbe/base/txgbe_e56_bp.c
create mode 100644 drivers/net/txgbe/base/txgbe_e56_bp.h
--
2.21.0.windows.1
^ permalink raw reply
* RE: [PATCH v3 00/20] Wangxun Fixes
From: Zaiyu Wang @ 2026-05-11 10:28 UTC (permalink / raw)
To: 'Stephen Hemminger'; +Cc: dev
In-Reply-To: <20260509100720.15b37bfb@phoenix.local>
> -----Original Message-----
> From: Stephen Hemminger <stephen@networkplumber.org>
> Sent: Sunday, May 10, 2026 1:07 AM
> To: Zaiyu Wang <zaiyuwang@trustnetic.com>; Zaiyu Wang
> <zaiyuwang@trustnetic.com>
> Cc: dev@dpdk.org; dev@dpdk.org
> Subject: Re: [PATCH v3 00/20] Wangxun Fixes
>
> On Sat, 9 May 2026 19:28:02 +0800
> Zaiyu Wang <zaiyuwang@trustnetic.com> wrote:
>
> > This series fixes several issues found on Wangxun Emerald, Sapphire
> > and Amber-lite NICs, with a focus on link-related problems.
> > ---
> > v3:
> > - Addressed Stephen's comments
> > ---
> > v2:
> > - Fixed compilation error and code style issues
> > ---
> >
> > Zaiyu Wang (20):
> > net/txgbe: remove duplicate xstats counters
> > net/ngbe: remove duplicate xstats counters
> > net/ngbe: add missing CDR config for YT PHY
> > net/ngbe: fix VF promiscuous and allmulticast
> > net/txgbe: fix inaccuracy in TX rate limiting
> > net/txgbe: fix link status check condition
> > net/txgbe: fix Tx desc free logic
> > net/txgbe: fix link flow control registers for Amber-Lite
> > net/txgbe: fix link flow control config for Sapphire
> > net/txgbe: fix a mass of unknown interrupts
> > net/txgbe: fix traffic class priority configuration
> > net/txgbe: fix link stability for 25G NIC
> > net/txgbe: fix link stability for 40G NIC
> > net/txgbe: fix link stability for Amber-Lite backplane mode
> > net/txgbe: fix FEC mode configuration on 25G NIC
> > net/txgbe: fix SFP module identification
> > net/txgbe: fix get module info operation
> > net/txgbe: fix get eeprom operation
> > net/txgbe: fix to reset Tx write-back pointer
> > net/txgbe: fix to enable Tx desc check
> >
> > drivers/net/ngbe/base/ngbe_phy_yt.c | 3 +
> > drivers/net/ngbe/ngbe_ethdev.c | 5 -
> > drivers/net/ngbe/ngbe_ethdev_vf.c | 11 +-
> > drivers/net/txgbe/base/meson.build | 2 +
> > drivers/net/txgbe/base/txgbe.h | 2 +
> > drivers/net/txgbe/base/txgbe_aml.c | 187 +-
> > drivers/net/txgbe/base/txgbe_aml.h | 6 +-
> > drivers/net/txgbe/base/txgbe_aml40.c | 113 +-
> > drivers/net/txgbe/base/txgbe_aml40.h | 6 +-
> > drivers/net/txgbe/base/txgbe_dcb_hw.c | 2 +-
> > drivers/net/txgbe/base/txgbe_e56.c | 3774
> +++++++++++++++++++++
> > drivers/net/txgbe/base/txgbe_e56.h | 1744 ++++++++++
> > drivers/net/txgbe/base/txgbe_e56_bp.c | 2593 ++++++++++++++
> > drivers/net/txgbe/base/txgbe_e56_bp.h | 278 ++
> > drivers/net/txgbe/base/txgbe_hw.c | 54 +-
> > drivers/net/txgbe/base/txgbe_hw.h | 4 +-
> > drivers/net/txgbe/base/txgbe_osdep.h | 4 +
> > drivers/net/txgbe/base/txgbe_phy.c | 360 +-
> > drivers/net/txgbe/base/txgbe_phy.h | 45 +-
> > drivers/net/txgbe/base/txgbe_regs.h | 11 +-
> > drivers/net/txgbe/base/txgbe_type.h | 43 +-
> > drivers/net/txgbe/txgbe_ethdev.c | 414 ++-
> > drivers/net/txgbe/txgbe_ethdev.h | 6 +-
> > drivers/net/txgbe/txgbe_rxtx.c | 102 +-
> > drivers/net/txgbe/txgbe_rxtx.h | 1 +
> > drivers/net/txgbe/txgbe_rxtx_vec_common.h | 14 +-
> > 26 files changed, 9350 insertions(+), 434 deletions(-) create mode
> > 100644 drivers/net/txgbe/base/txgbe_e56.c
> > create mode 100644 drivers/net/txgbe/base/txgbe_e56.h
> > create mode 100644 drivers/net/txgbe/base/txgbe_e56_bp.c
> > create mode 100644 drivers/net/txgbe/base/txgbe_e56_bp.h
> >
>
> New files missing SPDX headers must fix.
>
Hi Stephen,
Thanks for catching this. Apologies for the oversight.
I've now gone through the relevant devtools checks and an updated patch set
will be sent shortly.
^ permalink raw reply
* [PATCH 6/6] net/idpf: fix split queue AVX2 Tx burst and completion
From: Shaiq Wani @ 2026-05-11 9:09 UTC (permalink / raw)
To: dev, bruce.richardson; +Cc: aman.deep.singh
In-Reply-To: <20260511090935.2288837-1-shaiq.wani@intel.com>
Clamp burst size to tx_rs_thresh to prevent crossing completion
boundaries. Update tx_next_rs on ring wrap and after each burst
so that completion tracking in idpf_splitq_scan_cq_ring works
correctly. Fix sw_ring pointer to use base-plus-offset.
Fixes: 57560a92167a ("net/idpf: add AVX2 Tx path for split queue config")
Signed-off-by: Shaiq Wani <shaiq.wani@intel.com>
---
.../net/intel/idpf/idpf_common_rxtx_avx2.c | 24 ++++++++++++++-----
1 file changed, 18 insertions(+), 6 deletions(-)
diff --git a/drivers/net/intel/idpf/idpf_common_rxtx_avx2.c b/drivers/net/intel/idpf/idpf_common_rxtx_avx2.c
index 7c547b5f09..b6c4fdf20e 100644
--- a/drivers/net/intel/idpf/idpf_common_rxtx_avx2.c
+++ b/drivers/net/intel/idpf/idpf_common_rxtx_avx2.c
@@ -884,17 +884,21 @@ idpf_splitq_xmit_fixed_burst_vec_avx2(void *tx_queue, struct rte_mbuf **tx_pkts,
struct ci_tx_queue *txq = (struct ci_tx_queue *)tx_queue;
struct idpf_flex_tx_sched_desc *txdp;
struct ci_tx_entry_vec *txep;
- uint16_t n, nb_commit;
+ uint16_t n, nb_commit, tx_id;
uint64_t cmd_dtype = IDPF_TXD_FLEX_FLOW_CMD_EOP;
- uint16_t tx_id = txq->tx_tail;
- nb_commit = (uint16_t)RTE_MIN(txq->nb_tx_free, nb_pkts);
- nb_pkts = nb_commit;
+ /* cross rs_thresh boundary is not allowed */
+ nb_pkts = RTE_MIN(nb_pkts, txq->tx_rs_thresh);
+
+ nb_pkts = (uint16_t)RTE_MIN(txq->nb_tx_free, nb_pkts);
+ nb_commit = nb_pkts;
if (unlikely(nb_pkts == 0))
return 0;
- txdp = (struct idpf_flex_tx_sched_desc *)&txq->desc_ring[tx_id];
- txep = &txq->sw_ring_vec[tx_id];
+ tx_id = txq->tx_tail;
+ txdp = &txq->desc_ring[tx_id];
+ txep = (void *)txq->sw_ring;
+ txep += tx_id;
txq->nb_tx_free = (uint16_t)(txq->nb_tx_free - nb_pkts);
@@ -909,10 +913,14 @@ idpf_splitq_xmit_fixed_burst_vec_avx2(void *tx_queue, struct rte_mbuf **tx_pkts,
idpf_splitq_vtx1_avx2(txdp, *tx_pkts++, cmd_dtype);
nb_commit = (uint16_t)(nb_commit - n);
+
tx_id = 0;
+ txq->tx_next_rs = (uint16_t)(txq->tx_rs_thresh - 1);
+ /* avoid reach the end of ring */
txdp = &txq->desc_ring[tx_id];
txep = (void *)txq->sw_ring;
+ txep += tx_id;
}
ci_tx_backlog_entry_vec(txep, tx_pkts, nb_commit);
@@ -920,6 +928,10 @@ idpf_splitq_xmit_fixed_burst_vec_avx2(void *tx_queue, struct rte_mbuf **tx_pkts,
idpf_splitq_vtx_avx2(txdp, tx_pkts, nb_commit, cmd_dtype);
tx_id = (uint16_t)(tx_id + nb_commit);
+ if (tx_id > txq->tx_next_rs)
+ txq->tx_next_rs =
+ (uint16_t)(txq->tx_next_rs + txq->tx_rs_thresh);
+
txq->tx_tail = tx_id;
IDPF_PCI_REG_WRITE(txq->qtx_tail, txq->tx_tail);
--
2.34.1
^ permalink raw reply related
* [PATCH 5/6] net/idpf: fix split queue AVX2 Tx buffer size shift
From: Shaiq Wani @ 2026-05-11 9:09 UTC (permalink / raw)
To: dev, bruce.richardson; +Cc: aman.deep.singh
In-Reply-To: <20260511090935.2288837-1-shaiq.wani@intel.com>
The flex scheduled Tx descriptor (DTYPE 0x0C) used in split queue mode
places the buffer size at bits 48-63 of QW1, requiring a left-shift
of 48. The code incorrectly used IDPF_TXD_QW1_TX_BUF_SZ_S (34),
which is the shift for base Tx descriptors (DTYPE 0x0) used in single
queue mode.
This caused the data_len to be placed in the wrong bit position,
resulting in hardware reading an incorrect buffer size of zero.
Define IDPF_TXD_FLEX_QW1_TX_BUF_SZ_S (48) for the flex descriptor
layout and use it in both vtx1 and vtx_avx2, consistent with the
AVX512 split queue Tx path.
Fixes: 57560a92167a ("net/idpf: add AVX2 Tx path for split queue config")
Signed-off-by: Shaiq Wani <shaiq.wani@intel.com>
---
drivers/net/intel/idpf/idpf_common_rxtx_avx2.c | 12 +++++++-----
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/net/intel/idpf/idpf_common_rxtx_avx2.c b/drivers/net/intel/idpf/idpf_common_rxtx_avx2.c
index e66dcc7a14..7c547b5f09 100644
--- a/drivers/net/intel/idpf/idpf_common_rxtx_avx2.c
+++ b/drivers/net/intel/idpf/idpf_common_rxtx_avx2.c
@@ -819,6 +819,8 @@ idpf_splitq_scan_cq_ring(struct ci_tx_queue *cq)
cq->tx_tail = cq_qid;
}
+#define IDPF_TXD_FLEX_QW1_TX_BUF_SZ_S 48
+
static __rte_always_inline void
idpf_splitq_vtx1_avx2(struct idpf_flex_tx_sched_desc *txdp,
struct rte_mbuf *pkt, uint64_t flags)
@@ -826,7 +828,7 @@ idpf_splitq_vtx1_avx2(struct idpf_flex_tx_sched_desc *txdp,
uint64_t high_qw =
IDPF_TX_DESC_DTYPE_FLEX_FLOW_SCHE |
((uint64_t)flags) |
- ((uint64_t)pkt->data_len << IDPF_TXD_QW1_TX_BUF_SZ_S);
+ ((uint64_t)pkt->data_len << IDPF_TXD_FLEX_QW1_TX_BUF_SZ_S);
__m128i descriptor = _mm_set_epi64x(high_qw,
pkt->buf_iova + pkt->data_off);
@@ -848,13 +850,13 @@ idpf_splitq_vtx_avx2(struct idpf_flex_tx_sched_desc *txdp,
for (; nb_pkts >= IDPF_VPMD_DESCS_PER_LOOP; txdp += IDPF_VPMD_DESCS_PER_LOOP,
pkt += IDPF_VPMD_DESCS_PER_LOOP, nb_pkts -= IDPF_VPMD_DESCS_PER_LOOP) {
uint64_t hi_qw0 = hi_qw_tmpl |
- ((uint64_t)pkt[0]->data_len << IDPF_TXD_QW1_TX_BUF_SZ_S);
+ ((uint64_t)pkt[0]->data_len << IDPF_TXD_FLEX_QW1_TX_BUF_SZ_S);
uint64_t hi_qw1 = hi_qw_tmpl |
- ((uint64_t)pkt[1]->data_len << IDPF_TXD_QW1_TX_BUF_SZ_S);
+ ((uint64_t)pkt[1]->data_len << IDPF_TXD_FLEX_QW1_TX_BUF_SZ_S);
uint64_t hi_qw2 = hi_qw_tmpl |
- ((uint64_t)pkt[2]->data_len << IDPF_TXD_QW1_TX_BUF_SZ_S);
+ ((uint64_t)pkt[2]->data_len << IDPF_TXD_FLEX_QW1_TX_BUF_SZ_S);
uint64_t hi_qw3 = hi_qw_tmpl |
- ((uint64_t)pkt[3]->data_len << IDPF_TXD_QW1_TX_BUF_SZ_S);
+ ((uint64_t)pkt[3]->data_len << IDPF_TXD_FLEX_QW1_TX_BUF_SZ_S);
__m256i desc0_1 = _mm256_set_epi64x(hi_qw1,
pkt[1]->buf_iova + pkt[1]->data_off,
--
2.34.1
^ permalink raw reply related
* [PATCH 4/6] net/idpf: fix ptype insert position in split queue AVX2 Rx
From: Shaiq Wani @ 2026-05-11 9:09 UTC (permalink / raw)
To: dev, bruce.richardson; +Cc: aman.deep.singh
In-Reply-To: <20260511090935.2288837-1-shaiq.wani@intel.com>
The __m256i register mb10 holds rearm data for two mbufs: mbuf 0 in
the low 128-bit lane (dwords 0-3) and mbuf 1 in the high 128-bit
lane (dwords 4-7). The packet_type field sits at dword 0 within
each mbuf's rearm_data layout.
For mbuf 1 (high lane), the packet_type must be inserted at
_mm256_insert_epi32 index 4 (first dword of the high 128-bit lane).
Index 2 is the third dword of the low lane, which overwrites the
wrong mbuf's data. The same applies to mb32 for mbuf 3.
Fixes: 1f065f9d75ff ("net/idpf: add AVX2 Rx path for split queue config")
Signed-off-by: Shaiq Wani <shaiq.wani@intel.com>
---
drivers/net/intel/idpf/idpf_common_rxtx_avx2.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/intel/idpf/idpf_common_rxtx_avx2.c b/drivers/net/intel/idpf/idpf_common_rxtx_avx2.c
index d3a8e17778..e66dcc7a14 100644
--- a/drivers/net/intel/idpf/idpf_common_rxtx_avx2.c
+++ b/drivers/net/intel/idpf/idpf_common_rxtx_avx2.c
@@ -570,9 +570,9 @@ idpf_dp_splitq_recv_pkts_avx2(void *rxq, struct rte_mbuf **rx_pkts, uint16_t nb_
ptype2 = (uint16_t)_mm256_extract_epi16(pt32, 1);
ptype3 = (uint16_t)_mm256_extract_epi16(pt32, 9);
- mb10 = _mm256_insert_epi32(mb10, (int)ptype_tbl[ptype1], 2);
+ mb10 = _mm256_insert_epi32(mb10, (int)ptype_tbl[ptype1], 4);
mb10 = _mm256_insert_epi32(mb10, (int)ptype_tbl[ptype0], 0);
- mb32 = _mm256_insert_epi32(mb32, (int)ptype_tbl[ptype3], 2);
+ mb32 = _mm256_insert_epi32(mb32, (int)ptype_tbl[ptype3], 4);
mb32 = _mm256_insert_epi32(mb32, (int)ptype_tbl[ptype2], 0);
/* Build rearm data for each mbuf */
--
2.34.1
^ permalink raw reply related
* [PATCH 3/6] net/idpf: fix mbuf initializer source in split queue AVX2 Rx
From: Shaiq Wani @ 2026-05-11 9:09 UTC (permalink / raw)
To: dev, bruce.richardson; +Cc: aman.deep.singh
In-Reply-To: <20260511090935.2288837-1-shaiq.wani@intel.com>
In split queue mode the completion queue (rxq) does not own the mbuf
pool — the buffer queue (bufq2) does. The mbuf initializer encodes
the mempool pointer, refcount and other per-pool mbuf metadata that
is stamped into every received mbuf during rearm.
Using queue->mbuf initializer reads an uninitialised or zero value
from the completion queue, corrupting every mbuf rearm. Use
queue->bufq2->mbuf initializer to get the correct value from the
buffer queue that actually owns the mbufs.
Fixes: 1f065f9d75ff ("net/idpf: add AVX2 Rx path for split queue config")
Signed-off-by: Shaiq Wani <shaiq.wani@intel.com>
---
drivers/net/intel/idpf/idpf_common_rxtx_avx2.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/intel/idpf/idpf_common_rxtx_avx2.c b/drivers/net/intel/idpf/idpf_common_rxtx_avx2.c
index 28d4246134..d3a8e17778 100644
--- a/drivers/net/intel/idpf/idpf_common_rxtx_avx2.c
+++ b/drivers/net/intel/idpf/idpf_common_rxtx_avx2.c
@@ -491,7 +491,7 @@ idpf_dp_splitq_recv_pkts_avx2(void *rxq, struct rte_mbuf **rx_pkts, uint16_t nb_
struct rte_mbuf **sw_ring = &queue->bufq2->sw_ring[queue->rx_tail];
volatile union virtchnl2_rx_desc *rxdp =
(volatile union virtchnl2_rx_desc *)queue->rx_ring + queue->rx_tail;
- const __m256i mbuf_init = _mm256_set_epi64x(0, 0, 0, queue->mbuf_initializer);
+ const __m256i mbuf_init = _mm256_set_epi64x(0, 0, 0, queue->bufq2->mbuf_initializer);
uint64_t head_gen;
uint16_t received = 0;
int i;
--
2.34.1
^ permalink raw reply related
* [PATCH 2/6] net/idpf: fix DD bit byte offset in split queue AVX2 Rx
From: Shaiq Wani @ 2026-05-11 9:09 UTC (permalink / raw)
To: dev, bruce.richardson; +Cc: aman.deep.singh
In-Reply-To: <20260511090935.2288837-1-shaiq.wani@intel.com>
The split queue completion descriptor (virtchnl2_rx_flex_desc_adv_nic_3)
has two distinct status fields: status_err0_qw0 at byte offset 1 and
status_err0_qw1 at byte offset 8. The DD (descriptor done) bit lives
in status_err0_qw1 (byte 8), not status_err0_qw0 (byte 1).
Byte 1 (status_err0_qw0) bit 0 is the LPBK (loopback) indicator, so
reading DD from byte 1 checks the wrong field entirely.
Fix the _mm_extract_epi8 index from 1 to 8 so the code reads the DD
bit from its correct location in the writeback descriptor.
Fixes: 1f065f9d75ff ("net/idpf: add AVX2 Rx path for split queue config")
Signed-off-by: Shaiq Wani <shaiq.wani@intel.com>
---
drivers/net/intel/idpf/idpf_common_rxtx_avx2.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/net/intel/idpf/idpf_common_rxtx_avx2.c b/drivers/net/intel/idpf/idpf_common_rxtx_avx2.c
index cd10c27a30..28d4246134 100644
--- a/drivers/net/intel/idpf/idpf_common_rxtx_avx2.c
+++ b/drivers/net/intel/idpf/idpf_common_rxtx_avx2.c
@@ -587,11 +587,11 @@ idpf_dp_splitq_recv_pkts_avx2(void *rxq, struct rte_mbuf **rx_pkts, uint16_t nb_
_mm256_storeu_si256((__m256i *)&rx_pkts[i + 2]->rearm_data, rearm2);
_mm256_storeu_si256((__m256i *)&rx_pkts[i + 3]->rearm_data, rearm3);
- /* Extract DD and generation bits from the already-loaded descriptor data (d0-d3) */
- stat0 = (uint8_t)_mm_extract_epi8(d0, 1);
- stat1 = (uint8_t)_mm_extract_epi8(d1, 1);
- stat2 = (uint8_t)_mm_extract_epi8(d2, 1);
- stat3 = (uint8_t)_mm_extract_epi8(d3, 1);
+ /* Extract DD bit from status_err0_qw1 (byte 8 of descriptor) */
+ stat0 = (uint8_t)_mm_extract_epi8(d0, 8);
+ stat1 = (uint8_t)_mm_extract_epi8(d1, 8);
+ stat2 = (uint8_t)_mm_extract_epi8(d2, 8);
+ stat3 = (uint8_t)_mm_extract_epi8(d3, 8);
pktlen_gen0 = (uint16_t)_mm_extract_epi16(d0, 2);
pktlen_gen1 = (uint16_t)_mm_extract_epi16(d1, 2);
--
2.34.1
^ permalink raw reply related
* [PATCH 1/6] net/idpf: fix gen bit extraction in split queue AVX2 Rx
From: Shaiq Wani @ 2026-05-11 9:09 UTC (permalink / raw)
To: dev, bruce.richardson; +Cc: aman.deep.singh
In-Reply-To: <20260511090935.2288837-1-shaiq.wani@intel.com>
The generation bit in the pktlen_gen_bufq_id field of the split queue
completion descriptor (virtchnl2_rx_flex_desc_adv_nic_3) must be
extracted by masking first and then shifting, not the other way around.
With shift-then-mask, the mask is applied to already-shifted bits,
which can produce incorrect results when upper bits (packet length,
buffer queue ID) leak into the extracted value.
Change to mask-then-shift to correctly isolate the generation bit
before comparing it with the expected generation ID.
Fixes: 1f065f9d75ff ("net/idpf: add AVX2 Rx path for split queue config")
Signed-off-by: Shaiq Wani <shaiq.wani@intel.com>
---
.../net/intel/idpf/idpf_common_rxtx_avx2.c | 20 +++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/net/intel/idpf/idpf_common_rxtx_avx2.c b/drivers/net/intel/idpf/idpf_common_rxtx_avx2.c
index db7728afad..cd10c27a30 100644
--- a/drivers/net/intel/idpf/idpf_common_rxtx_avx2.c
+++ b/drivers/net/intel/idpf/idpf_common_rxtx_avx2.c
@@ -524,8 +524,8 @@ idpf_dp_splitq_recv_pkts_avx2(void *rxq, struct rte_mbuf **rx_pkts, uint16_t nb_
/* check if there is at least one packet available */
head_gen = rxdp->flex_adv_nic_3_wb.pktlen_gen_bufq_id;
- if (((head_gen >> VIRTCHNL2_RX_FLEX_DESC_ADV_GEN_S) &
- VIRTCHNL2_RX_FLEX_DESC_ADV_GEN_M) != queue->expected_gen_id)
+ if (((head_gen & VIRTCHNL2_RX_FLEX_DESC_ADV_GEN_M) >>
+ VIRTCHNL2_RX_FLEX_DESC_ADV_GEN_S) != queue->expected_gen_id)
return 0;
for (i = 0; i < nb_pkts;
@@ -599,17 +599,17 @@ idpf_dp_splitq_recv_pkts_avx2(void *rxq, struct rte_mbuf **rx_pkts, uint16_t nb_
pktlen_gen3 = (uint16_t)_mm_extract_epi16(d3, 2);
valid0 = (stat0 & 1) &&
- (((pktlen_gen0 >> VIRTCHNL2_RX_FLEX_DESC_ADV_GEN_S) &
- VIRTCHNL2_RX_FLEX_DESC_ADV_GEN_M) == queue->expected_gen_id);
+ (((pktlen_gen0 & VIRTCHNL2_RX_FLEX_DESC_ADV_GEN_M) >>
+ VIRTCHNL2_RX_FLEX_DESC_ADV_GEN_S) == queue->expected_gen_id);
valid1 = (stat1 & 1) &&
- (((pktlen_gen1 >> VIRTCHNL2_RX_FLEX_DESC_ADV_GEN_S) &
- VIRTCHNL2_RX_FLEX_DESC_ADV_GEN_M) == queue->expected_gen_id);
+ (((pktlen_gen1 & VIRTCHNL2_RX_FLEX_DESC_ADV_GEN_M) >>
+ VIRTCHNL2_RX_FLEX_DESC_ADV_GEN_S) == queue->expected_gen_id);
valid2 = (stat2 & 1) &&
- (((pktlen_gen2 >> VIRTCHNL2_RX_FLEX_DESC_ADV_GEN_S) &
- VIRTCHNL2_RX_FLEX_DESC_ADV_GEN_M) == queue->expected_gen_id);
+ (((pktlen_gen2 & VIRTCHNL2_RX_FLEX_DESC_ADV_GEN_M) >>
+ VIRTCHNL2_RX_FLEX_DESC_ADV_GEN_S) == queue->expected_gen_id);
valid3 = (stat3 & 1) &&
- (((pktlen_gen3 >> VIRTCHNL2_RX_FLEX_DESC_ADV_GEN_S) &
- VIRTCHNL2_RX_FLEX_DESC_ADV_GEN_M) == queue->expected_gen_id);
+ (((pktlen_gen3 & VIRTCHNL2_RX_FLEX_DESC_ADV_GEN_M) >>
+ VIRTCHNL2_RX_FLEX_DESC_ADV_GEN_S) == queue->expected_gen_id);
/* count valid descriptors (holes are impossible because
* descriptors are read in reverse order while the NIC
--
2.34.1
^ permalink raw reply related
* [PATCH 0/6] net/idpf: fix split queue AVX2 datapath
From: Shaiq Wani @ 2026-05-11 9:09 UTC (permalink / raw)
To: dev, bruce.richardson; +Cc: aman.deep.singh
Fix the split queue AVX2 vectorized path to correctly handle the
virtchnl2_rx_flex_desc_adv_nic_3 completion descriptor format and
the flex scheduled Tx descriptor encoding.
The split queue completion descriptor layout is significantly
different from the single queue path — the generation bit, DD bit,
and packet length occupy different positions than the base Rx
descriptor, and the buffer queue owns the mbuf pool rather than the
completion queue.
On Rx, four issues are fixed:
- Generation bit extraction order (mask-before-shift)
- DD bit byte offset (byte 8 not byte 1)
- mbuf initializer sourced from bufq2 instead of the completion queue
- Packet type inserted into the correct AVX2 lane
On Tx, two issues are fixed:
- Buffer size shift corrected from 34 to 48 for flex descriptors
- Burst clamped to tx_rs_thresh with proper tx_next_rs tracking
Shaiq Wani (6):
net/idpf: fix gen bit extraction in split queue AVX2 Rx
net/idpf: fix DD bit byte offset in split queue AVX2 Rx
net/idpf: fix mbuf initializer source in split queue AVX2 Rx
net/idpf: fix ptype insert position in split queue AVX2 Rx
net/idpf: fix split queue AVX2 Tx buffer size shift
net/idpf: fix split queue AVX2 Tx burst and completion
.../net/intel/idpf/idpf_common_rxtx_avx2.c | 72 +++++++++++--------
1 file changed, 43 insertions(+), 29 deletions(-)
--
2.34.1
^ permalink raw reply
* Re: [PATCH] raw/ifpga: target main tree not next-net-intel
From: Thomas Monjalon @ 2026-05-11 8:06 UTC (permalink / raw)
To: Richardson, Bruce; +Cc: dev@dpdk.org, Xu, Weihua (Altera Corp), Mcnamara, John
In-Reply-To: <CY5PR11MB63183599D36796F0202F45A2FC2D2@CY5PR11MB6318.namprd11.prod.outlook.com>
> From: Bruce Richardson <bruce.richardson@intel.com>
>
> The raw/ifpga driver does not belong in the next-net-intel tree because:
> a) it's not a "net" driver
> b) it's now maintained by Altera
>
> So remove the line in MAINTAINERS targeting patches for that driver at
> next-net-intel tree.
>
> Acked-by: John McNamara <john.mcnamara@intel.com>
Applied, thanks.
^ permalink raw reply
* Re: [RFC 0/3] fib: tbl8 reservation drift reproducer and proposed fix
From: Maxime Leroy @ 2026-05-11 7:29 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Vladimir Medvedkin, dev
In-Reply-To: <20260507120253.3eec853a@phoenix.local>
Hi Stephen,
On Thu, May 7, 2026 at 9:03 PM Stephen Hemminger
<stephen@networkplumber.org> wrote:
>
> On Thu, 7 May 2026 11:50:40 +0200
> Maxime Leroy <maxime@leroys.fr> wrote:
>
> > Asymmetric ADD/DEL sequences in FIB6 trie (a covering parent
> > removed between the ADD and DEL of a longer prefix) eventually
> > make ADD fail with -ENOSPC even when the tbl8 pool is empty.
> >
> > Patch 2/3 is a small reproducer.
> >
> > Root cause: rsvd_tbl8s is updated by depth_diff recomputed from
> > the current RIB, so increments at ADD and decrements at DEL do
> > not cancel when the RIB state changes in between. The counter
> > drifts and wraps to UINT32_MAX.
> >
> > The simplest fix I could find (1/3, 3/3) is to drop rsvd_tbl8s
> > and use the pool counters already maintained by alloc/free:
> > tbl8_pool_pos in trie, cur_tbl8s in dir24_8. The DQ reclaim
> > inside tbl8_alloc() is moved into the pre-check.
> >
> > I am not sure I understood the original intent of keeping
> > rsvd_tbl8s separate from the pool counters. In dir24_8 the two
> > mirror each other 1:1 and rsvd_tbl8s looks redundant; in trie,
> > depth_diff gives it a worst-case-reservation flavor but the
> > recomputation from the RIB is exactly what makes it drift. If
> > there was a deliberate reason, please point it out.
> >
> > Patch 3/3 is a no-op cleanup that aligns dir24_8 with the trie
> > pattern.
> >
> > Maxime Leroy (3):
> > fib6: fix tbl8 reservation drift in trie
> > test/fib6: add reproducer for tbl8 reservation drift
> > fib: drop redundant tbl8 reservation counter
> >
> > app/test/test_fib6.c | 83 ++++++++++++++++++++++++++++++++++++++++++++
> > lib/fib/dir24_8.c | 31 ++++++-----------
> > lib/fib/dir24_8.h | 1 -
> > lib/fib/trie.c | 23 ++++++------
> > lib/fib/trie.h | 3 +-
> > 5 files changed, 104 insertions(+), 37 deletions(-)
> >
>
> Used this a test case for multiple AI reviewers.
> Most reported false positives in various places.
> But the winner was Claude web (or desktop) with Opus 4.7 extended.
> It saw:
>
> Patch 3 - fib: drop redundant tbl8 reservation counter
> Warning: The commit message frames this as removing a "redundant" counter and claims "Behavior is unchanged for non-DQ modes," but dir24_8 has the same rsvd_tbl8s drift bug that patch 1/3 fixes for trie6 — this patch silently fixes it as well.
> Trace (no RCU, depth-1 mode):
> ADD /28 A (no /24 cover):
> - tmp == NULL, pre-check passes
> - install_to_fib allocates 1 tbl8 -> cur_tbl8s = 1
> - post-add hook: tmp == NULL -> rsvd_tbl8s++ = 1
> ADD /24 B covering A:
> - depth == 24, no rsvd_tbl8s update
> - tbl8 entries rewritten, no alloc/free
> - state: rsvd_tbl8s = 1, cur_tbl8s = 1
> DEL /28 A (with /24 cover B):
> - modify_fib installs B's nh over A's range
> - tbl8 becomes uniform -> tbl8_recycle() -> cur_tbl8s = 0
> - post-del check: tmp != NULL (B is the cover) -> rsvd_tbl8s NOT decremented
> - state: rsvd_tbl8s = 1, cur_tbl8s = 0 (diverged)
> DEL /24 B:
> - depth == 24, no rsvd_tbl8s update
> - final: rsvd_tbl8s = 1, cur_tbl8s = 0
> Each repetition leaks +1 into rsvd_tbl8s with no actual tbl8 in use. Over enough cycles, rsvd_tbl8s reaches number_tbl8s and the pre-check rejects valid /25-/32 ADDs even though the pool is empty. This is the same class of bug as the IPv6 case, just with smaller per-cycle drift.
> The patch should carry:
> Fixes: <commit that introduced rsvd_tbl8s in dir24_8>
> Cc: stable@dpdk.org
Thanks for the AI review. It makes senses. I will fix it for the V1.
^ permalink raw reply
* Re: [PATCH 18/20] app/test-dma-perf: remove unnecessary null check
From: fengchengwen @ 2026-05-11 1:16 UTC (permalink / raw)
To: Stephen Hemminger, dev; +Cc: Cheng Jiang
In-Reply-To: <20260508203607.1003036-19-stephen@networkplumber.org>
NACK
The srcs / dsts may be NULL if setup_memory_env() failed.
On 5/9/2026 4:33 AM, Stephen Hemminger wrote:
> Remove unnecessary if check before calling rte_pktmbuf_free_bulk.
>
> Generated by devtools/cocci/null_free.cocci
>
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> ---
> app/test-dma-perf/benchmark.c | 6 ++----
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/app/test-dma-perf/benchmark.c b/app/test-dma-perf/benchmark.c
> index c0ffc859bd..576c59faff 100644
> --- a/app/test-dma-perf/benchmark.c
> +++ b/app/test-dma-perf/benchmark.c
> @@ -690,10 +690,8 @@ teardown_memory_env(uint32_t nr_buf, struct rte_mbuf **srcs, struct rte_mbuf **d
> struct rte_dma_op **dma_ops)
> {
> /* free mbufs used in the test */
> - if (srcs != NULL)
> - rte_pktmbuf_free_bulk(srcs, nr_buf);
> - if (dsts != NULL)
> - rte_pktmbuf_free_bulk(dsts, nr_buf);
> + rte_pktmbuf_free_bulk(srcs, nr_buf);
> + rte_pktmbuf_free_bulk(dsts, nr_buf);
>
> /* free the points for the mbufs */
> rte_free(srcs);
^ permalink raw reply
* Re: [PATCH 0/3] power: some cleancode for cpufreq library
From: fengchengwen @ 2026-05-11 1:10 UTC (permalink / raw)
To: Huisong Li, anatoly.burakov, sivaprasad.tummala
Cc: dev, thomas, stephen, yangxingui, zhanjie9
In-Reply-To: <20260509084503.2917038-1-lihuisong@huawei.com>
Series-acked-by: Chengwen Feng <fengchengwen@huawei.com>
On 5/9/2026 4:45 PM, Huisong Li wrote:
> Move some common definition to common header file.
>
> Huisong Li (3):
> power: move power state structure to power cpufreq header
> power: unify decimal format macro for strtoul
> power: use common decimal macro definition
>
> drivers/power/acpi/acpi_cpufreq.c | 8 --------
> drivers/power/amd_pstate/amd_pstate_cpufreq.c | 9 ---------
> drivers/power/cppc/cppc_cpufreq.c | 9 ---------
> drivers/power/intel_pstate/intel_pstate_cpufreq.c | 8 --------
> lib/power/power_common.c | 1 -
> lib/power/power_common.h | 2 ++
> lib/power/power_cpufreq.h | 10 ++++++++++
> lib/power/rte_power_qos.c | 2 +-
> 8 files changed, 13 insertions(+), 36 deletions(-)
>
^ permalink raw reply
* Re: [PATCH v2] maintainers: update dts maintainer email
From: Thomas Monjalon @ 2026-05-10 21:21 UTC (permalink / raw)
To: Patrick Robb
Cc: luca.vizzarro, dev, dmarx, abailey, knimoji, lylavoie,
Morten Brørup
In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35F65817@smartserver.smartshare.dk>
27/04/2026 07:41, Morten Brørup:
> > From: Patrick Robb [mailto:patrickrobb1997@gmail.com]
> > Sent: Monday, 27 April 2026 02.47
> >
> > Patrick Robb will now make contributions to DTS
> > as an individual in his personal capcity. So,
> > updating his email in the MAINTAINERS file to
> > be his personal email.
> >
> > Signed-off-by: Patrick Robb <patrickrobb1997@gmail.com>
>
> Acked-by: Morten Brørup <mb@smartsharesystems.com>
Applied
^ permalink raw reply
* Re: [PATCH] maintainers: update RISC-V maintainer
From: Thomas Monjalon @ 2026-05-10 21:16 UTC (permalink / raw)
To: Stanislaw Kardach, sunyuechi; +Cc: dev
In-Reply-To: <7c10b2b5-71e9-4ef7-be7e-02da5bda7aaf@iscas.ac.cn>
02/04/2026 06:08, sunyuechi:
> On 4/2/26 3:24 AM, Stanislaw Kardach wrote:
> > Change the RISC-V maintainer to Sun Yuechi and remove myself as
> > I'm unable to properly perform maintainer duties due to time
> > constraints.
> >
> > Signed-off-by: Stanislaw Kardach <stanislaw.kardach@gmail.com>
> > ---
> > RISC-V
> > -M: Stanisław Kardach <stanislaw.kardach@gmail.com>
> > +M: Sun Yuechi <sunyuechi@iscas.ac.cn>
> Acked-by: Sun Yuechi <sunyuechi@iscas.ac.cn>
Applied, thanks.
^ permalink raw reply
* [PATCH] dts: fix topology capability comparison
From: Thomas Monjalon @ 2026-05-10 19:49 UTC (permalink / raw)
To: dev
Cc: stable, Luca Vizzarro, Patrick Robb, Dean Marx, Juraj Linkeš,
Jeremy Spewock
TopologyCapability.__gt__() was delegating to __lt__(),
which caused infinite recursion when "other" is not a TopologyCapability:
other.__lt__(self) returns NotImplemented,
Python retries with self.__gt__(other),
and the cycle repeats.
dts/framework/testbed_model/capability.py", line 579, in __gt__
return other < self
^^^^^^^^^^^^
RecursionError: maximum recursion depth exceeded
Similarly, __le__() was delegating to "not __gt__()",
which returns True for non-comparable types instead of False.
Fix both by checking is_comparable_with() first
and comparing topology_type directly, consistent with __lt__().
Fixes: 039256daa8bf ("dts: add topology capability")
Cc: stable@dpdk.org
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
---
dts/framework/testbed_model/capability.py | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/dts/framework/testbed_model/capability.py b/dts/framework/testbed_model/capability.py
index 960370fc72..96e1cd449f 100644
--- a/dts/framework/testbed_model/capability.py
+++ b/dts/framework/testbed_model/capability.py
@@ -574,7 +574,9 @@ def __gt__(self, other: Any) -> bool:
Returns:
:data:`True` if the instance's topology type is more complex than the compared object's.
"""
- return other < self
+ if not self.is_comparable_with(other):
+ return False
+ return self.topology_type > other.topology_type
def __le__(self, other: Any) -> bool:
"""Compare the :attr:`~TopologyCapability.topology_type`s.
@@ -586,7 +588,9 @@ def __le__(self, other: Any) -> bool:
:data:`True` if the instance's topology type is less complex or equal than
the compared object's.
"""
- return not self > other
+ if not self.is_comparable_with(other):
+ return False
+ return self.topology_type <= other.topology_type
def __hash__(self):
"""Each instance is identified by :attr:`topology_type`."""
--
2.54.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