* [PATCH 1/3] net/hns3: fix the hardware GRO function is abnormal
2025-06-09 13:06 [PATCH 0/3] net/hns3: bugfix for hns3 Dengdui Huang
@ 2025-06-09 13:06 ` Dengdui Huang
2025-06-09 17:13 ` Stephen Hemminger
2025-06-09 13:06 ` [PATCH 2/3] net/hns3: fix can't use vector for Tx when not set fast free Dengdui Huang
2025-06-09 13:06 ` [PATCH 3/3] net/hns3: fix can't use vector for Rx when set VLAN filter Dengdui Huang
2 siblings, 1 reply; 8+ messages in thread
From: Dengdui Huang @ 2025-06-09 13:06 UTC (permalink / raw)
To: dev; +Cc: stephen, lihuisong, fengchengwen, liuyonglong
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 1/3] net/hns3: fix the hardware GRO function is abnormal
2025-06-09 13:06 ` [PATCH 1/3] net/hns3: fix the hardware GRO function is abnormal Dengdui Huang
@ 2025-06-09 17:13 ` Stephen Hemminger
2025-06-10 1:27 ` huangdengdui
0 siblings, 1 reply; 8+ messages in thread
From: Stephen Hemminger @ 2025-06-09 17:13 UTC (permalink / raw)
To: Dengdui Huang; +Cc: dev, lihuisong, fengchengwen, liuyonglong
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 1/3] net/hns3: fix the hardware GRO function is abnormal
2025-06-09 17:13 ` Stephen Hemminger
@ 2025-06-10 1:27 ` huangdengdui
0 siblings, 0 replies; 8+ messages in thread
From: huangdengdui @ 2025-06-10 1:27 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: dev, lihuisong, fengchengwen, liuyonglong
On 2025/6/10 1:13, Stephen Hemminger wrote:
> 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
I made a mistake, can you help me fix it when merging?
Thanks
^ permalink raw reply [flat|nested] 8+ messages in thread
* [PATCH 2/3] net/hns3: fix can't use vector for Tx when not set fast free
2025-06-09 13:06 [PATCH 0/3] net/hns3: bugfix for hns3 Dengdui Huang
2025-06-09 13:06 ` [PATCH 1/3] net/hns3: fix the hardware GRO function is abnormal Dengdui Huang
@ 2025-06-09 13:06 ` Dengdui Huang
2025-06-09 13:06 ` [PATCH 3/3] net/hns3: fix can't use vector for Rx when set VLAN filter Dengdui Huang
2 siblings, 0 replies; 8+ messages in thread
From: Dengdui Huang @ 2025-06-09 13:06 UTC (permalink / raw)
To: dev; +Cc: stephen, lihuisong, fengchengwen, liuyonglong
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* [PATCH 3/3] net/hns3: fix can't use vector for Rx when set VLAN filter
2025-06-09 13:06 [PATCH 0/3] net/hns3: bugfix for hns3 Dengdui Huang
2025-06-09 13:06 ` [PATCH 1/3] net/hns3: fix the hardware GRO function is abnormal Dengdui Huang
2025-06-09 13:06 ` [PATCH 2/3] net/hns3: fix can't use vector for Tx when not set fast free Dengdui Huang
@ 2025-06-09 13:06 ` Dengdui Huang
2025-06-09 17:12 ` Stephen Hemminger
2 siblings, 1 reply; 8+ messages in thread
From: Dengdui Huang @ 2025-06-09 13:06 UTC (permalink / raw)
To: dev; +Cc: stephen, lihuisong, fengchengwen, liuyonglong
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 3/3] net/hns3: fix can't use vector for Rx when set VLAN filter
2025-06-09 13:06 ` [PATCH 3/3] net/hns3: fix can't use vector for Rx when set VLAN filter Dengdui Huang
@ 2025-06-09 17:12 ` Stephen Hemminger
2025-06-10 1:19 ` huangdengdui
0 siblings, 1 reply; 8+ messages in thread
From: Stephen Hemminger @ 2025-06-09 17:12 UTC (permalink / raw)
To: Dengdui Huang; +Cc: dev, lihuisong, fengchengwen, liuyonglong
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 3/3] net/hns3: fix can't use vector for Rx when set VLAN filter
2025-06-09 17:12 ` Stephen Hemminger
@ 2025-06-10 1:19 ` huangdengdui
0 siblings, 0 replies; 8+ messages in thread
From: huangdengdui @ 2025-06-10 1:19 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: dev, lihuisong, fengchengwen, liuyonglong
On 2025/6/10 1:12, Stephen Hemminger wrote:
> 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.
>
>
Okay, I don't mind. This new description is easier to understand.
^ permalink raw reply [flat|nested] 8+ messages in thread