[PATCH 0/3] net/hns3: bugfix for hns3

[PATCH 0/3] net/hns3: bugfix for hns3

[Dengdui Huang]

This patchset fixes some bugs.

Dengdui Huang (3):
  net/hns3: fix the hardware GRO function is abnormal
  net/hns3: fix can't use vector for Tx when not set fast free
  net/hns3: fix can't use vector for Rx when set VLAN filter

 drivers/net/hns3/hns3_rxtx.c     | 12 ++++++++++++
 drivers/net/hns3/hns3_rxtx_vec.c | 10 ++++++----
 2 files changed, 18 insertions(+), 4 deletions(-)

-- 
2.33.0

[PATCH 1/3] net/hns3: fix the hardware GRO function is abnormal

[Dengdui Huang]

Currently, the alignment requirements of the data address in mbuf is
64-byte on HIP08 platform. However, the GRO feature will be abnormal
in this case.

Many online applications already use 64-byte aligned. So a check is added
to avoid using the GRO function when 64-byte aligned is used.

Fixes: d14c995b775a ("net/hns3: check Rx DMA address alignmnent")
Cc: stable@dpdk.org

Signed-off-by: Dengdui Huang <huangdengdui@huawei.com>
---
 drivers/net/hns3/hns3_rxtx.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/drivers/net/hns3/hns3_rxtx.c b/drivers/net/hns3/hns3_rxtx.c
index bde46733b0..b7b9b9e3f2 100644
--- a/drivers/net/hns3/hns3_rxtx.c
+++ b/drivers/net/hns3/hns3_rxtx.c
@@ -281,6 +281,7 @@ hns3_free_all_queues(struct rte_eth_dev *dev)
 static int
 hns3_check_rx_dma_addr(struct hns3_hw *hw, uint64_t dma_addr)
 {
+	uint64_t rx_offload = hw->data->dev_conf.rxmode.offloads;
 	uint64_t rem;
 
 	rem = dma_addr & (hw->rx_dma_addr_align - 1);
@@ -289,6 +290,17 @@ hns3_check_rx_dma_addr(struct hns3_hw *hw, uint64_t dma_addr)
 			 "must be %u-byte aligned", hw->rx_dma_addr_align);
 		return -EINVAL;
 	}
+
+	/*
+	 * This check is for HIP08 network engine. The GRO function will be
+	 * abnormal when mbuf DMA address is 64-byte aligned.
+	 */
+	rem = dma_addr & (HNS3_RX_DMA_ADDR_ALIGN_128 - 1);
+	if ((rx_offload & RTE_ETH_RX_OFFLOAD_TCP_LRO) && rem > 0) {
+		hns3_err(hw, "Hardware GRO is not supported when mbuf DMA "
+			 "address is 64-byte aligned");
+		return -EINVAL;
+	}
 	return 0;
 }
 
-- 
2.33.0

[PATCH 2/3] net/hns3: fix can't use vector for Tx when not set fast free

[Dengdui Huang]

Currently, select Tx vector algorithm only when tx_offload is
RTE_ETH_TX_OFFLOAD_MBUF_FAST_FREE. Actually, this algorithm
already supported the case that tx_offload isn't fast free.

Fixes: e31f123db06b ("net/hns3: support NEON Tx")
Cc: stable@dpdk.org

Signed-off-by: Dengdui Huang <huangdengdui@huawei.com>
---
 drivers/net/hns3/hns3_rxtx_vec.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/net/hns3/hns3_rxtx_vec.c b/drivers/net/hns3/hns3_rxtx_vec.c
index bf37ce51b1..9fb66ea2de 100644
--- a/drivers/net/hns3/hns3_rxtx_vec.c
+++ b/drivers/net/hns3/hns3_rxtx_vec.c
@@ -16,11 +16,11 @@
 int
 hns3_tx_check_vec_support(struct rte_eth_dev *dev)
 {
-	struct rte_eth_txmode *txmode = &dev->data->dev_conf.txmode;
+	uint64_t tx_offloads = dev->data->dev_conf.txmode.offloads;
 	struct rte_eth_rxmode *rxmode = &dev->data->dev_conf.rxmode;
 
-	/* Only support RTE_ETH_TX_OFFLOAD_MBUF_FAST_FREE */
-	if (txmode->offloads != RTE_ETH_TX_OFFLOAD_MBUF_FAST_FREE)
+	/* Only support when Tx offloads is RTE_ETH_TX_OFFLOAD_MBUF_FAST_FREE or 0. */
+	if (tx_offloads != RTE_ETH_TX_OFFLOAD_MBUF_FAST_FREE && tx_offloads != 0)
 		return -ENOTSUP;
 
 	/*
-- 
2.33.0

[PATCH 3/3] net/hns3: fix can't use vector for Rx when set VLAN filter

[Dengdui Huang]

Currently, When RTE_ETH_RX_OFFLOAD_VLAN_FILTER offload is set,
driver wouldn't select Rx vector algorithm. Actually, this
algorithm support it, so open it.

Fixes: a3d4f4d291d7 ("net/hns3: support NEON Rx")
Cc: stable@dpdk.org

Signed-off-by: Dengdui Huang <huangdengdui@huawei.com>
---
 drivers/net/hns3/hns3_rxtx_vec.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/net/hns3/hns3_rxtx_vec.c b/drivers/net/hns3/hns3_rxtx_vec.c
index 9fb66ea2de..daadd7e19f 100644
--- a/drivers/net/hns3/hns3_rxtx_vec.c
+++ b/drivers/net/hns3/hns3_rxtx_vec.c
@@ -184,7 +184,9 @@ hns3_rx_check_vec_support(struct rte_eth_dev *dev)
 {
 	struct rte_eth_rxmode *rxmode = &dev->data->dev_conf.rxmode;
 	uint64_t offloads_mask = RTE_ETH_RX_OFFLOAD_TCP_LRO |
-				 RTE_ETH_RX_OFFLOAD_VLAN |
+				 RTE_ETH_RX_OFFLOAD_VLAN_STRIP |
+				 RTE_ETH_RX_OFFLOAD_VLAN_EXTEND |
+				 RTE_ETH_RX_OFFLOAD_QINQ_STRIP |
 				 RTE_ETH_RX_OFFLOAD_TIMESTAMP |
 				 RTE_ETH_RX_OFFLOAD_KEEP_CRC;
 
-- 
2.33.0

Re: [PATCH 3/3] net/hns3: fix can't use vector for Rx when set VLAN filter

[Stephen Hemminger]

On Mon, 9 Jun 2025 21:06:51 +0800
Dengdui Huang <huangdengdui@huawei.com> wrote:

> Currently, When RTE_ETH_RX_OFFLOAD_VLAN_FILTER offload is set,
> driver wouldn't select Rx vector algorithm. Actually, this
> algorithm support it, so open it.
> 
> Fixes: a3d4f4d291d7 ("net/hns3: support NEON Rx")
> Cc: stable@dpdk.org
> 
> Signed-off-by: Dengdui Huang <huangdengdui@huawei.com>

Mind if I reword commit message slightly.
Use past tense for case before the patch was applied (old)
and present for case when patch is applied.

When the RTE_ETH_RX_OFFLOAD_VLAN_FILTER offload flag was set,
the driver would not select the Rx vector algorithm.
But this flag is OK when using vector algorithm so remove
it from the mask.

Re: [PATCH 1/3] net/hns3: fix the hardware GRO function is abnormal

[Stephen Hemminger]

On Mon, 9 Jun 2025 21:06:49 +0800
Dengdui Huang <huangdengdui@huawei.com> wrote:

> +	rem = dma_addr & (HNS3_RX_DMA_ADDR_ALIGN_128 - 1);
> +	if ((rx_offload & RTE_ETH_RX_OFFLOAD_TCP_LRO) && rem > 0) {
> +		hns3_err(hw, "Hardware GRO is not supported when mbuf DMA "
> +			 "address is 64-byte aligned");
> +		return -EINVAL;

Best to not break messages across source lines, it makes it harder for users
and tools looking for error messages in the source.

I.e do:
		hns3_err(hw, 
			 "Hardware GRO is not supported for if mbuf DMA not 64-byte aligned");
			 "
I can fix during merge if that is ok? or you can resubmit