[dpdk-dev] [PATCH 0/6] bugfixes for hns3

[dpdk-dev] [PATCH 0/6] bugfixes for hns3

[Min Hu (Connor)]

This series added six bugfix patches.

Chengchang Tang (3):
  net/hns3: fix TCP SEG and TCP CKSUM flag set
  net/hns3: fix Tx checksum for UDP packets with special port
  net/hns3: fix the long taskqueue pairs reset time

Huisong Li (3):
  net/hns3: fix the reporting of undefined speed
  net/hns3: fix compiling error for using SVE algorithm
  net/hns3: fix link update when failed to get link info

 drivers/net/hns3/hns3_cmd.h          |   8 +-
 drivers/net/hns3/hns3_ethdev.c       |  58 ++++++++---
 drivers/net/hns3/hns3_ethdev.h       |  19 ++++
 drivers/net/hns3/hns3_ethdev_vf.c    |   5 +-
 drivers/net/hns3/hns3_rxtx.c         | 194 +++++++++++++++++++++++++++++++----
 drivers/net/hns3/hns3_rxtx.h         |  16 +++
 drivers/net/hns3/hns3_rxtx_vec_sve.c |   2 +-
 7 files changed, 265 insertions(+), 37 deletions(-)

-- 
2.7.4

[dpdk-dev] [PATCH 1/6] net/hns3: fix the reporting of undefined speed

[Min Hu (Connor)]

From: Huisong Li <lihuisong@huawei.com>

There may be a case in future that the speed obtained from firmware
is undefined(such as, 400G or other rate), and link status of device is
up. At this case, PMD driver will reports 100Mbps to the user in the
"hns3_dev_link_update" API, which is unreasonable. Besides, if the
speed from firmware is zero, driver should report zero instead of
100Mbps.

Fixes: 59fad0f32135 ("net/hns3: support link update operation")
Cc: stable@dpdk.org

Signed-off-by: Huisong Li <lihuisong@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
---
 drivers/net/hns3/hns3_ethdev.c    | 5 ++++-
 drivers/net/hns3/hns3_ethdev_vf.c | 5 ++++-
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/net/hns3/hns3_ethdev.c b/drivers/net/hns3/hns3_ethdev.c
index fba715b..410b241 100644
--- a/drivers/net/hns3/hns3_ethdev.c
+++ b/drivers/net/hns3/hns3_ethdev.c
@@ -2725,7 +2725,10 @@ hns3_dev_link_update(struct rte_eth_dev *eth_dev,
 		new_link.link_speed = mac->link_speed;
 		break;
 	default:
-		new_link.link_speed = ETH_SPEED_NUM_100M;
+		if (mac->link_status)
+			new_link.link_speed = ETH_SPEED_NUM_UNKNOWN;
+		else
+			new_link.link_speed = ETH_SPEED_NUM_NONE;
 		break;
 	}
 
diff --git a/drivers/net/hns3/hns3_ethdev_vf.c b/drivers/net/hns3/hns3_ethdev_vf.c
index b121d7f..6e579b5 100644
--- a/drivers/net/hns3/hns3_ethdev_vf.c
+++ b/drivers/net/hns3/hns3_ethdev_vf.c
@@ -2125,7 +2125,10 @@ hns3vf_dev_link_update(struct rte_eth_dev *eth_dev,
 		new_link.link_speed = mac->link_speed;
 		break;
 	default:
-		new_link.link_speed = ETH_SPEED_NUM_100M;
+		if (mac->link_status)
+			new_link.link_speed = ETH_SPEED_NUM_UNKNOWN;
+		else
+			new_link.link_speed = ETH_SPEED_NUM_NONE;
 		break;
 	}
 
-- 
2.7.4

[dpdk-dev] [PATCH 2/6] net/hns3: fix compiling error for using SVE algorithm

[Min Hu (Connor)]

From: Huisong Li <lihuisong@huawei.com>

The 'queue_full_cnt' stats have been encapsulated in 'dfx_stats'.
However, the modification in the SVE algorithm is omitted.
As a result, the driver fails to be compiled when the SVE
algorithm is used.

Fixes: 9b77f1fe303f ("net/hns3: encapsulate DFX stats in datapath")

Signed-off-by: Huisong Li <lihuisong@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
---
 drivers/net/hns3/hns3_rxtx_vec_sve.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/hns3/hns3_rxtx_vec_sve.c b/drivers/net/hns3/hns3_rxtx_vec_sve.c
index f8655fa..e1a1731 100644
--- a/drivers/net/hns3/hns3_rxtx_vec_sve.c
+++ b/drivers/net/hns3/hns3_rxtx_vec_sve.c
@@ -439,7 +439,7 @@ hns3_xmit_fixed_burst_vec_sve(void *__restrict tx_queue,
 
 	nb_pkts = RTE_MIN(txq->tx_bd_ready, nb_pkts);
 	if (unlikely(nb_pkts == 0)) {
-		txq->queue_full_cnt++;
+		txq->dfx_stats.queue_full_cnt++;
 		return 0;
 	}
 
-- 
2.7.4

[dpdk-dev] [PATCH 3/6] net/hns3: fix TCP SEG and TCP CKSUM flag set

[Min Hu (Connor)]

From: Chengchang Tang <tangchengchang@huawei.com>

Currently, if the PKT_TX_TCP_SEG and PKT_TX_TCP_CKSUM set in the same time,
hns3 PMD can not process the descriptors correctly.

This patch fix it by adding the processing of this situation.

Fixes: fb6eb9009f41 ("net/hns3: fix Tx checksum with fixed header length")
Cc: stable@dpdk.org

Signed-off-by: Chengchang Tang <tangchengchang@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
---
 drivers/net/hns3/hns3_rxtx.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/hns3/hns3_rxtx.c b/drivers/net/hns3/hns3_rxtx.c
index ba30086..a76dfa5 100644
--- a/drivers/net/hns3/hns3_rxtx.c
+++ b/drivers/net/hns3/hns3_rxtx.c
@@ -3372,6 +3372,7 @@ hns3_parse_l4_cksum_params(struct rte_mbuf *m, uint32_t *type_cs_vlan_tso_len)
 	uint32_t tmp;
 	/* Enable L4 checksum offloads */
 	switch (ol_flags & (PKT_TX_L4_MASK | PKT_TX_TCP_SEG)) {
+	case PKT_TX_TCP_CKSUM | PKT_TX_TCP_SEG:
 	case PKT_TX_TCP_CKSUM:
 	case PKT_TX_TCP_SEG:
 		tmp = *type_cs_vlan_tso_len;
-- 
2.7.4

[dpdk-dev] [PATCH 4/6] net/hns3: fix Tx checksum for UDP packets with special port

[Min Hu (Connor)]

From: Chengchang Tang <tangchengchang@huawei.com>

For Kunpeng920 network engine, UDP packets with destination port 6081,
4789 or 4790 will be identified as tunnel packets. If the UDP CKSUM
offload is set in the mbuf, and the TX tunnel mask is not set, the
CKSUM of these packets will be wrong. In this case, the upper layer
user may not identify the packet as a tunnel packet, and processes it
as non-tunnel packet, and expect to offload the outer UDP CKSUM, so
they may not fill the outer L2/L3 length to mbuf. However, the HW
identifies these packet as tunnel packets and therefore offload the
inner UDP CKSUM. As a result, the inner and outer UDP CKSUM are
incorrect. And for non-tunnel UDP packets with preceding special
destination port will also exist similar checksum error.

For the new generation Kunpeng930 network engine, the above errata
have been fixed. Therefore, the concept of udp_cksum_mode is
introduced. There are two udp_cksum_mode for hns3 PMD,
HNS3_SPECIAL_PORT_HW_CKSUM_MODE means HW could solve the above
problem. And in HNS3_SPECIAL_PORT_SW_CKSUM_MODE, hns3 PMD will check
packets in the Tx prepare and perform the UDP CKSUM for such packets
to avoid a checksum error.

Fixes: bba636698316 ("net/hns3: support Rx/Tx and related operations")
Cc: stable@dpdk.org

Signed-off-by: Chengchang Tang <tangchengchang@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
---
 drivers/net/hns3/hns3_ethdev.c |  2 ++
 drivers/net/hns3/hns3_ethdev.h | 19 ++++++++++++
 drivers/net/hns3/hns3_rxtx.c   | 68 ++++++++++++++++++++++++++++++++++++++++++
 drivers/net/hns3/hns3_rxtx.h   | 16 ++++++++++
 4 files changed, 105 insertions(+)

diff --git a/drivers/net/hns3/hns3_ethdev.c b/drivers/net/hns3/hns3_ethdev.c
index 410b241..c318350 100644
--- a/drivers/net/hns3/hns3_ethdev.c
+++ b/drivers/net/hns3/hns3_ethdev.c
@@ -3129,6 +3129,7 @@ hns3_get_capability(struct hns3_hw *hw)
 		hw->min_tx_pkt_len = HNS3_HIP08_MIN_TX_PKT_LEN;
 		pf->tqp_config_mode = HNS3_FIXED_MAX_TQP_NUM_MODE;
 		hw->rss_info.ipv6_sctp_offload_supported = false;
+		hw->udp_cksum_mode = HNS3_SPECIAL_PORT_SW_CKSUM_MODE;
 		return 0;
 	}
 
@@ -3148,6 +3149,7 @@ hns3_get_capability(struct hns3_hw *hw)
 	hw->min_tx_pkt_len = HNS3_HIP09_MIN_TX_PKT_LEN;
 	pf->tqp_config_mode = HNS3_FLEX_MAX_TQP_NUM_MODE;
 	hw->rss_info.ipv6_sctp_offload_supported = true;
+	hw->udp_cksum_mode = HNS3_SPECIAL_PORT_HW_CKSUM_MODE;
 
 	return 0;
 }
diff --git a/drivers/net/hns3/hns3_ethdev.h b/drivers/net/hns3/hns3_ethdev.h
index 586979b..d35ca98 100644
--- a/drivers/net/hns3/hns3_ethdev.h
+++ b/drivers/net/hns3/hns3_ethdev.h
@@ -47,6 +47,9 @@
 #define HNS3_UNLIMIT_PROMISC_MODE       0
 #define HNS3_LIMIT_PROMISC_MODE         1
 
+#define HNS3_SPECIAL_PORT_SW_CKSUM_MODE         0
+#define HNS3_SPECIAL_PORT_HW_CKSUM_MODE         1
+
 #define HNS3_UC_MACADDR_NUM		128
 #define HNS3_VF_UC_MACADDR_NUM		48
 #define HNS3_MC_MACADDR_NUM		128
@@ -567,6 +570,22 @@ struct hns3_hw {
 	uint8_t drop_stats_mode;
 
 	uint8_t max_non_tso_bd_num; /* max BD number of one non-TSO packet */
+	/*
+	 * udp checksum mode.
+	 * value range:
+	 *      HNS3_SPECIAL_PORT_HW_CKSUM_MODE/HNS3_SPECIAL_PORT_SW_CKSUM_MODE
+	 *
+	 *  - HNS3_SPECIAL_PORT_SW_CKSUM_MODE
+	 *     In this mode, HW can not do checksum for special UDP port like
+	 *     4789, 4790, 6081 for non-tunnel UDP packets and UDP tunnel
+	 *     packets without the PKT_TX_TUNEL_MASK in the mbuf. So, PMD need
+	 *     do the checksum for these packets to avoid a checksum error.
+	 *
+	 *  - HNS3_SPECIAL_PORT_HW_CKSUM_MODE
+	 *     In this mode, HW does not have the preceding problems and can
+	 *     directly calculate the checksum of these UDP packets.
+	 */
+	uint8_t udp_cksum_mode;
 
 	struct hns3_port_base_vlan_config port_base_vlan_cfg;
 	/*
diff --git a/drivers/net/hns3/hns3_rxtx.c b/drivers/net/hns3/hns3_rxtx.c
index a76dfa5..3d7e831 100644
--- a/drivers/net/hns3/hns3_rxtx.c
+++ b/drivers/net/hns3/hns3_rxtx.c
@@ -5,6 +5,7 @@
 #include <rte_bus_pci.h>
 #include <rte_common.h>
 #include <rte_cycles.h>
+#include <rte_geneve.h>
 #include <rte_vxlan.h>
 #include <ethdev_driver.h>
 #include <rte_io.h>
@@ -2920,6 +2921,7 @@ hns3_tx_queue_setup(struct rte_eth_dev *dev, uint16_t idx, uint16_t nb_desc,
 					     HNS3_RING_TX_TAIL_REG);
 	txq->min_tx_pkt_len = hw->min_tx_pkt_len;
 	txq->tso_mode = hw->tso_mode;
+	txq->udp_cksum_mode = hw->udp_cksum_mode;
 	memset(&txq->basic_stats, 0, sizeof(struct hns3_tx_basic_stats));
 	memset(&txq->dfx_stats, 0, sizeof(struct hns3_tx_dfx_stats));
 
@@ -3629,6 +3631,69 @@ hns3_vld_vlan_chk(struct hns3_tx_queue *txq, struct rte_mbuf *m)
 }
 #endif
 
+static uint16_t
+hns3_udp_cksum_help(struct rte_mbuf *m)
+{
+	uint64_t ol_flags = m->ol_flags;
+	uint16_t cksum = 0;
+	uint32_t l4_len;
+
+	if (ol_flags & PKT_TX_IPV4) {
+		struct rte_ipv4_hdr *ipv4_hdr = rte_pktmbuf_mtod_offset(m,
+				struct rte_ipv4_hdr *, m->l2_len);
+		l4_len = rte_be_to_cpu_16(ipv4_hdr->total_length) - m->l3_len;
+	} else {
+		struct rte_ipv6_hdr *ipv6_hdr = rte_pktmbuf_mtod_offset(m,
+				struct rte_ipv6_hdr *, m->l2_len);
+		l4_len = rte_be_to_cpu_16(ipv6_hdr->payload_len);
+	}
+
+	rte_raw_cksum_mbuf(m, m->l2_len + m->l3_len, l4_len, &cksum);
+
+	cksum = ~cksum;
+	/*
+	 * RFC 768:If the computed checksum is zero for UDP, it is transmitted
+	 * as all ones
+	 */
+	if (cksum == 0)
+		cksum = 0xffff;
+
+	return (uint16_t)cksum;
+}
+
+static bool
+hns3_validate_tunnel_cksum(struct hns3_tx_queue *tx_queue, struct rte_mbuf *m)
+{
+	uint64_t ol_flags = m->ol_flags;
+	struct rte_udp_hdr *udp_hdr;
+	uint16_t dst_port;
+
+	if (tx_queue->udp_cksum_mode == HNS3_SPECIAL_PORT_HW_CKSUM_MODE ||
+	    ol_flags & PKT_TX_TUNNEL_MASK ||
+	    (ol_flags & PKT_TX_L4_MASK) != PKT_TX_UDP_CKSUM)
+		return true;
+	/*
+	 * A UDP packet with the same dst_port as VXLAN\VXLAN_GPE\GENEVE will
+	 * be recognized as a tunnel packet in HW. In this case, if UDP CKSUM
+	 * offload is set and the tunnel mask has not been set, the CKSUM will
+	 * be wrong since the header length is wrong and driver should complete
+	 * the CKSUM to avoid CKSUM error.
+	 */
+	udp_hdr = rte_pktmbuf_mtod_offset(m, struct rte_udp_hdr *,
+						m->l2_len + m->l3_len);
+	dst_port = rte_be_to_cpu_16(udp_hdr->dst_port);
+	switch (dst_port) {
+	case RTE_VXLAN_DEFAULT_PORT:
+	case RTE_VXLAN_GPE_DEFAULT_PORT:
+	case RTE_GENEVE_DEFAULT_PORT:
+		udp_hdr->dgram_cksum = hns3_udp_cksum_help(m);
+		m->ol_flags = ol_flags & ~PKT_TX_L4_MASK;
+		return false;
+	default:
+		return true;
+	}
+}
+
 static int
 hns3_prep_pkt_proc(struct hns3_tx_queue *tx_queue, struct rte_mbuf *m)
 {
@@ -3673,6 +3738,9 @@ hns3_prep_pkt_proc(struct hns3_tx_queue *tx_queue, struct rte_mbuf *m)
 		return ret;
 	}
 
+	if (!hns3_validate_tunnel_cksum(tx_queue, m))
+		return 0;
+
 	hns3_outer_header_cksum_prepare(m);
 
 	return 0;
diff --git a/drivers/net/hns3/hns3_rxtx.h b/drivers/net/hns3/hns3_rxtx.h
index ab2b05a..2a51c71 100644
--- a/drivers/net/hns3/hns3_rxtx.h
+++ b/drivers/net/hns3/hns3_rxtx.h
@@ -466,6 +466,22 @@ struct hns3_tx_queue {
 	 */
 	uint8_t tso_mode;
 	/*
+	 * udp checksum mode.
+	 * value range:
+	 *      HNS3_SPECIAL_PORT_HW_CKSUM_MODE/HNS3_SPECIAL_PORT_SW_CKSUM_MODE
+	 *
+	 *  - HNS3_SPECIAL_PORT_SW_CKSUM_MODE
+	 *     In this mode, HW can not do checksum for special UDP port like
+	 *     4789, 4790, 6081 for non-tunnel UDP packets and UDP tunnel
+	 *     packets without the PKT_TX_TUNEL_MASK in the mbuf. So, PMD need
+	 *     do the checksum for these packets to avoid a checksum error.
+	 *
+	 *  - HNS3_SPECIAL_PORT_HW_CKSUM_MODE
+	 *     In this mode, HW does not have the preceding problems and can
+	 *     directly calculate the checksum of these UDP packets.
+	 */
+	uint8_t udp_cksum_mode;
+	/*
 	 * The minimum length of the packet supported by hardware in the Tx
 	 * direction.
 	 */
-- 
2.7.4

[dpdk-dev] [PATCH 5/6] net/hns3: fix link update when failed to get link info

[Min Hu (Connor)]

From: Huisong Li <lihuisong@huawei.com>

In the "hns3_dev_link_update" API, the link information of the port is
obtained first, and then 'dev_link' in dev->data is updated. When the
driver is resetting or fails to obtain link info, the current driver
still reports the previous link info to the user. This may cause that
the dev->data->dev_link may be inconsistent with the hw link status.

Therefore, the link status consistency between the hardware, driver,
and framework can be ensured in this interface regardless of whether
the driver is normal or abnormal.

Fixes: 109e4dd1bd7a ("net/hns3: get link state change through mailbox")
Cc: stable@dpdk.org

Signed-off-by: Huisong Li <lihuisong@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
---
 drivers/net/hns3/hns3_ethdev.c | 55 +++++++++++++++++++++++++++++-------------
 1 file changed, 38 insertions(+), 17 deletions(-)

diff --git a/drivers/net/hns3/hns3_ethdev.c b/drivers/net/hns3/hns3_ethdev.c
index c318350..951f724 100644
--- a/drivers/net/hns3/hns3_ethdev.c
+++ b/drivers/net/hns3/hns3_ethdev.c
@@ -2698,20 +2698,22 @@ hns3_fw_version_get(struct rte_eth_dev *eth_dev, char *fw_version,
 }
 
 static int
-hns3_dev_link_update(struct rte_eth_dev *eth_dev,
-		     __rte_unused int wait_to_complete)
+hns3_update_port_link_info(struct rte_eth_dev *eth_dev)
 {
-	struct hns3_adapter *hns = eth_dev->data->dev_private;
-	struct hns3_hw *hw = &hns->hw;
-	struct hns3_mac *mac = &hw->mac;
-	struct rte_eth_link new_link;
+	struct hns3_hw *hw = HNS3_DEV_PRIVATE_TO_HW(eth_dev->data->dev_private);
 
-	if (!hns3_is_reset_pending(hns)) {
-		hns3_update_link_status(hw);
-		hns3_update_link_info(eth_dev);
-	}
+	(void)hns3_update_link_status(hw);
+
+	return hns3_update_link_info(eth_dev);
+}
+
+static void
+hns3_setup_linkstatus(struct rte_eth_dev *eth_dev,
+		      struct rte_eth_link *new_link)
+{
+	struct hns3_hw *hw = HNS3_DEV_PRIVATE_TO_HW(eth_dev->data->dev_private);
+	struct hns3_mac *mac = &hw->mac;
 
-	memset(&new_link, 0, sizeof(new_link));
 	switch (mac->link_speed) {
 	case ETH_SPEED_NUM_10M:
 	case ETH_SPEED_NUM_100M:
@@ -2722,20 +2724,39 @@ hns3_dev_link_update(struct rte_eth_dev *eth_dev,
 	case ETH_SPEED_NUM_50G:
 	case ETH_SPEED_NUM_100G:
 	case ETH_SPEED_NUM_200G:
-		new_link.link_speed = mac->link_speed;
+		new_link->link_speed = mac->link_speed;
 		break;
 	default:
 		if (mac->link_status)
-			new_link.link_speed = ETH_SPEED_NUM_UNKNOWN;
+			new_link->link_speed = ETH_SPEED_NUM_UNKNOWN;
 		else
-			new_link.link_speed = ETH_SPEED_NUM_NONE;
+			new_link->link_speed = ETH_SPEED_NUM_NONE;
 		break;
 	}
 
-	new_link.link_duplex = mac->link_duplex;
-	new_link.link_status = mac->link_status ? ETH_LINK_UP : ETH_LINK_DOWN;
-	new_link.link_autoneg =
+	new_link->link_duplex = mac->link_duplex;
+	new_link->link_status = mac->link_status ? ETH_LINK_UP : ETH_LINK_DOWN;
+	new_link->link_autoneg =
 	    !(eth_dev->data->dev_conf.link_speeds & ETH_LINK_SPEED_FIXED);
+}
+
+static int
+hns3_dev_link_update(struct rte_eth_dev *eth_dev,
+		     __rte_unused int wait_to_complete)
+{
+	struct hns3_hw *hw = HNS3_DEV_PRIVATE_TO_HW(eth_dev->data->dev_private);
+	struct hns3_mac *mac = &hw->mac;
+	struct rte_eth_link new_link;
+	int ret;
+
+	ret = hns3_update_port_link_info(eth_dev);
+	if (ret) {
+		mac->link_status = ETH_LINK_DOWN;
+		hns3_err(hw, "failed to get port link info, ret = %d.", ret);
+	}
+
+	memset(&new_link, 0, sizeof(new_link));
+	hns3_setup_linkstatus(eth_dev, &new_link);
 
 	return rte_eth_linkstatus_set(eth_dev, &new_link);
 }
-- 
2.7.4

[dpdk-dev] [PATCH 6/6] net/hns3: fix the long taskqueue pairs reset time

[Min Hu (Connor)]

From: Chengchang Tang <tangchengchang@huawei.com>

Currently, the queue reset process needs to be performed one by one, which
is inefficient. However, the queues reset in the same function is almost at
the same stage. To optimize the queue reset process, a new function has
been added to the firmware command HNS3_OPC_CFG_RST_TRIGGER to reset all
queues in the same function at a time. And the related queue reset MBX
message is adjusted in the same way too.

Fixes: bba636698316 ("net/hns3: support Rx/Tx and related operations")
Cc: stable@dpdk.org

Signed-off-by: Chengchang Tang <tangchengchang@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
---
 drivers/net/hns3/hns3_cmd.h  |   8 ++-
 drivers/net/hns3/hns3_rxtx.c | 125 ++++++++++++++++++++++++++++++++++++-------
 2 files changed, 114 insertions(+), 19 deletions(-)

diff --git a/drivers/net/hns3/hns3_cmd.h b/drivers/net/hns3/hns3_cmd.h
index 939bbc2..2e911ef 100644
--- a/drivers/net/hns3/hns3_cmd.h
+++ b/drivers/net/hns3/hns3_cmd.h
@@ -933,10 +933,16 @@ struct hns3_reset_tqp_queue_cmd {
 
 #define HNS3_CFG_RESET_MAC_B		3
 #define HNS3_CFG_RESET_FUNC_B		7
+#define HNS3_CFG_RESET_RCB_B		1
 struct hns3_reset_cmd {
 	uint8_t mac_func_reset;
 	uint8_t fun_reset_vfid;
-	uint8_t rsv[22];
+	uint8_t fun_reset_rcb;
+	uint8_t rsv1;
+	uint16_t fun_reset_rcb_vqid_start;
+	uint16_t fun_reset_rcb_vqid_num;
+	uint8_t fun_reset_rcb_return_status;
+	uint8_t rsv2[15];
 };
 
 #define HNS3_QUERY_DEV_SPECS_BD_NUM		4
diff --git a/drivers/net/hns3/hns3_rxtx.c b/drivers/net/hns3/hns3_rxtx.c
index 3d7e831..a6722d3 100644
--- a/drivers/net/hns3/hns3_rxtx.c
+++ b/drivers/net/hns3/hns3_rxtx.c
@@ -629,10 +629,6 @@ hns3pf_reset_tqp(struct hns3_hw *hw, uint16_t queue_id)
 	uint64_t end;
 	int ret;
 
-	ret = hns3_tqp_enable(hw, queue_id, false);
-	if (ret)
-		return ret;
-
 	/*
 	 * In current version VF is not supported when PF is driven by DPDK
 	 * driver, all task queue pairs are mapped to PF function, so PF's queue
@@ -679,11 +675,6 @@ hns3vf_reset_tqp(struct hns3_hw *hw, uint16_t queue_id)
 	uint8_t msg_data[2];
 	int ret;
 
-	/* Disable VF's queue before send queue reset msg to PF */
-	ret = hns3_tqp_enable(hw, queue_id, false);
-	if (ret)
-		return ret;
-
 	memcpy(msg_data, &queue_id, sizeof(uint16_t));
 
 	ret = hns3_send_mbx_msg(hw, HNS3_MBX_QUEUE_RESET, 0, msg_data,
@@ -695,14 +686,105 @@ hns3vf_reset_tqp(struct hns3_hw *hw, uint16_t queue_id)
 }
 
 static int
-hns3_reset_tqp(struct hns3_adapter *hns, uint16_t queue_id)
+hns3_reset_rcb_cmd(struct hns3_hw *hw, uint8_t *reset_status)
 {
-	struct hns3_hw *hw = &hns->hw;
+	struct hns3_reset_cmd *req;
+	struct hns3_cmd_desc desc;
+	int ret;
 
-	if (hns->is_vf)
-		return hns3vf_reset_tqp(hw, queue_id);
-	else
-		return hns3pf_reset_tqp(hw, queue_id);
+	hns3_cmd_setup_basic_desc(&desc, HNS3_OPC_CFG_RST_TRIGGER, false);
+	req = (struct hns3_reset_cmd *)desc.data;
+	hns3_set_bit(req->mac_func_reset, HNS3_CFG_RESET_RCB_B, 1);
+
+	/*
+	 * The start qid should be the global qid of the first tqp of the
+	 * function which should be reset in this port. Since our PF not
+	 * support take over of VFs, so we only need to reset function 0,
+	 * and its start qid is always 0.
+	 */
+	req->fun_reset_rcb_vqid_start = rte_cpu_to_le_16(0);
+	req->fun_reset_rcb_vqid_num = rte_cpu_to_le_16(hw->cfg_max_queues);
+
+	ret = hns3_cmd_send(hw, &desc, 1);
+	if (ret) {
+		hns3_err(hw, "fail to send rcb reset cmd, ret = %d.", ret);
+		return ret;
+	}
+
+	*reset_status = req->fun_reset_rcb_return_status;
+	return 0;
+}
+
+static int
+hns3pf_reset_all_tqps(struct hns3_hw *hw)
+{
+#define HNS3_RESET_RCB_NOT_SUPPORT	0U
+#define HNS3_RESET_ALL_TQP_SUCCESS	1U
+	uint8_t reset_status;
+	int ret;
+	int i;
+
+	ret = hns3_reset_rcb_cmd(hw, &reset_status);
+	if (ret)
+		return ret;
+
+	/*
+	 * If the firmware version is low, it may not support the rcb reset
+	 * which means reset all the tqps at a time. In this case, we should
+	 * reset tqps one by one.
+	 */
+	if (reset_status == HNS3_RESET_RCB_NOT_SUPPORT) {
+		for (i = 0; i < hw->cfg_max_queues; i++) {
+			ret = hns3pf_reset_tqp(hw, i);
+			if (ret) {
+				hns3_err(hw,
+				  "fail to reset tqp, queue_id = %d, ret = %d.",
+				  i, ret);
+				return ret;
+			}
+		}
+	} else if (reset_status != HNS3_RESET_ALL_TQP_SUCCESS) {
+		hns3_err(hw, "fail to reset all tqps, reset_status = %u.",
+				reset_status);
+		return -EIO;
+	}
+
+	return 0;
+}
+
+static int
+hns3vf_reset_all_tqps(struct hns3_hw *hw)
+{
+#define HNS3VF_RESET_ALL_TQP_DONE	1U
+	uint8_t reset_status;
+	uint8_t msg_data[2];
+	int ret;
+	int i;
+
+	memset(msg_data, 0, sizeof(uint16_t));
+	ret = hns3_send_mbx_msg(hw, HNS3_MBX_QUEUE_RESET, 0, msg_data,
+				sizeof(msg_data), true, &reset_status,
+				sizeof(reset_status));
+	if (ret) {
+		hns3_err(hw, "fail to send rcb reset mbx, ret = %d.", ret);
+		return ret;
+	}
+
+	if (reset_status == HNS3VF_RESET_ALL_TQP_DONE)
+		return 0;
+
+	/*
+	 * If the firmware version or kernel PF version is low, it may not
+	 * support the rcb reset which means reset all the tqps at a time.
+	 * In this case, we should reset tqps one by one.
+	 */
+	for (i = 1; i < hw->cfg_max_queues; i++) {
+		ret = hns3vf_reset_tqp(hw, i);
+		if (ret)
+			return ret;
+	}
+
+	return 0;
 }
 
 int
@@ -711,14 +793,21 @@ hns3_reset_all_tqps(struct hns3_adapter *hns)
 	struct hns3_hw *hw = &hns->hw;
 	int ret, i;
 
+	/* Disable all queues before reset all queues */
 	for (i = 0; i < hw->cfg_max_queues; i++) {
-		ret = hns3_reset_tqp(hns, i);
+		ret = hns3_tqp_enable(hw, i, false);
 		if (ret) {
-			hns3_err(hw, "Failed to reset No.%d queue: %d", i, ret);
+			hns3_err(hw,
+			    "fail to disable tqps before tqps reset, ret = %d.",
+			    ret);
 			return ret;
 		}
 	}
-	return 0;
+
+	if (hns->is_vf)
+		return hns3vf_reset_all_tqps(hw);
+	else
+		return hns3pf_reset_all_tqps(hw);
 }
 
 static int
-- 
2.7.4

Re: [dpdk-dev] [PATCH 2/6] net/hns3: fix compiling error for using SVE algorithm

[Ferruh Yigit]

On 3/23/2021 1:45 PM, Min Hu (Connor) wrote:
> From: Huisong Li <lihuisong@huawei.com>
> 
> The 'queue_full_cnt' stats have been encapsulated in 'dfx_stats'.
> However, the modification in the SVE algorithm is omitted.
> As a result, the driver fails to be compiled when the SVE
> algorithm is used.
> 
> Fixes: 9b77f1fe303f ("net/hns3: encapsulate DFX stats in datapath")
> 
> Signed-off-by: Huisong Li <lihuisong@huawei.com>
> Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
> ---
>   drivers/net/hns3/hns3_rxtx_vec_sve.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/hns3/hns3_rxtx_vec_sve.c b/drivers/net/hns3/hns3_rxtx_vec_sve.c
> index f8655fa..e1a1731 100644
> --- a/drivers/net/hns3/hns3_rxtx_vec_sve.c
> +++ b/drivers/net/hns3/hns3_rxtx_vec_sve.c
> @@ -439,7 +439,7 @@ hns3_xmit_fixed_burst_vec_sve(void *__restrict tx_queue,
>   
>   	nb_pkts = RTE_MIN(txq->tx_bd_ready, nb_pkts);
>   	if (unlikely(nb_pkts == 0)) {
> -		txq->queue_full_cnt++;
> +		txq->dfx_stats.queue_full_cnt++;
>   		return 0;
>   	}
>   
> 

Hi Connor,

This is a very obvious build error, I am concerned how this is released. Do you 
have any internal testing?

+ Aaron & Honnappa,

If we can have a build test in our public CI with SVE?

Re: [dpdk-dev] [PATCH 2/6] net/hns3: fix compiling error for using SVE algorithm

[Aaron Conole]

Ferruh Yigit <ferruh.yigit@intel.com> writes:

> On 3/23/2021 1:45 PM, Min Hu (Connor) wrote:
>> From: Huisong Li <lihuisong@huawei.com>
>>
>> The 'queue_full_cnt' stats have been encapsulated in 'dfx_stats'.
>> However, the modification in the SVE algorithm is omitted.
>> As a result, the driver fails to be compiled when the SVE
>> algorithm is used.
>>
>> Fixes: 9b77f1fe303f ("net/hns3: encapsulate DFX stats in datapath")
>>
>> Signed-off-by: Huisong Li <lihuisong@huawei.com>
>> Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
>> ---
>>   drivers/net/hns3/hns3_rxtx_vec_sve.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/hns3/hns3_rxtx_vec_sve.c b/drivers/net/hns3/hns3_rxtx_vec_sve.c
>> index f8655fa..e1a1731 100644
>> --- a/drivers/net/hns3/hns3_rxtx_vec_sve.c
>> +++ b/drivers/net/hns3/hns3_rxtx_vec_sve.c
>> @@ -439,7 +439,7 @@ hns3_xmit_fixed_burst_vec_sve(void *__restrict tx_queue,
>>     	nb_pkts = RTE_MIN(txq->tx_bd_ready, nb_pkts);
>>   	if (unlikely(nb_pkts == 0)) {
>> -		txq->queue_full_cnt++;
>> +		txq->dfx_stats.queue_full_cnt++;
>>   		return 0;
>>   	}
>>   
>>
>
> Hi Connor,
>
> This is a very obvious build error, I am concerned how this is
> released. Do you have any internal testing?
>
> + Aaron & Honnappa,
>
> If we can have a build test in our public CI with SVE?

Maybe it's possible - we might need to expand the aarch64 cross builds
with a bit of extra information.  I'm not sure which compiler is needed,
though.  Currently, we install whatever ubuntu18.04 is providing - I
don't know if it has the SVE extensions needed.  Honnappa/ARM folks can
provide more information that way - though I would expect it's just a
setting that can be changed in the host_machine or properties section of
the cross-config file.

If that's known (maybe we need to use the thunderx2 config or something
else?  I don't know too much about enabling compiler support for SVE),
then we should probably hook it up.

Re: [dpdk-dev] [PATCH 2/6] net/hns3: fix compiling error for using SVE algorithm

[David Marchand]

On Mon, Mar 29, 2021 at 8:32 PM Aaron Conole <aconole@redhat.com> wrote:
> Ferruh Yigit <ferruh.yigit@intel.com> writes:
> > This is a very obvious build error, I am concerned how this is
> > released. Do you have any internal testing?
> >
> > + Aaron & Honnappa,
> >
> > If we can have a build test in our public CI with SVE?
>
> Maybe it's possible - we might need to expand the aarch64 cross builds
> with a bit of extra information.  I'm not sure which compiler is needed,
> though.  Currently, we install whatever ubuntu18.04 is providing - I
> don't know if it has the SVE extensions needed.  Honnappa/ARM folks can
> provide more information that way - though I would expect it's just a
> setting that can be changed in the host_machine or properties section of
> the cross-config file.
>
> If that's known (maybe we need to use the thunderx2 config or something
> else?  I don't know too much about enabling compiler support for SVE),
> then we should probably hook it up.

Last time I tried SVE builds, I needed a gcc 10 + tweaking cross
compiler config.
http://inbox.dpdk.org/dev/CAJFAV8ywp0qA7qg7cGAhb1ULY72AwjZM6foDBej4roYNE8Oy5Q@mail.gmail.com/

Ruifeng had replied there was a gcc 10 for Ubuntu.
Not sure how others compile with SVE.

-- 
David Marchand

Re: [dpdk-dev] [PATCH 2/6] net/hns3: fix compiling error for using SVE algorithm

[Honnappa Nagarahalli]

<snip>

> Subject: Re: [PATCH 2/6] net/hns3: fix compiling error for using SVE algorithm
> 
> On Mon, Mar 29, 2021 at 8:32 PM Aaron Conole <aconole@redhat.com>
> wrote:
> > Ferruh Yigit <ferruh.yigit@intel.com> writes:
> > > This is a very obvious build error, I am concerned how this is
> > > released. Do you have any internal testing?
> > >
> > > + Aaron & Honnappa,
> > >
> > > If we can have a build test in our public CI with SVE?
> >
> > Maybe it's possible - we might need to expand the aarch64 cross builds
> > with a bit of extra information.  I'm not sure which compiler is
> > needed, though.  Currently, we install whatever ubuntu18.04 is
> > providing - I don't know if it has the SVE extensions needed.
> > Honnappa/ARM folks can provide more information that way - though I
> > would expect it's just a setting that can be changed in the
> > host_machine or properties section of the cross-config file.
> >
> > If that's known (maybe we need to use the thunderx2 config or
> > something else?  I don't know too much about enabling compiler support
> > for SVE), then we should probably hook it up.
Since, Kunpeng SoC has SVE enabled, we should have a Kunpeng config [1]. We could use that config to compile the code, through cross compile or through SoC target option for meson scripts[2].

[1] http://patches.dpdk.org/project/dpdk/patch/1616808435-25166-2-git-send-email-oulijun@huawei.com/
[2] http://patches.dpdk.org/project/dpdk/patch/1612361037-12746-3-git-send-email-juraj.linkes@pantheon.tech/

> 
> Last time I tried SVE builds, I needed a gcc 10 + tweaking cross compiler
> config.
> http://inbox.dpdk.org/dev/CAJFAV8ywp0qA7qg7cGAhb1ULY72AwjZM6foDB
> ej4roYNE8Oy5Q@mail.gmail.com/
> 
> Ruifeng had replied there was a gcc 10 for Ubuntu.
> Not sure how others compile with SVE.
> 
> --
> David Marchand

Re: [dpdk-dev] [PATCH 0/6] bugfixes for hns3

[Ferruh Yigit]

On 3/23/2021 1:45 PM, Min Hu (Connor) wrote:
> This series added six bugfix patches.
> 
> Chengchang Tang (3):
>    net/hns3: fix TCP SEG and TCP CKSUM flag set
>    net/hns3: fix Tx checksum for UDP packets with special port
>    net/hns3: fix the long taskqueue pairs reset time
> 
> Huisong Li (3):
>    net/hns3: fix the reporting of undefined speed
>    net/hns3: fix compiling error for using SVE algorithm
>    net/hns3: fix link update when failed to get link info
> 

Series applied to dpdk-next-net/main, thanks.

Re: [dpdk-dev] [PATCH 2/6] net/hns3: fix compiling error for using SVE algorithm

[Min Hu (Connor)]

在 2021/3/30 0:10, Ferruh Yigit 写道:
> On 3/23/2021 1:45 PM, Min Hu (Connor) wrote:
>> From: Huisong Li <lihuisong@huawei.com>
>>
>> The 'queue_full_cnt' stats have been encapsulated in 'dfx_stats'.
>> However, the modification in the SVE algorithm is omitted.
>> As a result, the driver fails to be compiled when the SVE
>> algorithm is used.
>>
>> Fixes: 9b77f1fe303f ("net/hns3: encapsulate DFX stats in datapath")
>>
>> Signed-off-by: Huisong Li <lihuisong@huawei.com>
>> Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
>> ---
>>   drivers/net/hns3/hns3_rxtx_vec_sve.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/hns3/hns3_rxtx_vec_sve.c 
>> b/drivers/net/hns3/hns3_rxtx_vec_sve.c
>> index f8655fa..e1a1731 100644
>> --- a/drivers/net/hns3/hns3_rxtx_vec_sve.c
>> +++ b/drivers/net/hns3/hns3_rxtx_vec_sve.c
>> @@ -439,7 +439,7 @@ hns3_xmit_fixed_burst_vec_sve(void *__restrict 
>> tx_queue,
>>       nb_pkts = RTE_MIN(txq->tx_bd_ready, nb_pkts);
>>       if (unlikely(nb_pkts == 0)) {
>> -        txq->queue_full_cnt++;
>> +        txq->dfx_stats.queue_full_cnt++;
>>           return 0;
>>       }
>>
> 
> Hi Connor,
> 
> This is a very obvious build error, I am concerned how this is released. 
> Do you have any internal testing?
> 
Hi Ferruh,
	Well, we admit it is our mistake for this issue. Let me
describe the reason:
	Firstly, we must declare that we have our inner CI system for
building and testing. While when we upstream the ""support SVE" patch,
our CI does not support SVE building. Instead we build and test SVE on
our local platform.
	Then when we upstream the "encapsulate DFX stats in datapath"
patch, we only build it in CI(at that time, SVE building is still not 
supported), regardless of SVE building on local platform.
	Now, SVE building is supported in our CI， So the building error
occurs.
	We'll pay more attention to the issue in the future. Thanks.

> + Aaron & Honnappa,
> 
> If we can have a build test in our public CI with SVE?
> 
> 
> .

Re: [dpdk-dev] [PATCH 2/6] net/hns3: fix compiling error for using SVE algorithm

[Ferruh Yigit]

On 3/31/2021 1:55 AM, Min Hu (Connor) wrote:
> 
> 
> 在 2021/3/30 0:10, Ferruh Yigit 写道:
>> On 3/23/2021 1:45 PM, Min Hu (Connor) wrote:
>>> From: Huisong Li <lihuisong@huawei.com>
>>>
>>> The 'queue_full_cnt' stats have been encapsulated in 'dfx_stats'.
>>> However, the modification in the SVE algorithm is omitted.
>>> As a result, the driver fails to be compiled when the SVE
>>> algorithm is used.
>>>
>>> Fixes: 9b77f1fe303f ("net/hns3: encapsulate DFX stats in datapath")
>>>
>>> Signed-off-by: Huisong Li <lihuisong@huawei.com>
>>> Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
>>> ---
>>>   drivers/net/hns3/hns3_rxtx_vec_sve.c | 2 +-
>>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/net/hns3/hns3_rxtx_vec_sve.c 
>>> b/drivers/net/hns3/hns3_rxtx_vec_sve.c
>>> index f8655fa..e1a1731 100644
>>> --- a/drivers/net/hns3/hns3_rxtx_vec_sve.c
>>> +++ b/drivers/net/hns3/hns3_rxtx_vec_sve.c
>>> @@ -439,7 +439,7 @@ hns3_xmit_fixed_burst_vec_sve(void *__restrict tx_queue,
>>>       nb_pkts = RTE_MIN(txq->tx_bd_ready, nb_pkts);
>>>       if (unlikely(nb_pkts == 0)) {
>>> -        txq->queue_full_cnt++;
>>> +        txq->dfx_stats.queue_full_cnt++;
>>>           return 0;
>>>       }
>>>
>>
>> Hi Connor,
>>
>> This is a very obvious build error, I am concerned how this is released. Do 
>> you have any internal testing?
>>
> Hi Ferruh,
>      Well, we admit it is our mistake for this issue. Let me
> describe the reason:
>      Firstly, we must declare that we have our inner CI system for
> building and testing. While when we upstream the ""support SVE" patch,
> our CI does not support SVE building. Instead we build and test SVE on
> our local platform.
>      Then when we upstream the "encapsulate DFX stats in datapath"
> patch, we only build it in CI(at that time, SVE building is still not 
> supported), regardless of SVE building on local platform.
>      Now, SVE building is supported in our CI， So the building error
> occurs.
>      We'll pay more attention to the issue in the future. Thanks.
> 

Good to hear your internal testing covers SVE now, thanks for clarification.