[dpdk-dev] [PATCH 00/12] Bugfix for hns3 PMD

[dpdk-dev] [PATCH 00/12] Bugfix for hns3 PMD

[Min Hu (Connor)]

This set of patches contains 12 bugfixes for hns3 PMD.

Chengchang Tang (2):
  net/hns3: fix potentially incorrect timing in MBX
  net/hns3: fix incorrect use of CMD status enumeration type

Chengwen Feng (10):
  net/hns3: delete mailbox arq ring
  net/hns3: fix possible mismatches response of mailbox
  net/hns3: fix VF may report LSC event in secondary process
  net/hns3: fix miss verification of whether NEON supported
  net/hns3: fix missing outer L4 UDP flag for VXLAN packet
  net/hns3: add reporting TUNNEL GRE packet type
  net/hns3: fix PTP caps report
  net/hns3: rename Rx burst API
  net/hns3: add supported ptypes list for RXD advanced layout
  net/hns3: remove VLAN/QINQ ptypes from support list

 drivers/net/hns3/hns3_cmd.c    |  17 ++-
 drivers/net/hns3/hns3_cmd.h    |   9 +-
 drivers/net/hns3/hns3_ethdev.c |  12 +-
 drivers/net/hns3/hns3_ethdev.h |   1 -
 drivers/net/hns3/hns3_mbx.c    | 282 +++++++++++++++++++++++++++++------------
 drivers/net/hns3/hns3_mbx.h    |  34 ++---
 drivers/net/hns3/hns3_rxtx.c   |  97 ++++++++++----
 drivers/net/hns3/hns3_rxtx.h   |   4 +-
 8 files changed, 313 insertions(+), 143 deletions(-)

-- 
2.7.4

[dpdk-dev] [PATCH 01/12] net/hns3: delete mailbox arq ring

[Min Hu (Connor)]

From: Chengwen Feng <fengchengwen@huawei.com>

Currently, driver will copy mailbox messages body into arq ring when
process HNS3_MBX_LINK_STAT_CHANGE and HNS3_MBX_LINK_STAT_CHANGE
message, and then call hns3_mbx_handler API which will direct process
pre-copy messages. In the whole process, the arq ring don't have a
substantial effect.

Note: The arq ring is designed for kernel environment which could not
do much job in interrupt context, but for DPDK it's not required.

Also we rename hns3_handle_link_change_event to
hns3pf_handle_link_change_event which add 'pf' suffix to make it
better to distinguish.

Fixes: 463e748964f5 ("net/hns3: support mailbox")
Cc: stable@dpdk.org

Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
---
 drivers/net/hns3/hns3_ethdev.h |  1 -
 drivers/net/hns3/hns3_mbx.c    | 83 +++++++++++++++++-------------------------
 drivers/net/hns3/hns3_mbx.h    | 14 -------
 3 files changed, 33 insertions(+), 65 deletions(-)

diff --git a/drivers/net/hns3/hns3_ethdev.h b/drivers/net/hns3/hns3_ethdev.h
index 72d718c..840880e 100644
--- a/drivers/net/hns3/hns3_ethdev.h
+++ b/drivers/net/hns3/hns3_ethdev.h
@@ -438,7 +438,6 @@ struct hns3_hw {
 	uint8_t revision;           /* PCI revision, low byte of class word */
 	struct hns3_cmq cmq;
 	struct hns3_mbx_resp_status mbx_resp; /* mailbox response */
-	struct hns3_mbx_arq_ring arq;         /* mailbox async rx queue */
 	struct hns3_mac mac;
 	unsigned int secondary_cnt; /* Number of secondary processes init'd. */
 	struct hns3_tqp_stats tqp_stats;
diff --git a/drivers/net/hns3/hns3_mbx.c b/drivers/net/hns3/hns3_mbx.c
index 97692ec..4326c7b 100644
--- a/drivers/net/hns3/hns3_mbx.c
+++ b/drivers/net/hns3/hns3_mbx.c
@@ -173,55 +173,42 @@ hns3_cmd_crq_empty(struct hns3_hw *hw)
 }
 
 static void
-hns3_mbx_handler(struct hns3_hw *hw)
+hns3vf_handle_link_change_event(struct hns3_hw *hw,
+				struct hns3_mbx_pf_to_vf_cmd *req)
 {
-	enum hns3_reset_level reset_level;
 	uint8_t link_status, link_duplex;
+	uint16_t *msg_q = req->msg;
 	uint8_t support_push_lsc;
 	uint32_t link_speed;
-	uint16_t *msg_q;
-	uint8_t opcode;
-	uint32_t tail;
 
-	tail = hw->arq.tail;
-
-	/* process all the async queue messages */
-	while (tail != hw->arq.head) {
-		msg_q = hw->arq.msg_q[hw->arq.head];
+	memcpy(&link_speed, &msg_q[2], sizeof(link_speed));
+	link_status = rte_le_to_cpu_16(msg_q[1]);
+	link_duplex = (uint8_t)rte_le_to_cpu_16(msg_q[4]);
+	hns3vf_update_link_status(hw, link_status, link_speed,
+				  link_duplex);
+	support_push_lsc = (*(uint8_t *)&msg_q[5]) & 1u;
+	hns3vf_update_push_lsc_cap(hw, support_push_lsc);
+}
 
-		opcode = msg_q[0] & 0xff;
-		switch (opcode) {
-		case HNS3_MBX_LINK_STAT_CHANGE:
-			memcpy(&link_speed, &msg_q[2], sizeof(link_speed));
-			link_status = rte_le_to_cpu_16(msg_q[1]);
-			link_duplex = (uint8_t)rte_le_to_cpu_16(msg_q[4]);
-			hns3vf_update_link_status(hw, link_status, link_speed,
-						  link_duplex);
-			support_push_lsc = (*(uint8_t *)&msg_q[5]) & 1u;
-			hns3vf_update_push_lsc_cap(hw, support_push_lsc);
-			break;
-		case HNS3_MBX_ASSERTING_RESET:
-			/* PF has asserted reset hence VF should go in pending
-			 * state and poll for the hardware reset status till it
-			 * has been completely reset. After this stack should
-			 * eventually be re-initialized.
-			 */
-			reset_level = rte_le_to_cpu_16(msg_q[1]);
-			hns3_atomic_set_bit(reset_level, &hw->reset.pending);
+static void
+hns3_handle_asserting_reset(struct hns3_hw *hw,
+			    struct hns3_mbx_pf_to_vf_cmd *req)
+{
+	enum hns3_reset_level reset_level;
+	uint16_t *msg_q = req->msg;
 
-			hns3_warn(hw, "PF inform reset level %d", reset_level);
-			hw->reset.stats.request_cnt++;
-			hns3_schedule_reset(HNS3_DEV_HW_TO_ADAPTER(hw));
-			break;
-		default:
-			hns3_err(hw, "Fetched unsupported(%u) message from arq",
-				 opcode);
-			break;
-		}
+	/*
+	 * PF has asserted reset hence VF should go in pending
+	 * state and poll for the hardware reset status till it
+	 * has been completely reset. After this stack should
+	 * eventually be re-initialized.
+	 */
+	reset_level = rte_le_to_cpu_16(msg_q[1]);
+	hns3_atomic_set_bit(reset_level, &hw->reset.pending);
 
-		hns3_mbx_head_ptr_move_arq(hw->arq);
-		msg_q = hw->arq.msg_q[hw->arq.head];
-	}
+	hns3_warn(hw, "PF inform reset level %d", reset_level);
+	hw->reset.stats.request_cnt++;
+	hns3_schedule_reset(HNS3_DEV_HW_TO_ADAPTER(hw));
 }
 
 /*
@@ -278,7 +265,7 @@ hns3_link_fail_parse(struct hns3_hw *hw, uint8_t link_fail_code)
 }
 
 static void
-hns3_handle_link_change_event(struct hns3_hw *hw,
+hns3pf_handle_link_change_event(struct hns3_hw *hw,
 			      struct hns3_mbx_pf_to_vf_cmd *req)
 {
 #define LINK_STATUS_OFFSET     1
@@ -337,7 +324,6 @@ hns3_dev_handle_mbx_msg(struct hns3_hw *hw)
 	struct hns3_mbx_pf_to_vf_cmd *req;
 	struct hns3_cmd_desc *desc;
 	uint32_t msg_data;
-	uint16_t *msg_q;
 	uint8_t opcode;
 	uint16_t flag;
 	uint8_t *temp;
@@ -380,16 +366,13 @@ hns3_dev_handle_mbx_msg(struct hns3_hw *hw)
 			hns3_update_resp_position(hw, msg_data);
 			break;
 		case HNS3_MBX_LINK_STAT_CHANGE:
+			hns3vf_handle_link_change_event(hw, req);
+			break;
 		case HNS3_MBX_ASSERTING_RESET:
-			msg_q = hw->arq.msg_q[hw->arq.tail];
-			memcpy(&msg_q[0], req->msg,
-			       HNS3_MBX_MAX_ARQ_MSG_SIZE * sizeof(uint16_t));
-			hns3_mbx_tail_ptr_move_arq(hw->arq);
-
-			hns3_mbx_handler(hw);
+			hns3_handle_asserting_reset(hw, req);
 			break;
 		case HNS3_MBX_PUSH_LINK_STATUS:
-			hns3_handle_link_change_event(hw, req);
+			hns3pf_handle_link_change_event(hw, req);
 			break;
 		case HNS3_MBX_PUSH_VLAN_INFO:
 			/*
diff --git a/drivers/net/hns3/hns3_mbx.h b/drivers/net/hns3/hns3_mbx.h
index 5714eb1..45aa4cd 100644
--- a/drivers/net/hns3/hns3_mbx.h
+++ b/drivers/net/hns3/hns3_mbx.h
@@ -144,22 +144,8 @@ struct hns3_pf_rst_done_cmd {
 
 #define HNS3_PF_RESET_DONE_BIT		BIT(0)
 
-/* used by VF to store the received Async responses from PF */
-struct hns3_mbx_arq_ring {
-#define HNS3_MBX_MAX_ARQ_MSG_SIZE	8
-#define HNS3_MBX_MAX_ARQ_MSG_NUM	1024
-	uint32_t head;
-	uint32_t tail;
-	uint32_t count;
-	uint16_t msg_q[HNS3_MBX_MAX_ARQ_MSG_NUM][HNS3_MBX_MAX_ARQ_MSG_SIZE];
-};
-
 #define hns3_mbx_ring_ptr_move_crq(crq) \
 	((crq)->next_to_use = ((crq)->next_to_use + 1) % (crq)->desc_num)
-#define hns3_mbx_tail_ptr_move_arq(arq) \
-	((arq).tail = ((arq).tail + 1) % HNS3_MBX_MAX_ARQ_MSG_SIZE)
-#define hns3_mbx_head_ptr_move_arq(arq) \
-		((arq).head = ((arq).head + 1) % HNS3_MBX_MAX_ARQ_MSG_SIZE)
 
 struct hns3_hw;
 void hns3_dev_handle_mbx_msg(struct hns3_hw *hw);
-- 
2.7.4

[dpdk-dev] [PATCH 02/12] net/hns3: fix possible mismatches response of mailbox

[Min Hu (Connor)]

From: Chengwen Feng <fengchengwen@huawei.com>

Currently, the mailbox synchronous communication between VF and PF use
the following fields to maintain communication:
1. Req_msg_data which was combined by message code and subcode, used
to match request and response.
2. Head which means the number of requests successfully sent by VF.
3. Tail which means the number of responses successfully received by
VF.
4. Lost which means the number of requests which are timeout.

There may possible mismatches of the following situation:
1. VF sends message A with code=1 subcode=1.
	Then head=1, tail=0, lost=0.
2. PF was blocked about 500ms when processing the message A.
3. VF will detect message A timeout because it can't get the response
within 500ms.
	Then head=1, tail=0, lost=1.
4. VF sends message B with code=1 subcode=1 which equal message A.
	Then head=2, tail=0, lost=1.
5. PF processes the first message A and send the response message to
VF.
6. VF will update tail field to 1, but the lost field will remain
unchanged because the code/subcode equal message B's, so driver will
return success because now the head(2) equals tail(1) plus lost(1).
This will lead to mismatch of request and response.

To fix the above bug, we use the following scheme:
1. The message sent from VF was labelled with match_id which was a
unique 16-bit non-zero value.
2. The response sent from PF will label with match_id which got from
the request.
3. The VF uses the match_id to match request and response message.

This scheme depends on the PF driver, if the PF driver don't support
then VF will uses the original scheme.

Fixes: 463e748964f5 ("net/hns3: support mailbox")
Cc: stable@dpdk.org

Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
---
 drivers/net/hns3/hns3_mbx.c | 120 +++++++++++++++++++++++++++++++++++---------
 drivers/net/hns3/hns3_mbx.h |  20 +++++++-
 2 files changed, 114 insertions(+), 26 deletions(-)

diff --git a/drivers/net/hns3/hns3_mbx.c b/drivers/net/hns3/hns3_mbx.c
index 4326c7b..8e38649 100644
--- a/drivers/net/hns3/hns3_mbx.c
+++ b/drivers/net/hns3/hns3_mbx.c
@@ -40,14 +40,32 @@ hns3_resp_to_errno(uint16_t resp_code)
 	return -EIO;
 }
 
+static void
+hns3_mbx_proc_timeout(struct hns3_hw *hw, uint16_t code, uint16_t subcode)
+{
+	if (hw->mbx_resp.matching_scheme ==
+	    HNS3_MBX_RESP_MATCHING_SCHEME_OF_ORIGINAL) {
+		hw->mbx_resp.lost++;
+		hns3_err(hw,
+			 "VF could not get mbx(%u,%u) head(%u) tail(%u) "
+			 "lost(%u) from PF",
+			 code, subcode, hw->mbx_resp.head, hw->mbx_resp.tail,
+			 hw->mbx_resp.lost);
+		return;
+	}
+
+	hns3_err(hw, "VF could not get mbx(%u,%u) from PF", code, subcode);
+}
+
 static int
-hns3_get_mbx_resp(struct hns3_hw *hw, uint16_t code0, uint16_t code1,
+hns3_get_mbx_resp(struct hns3_hw *hw, uint16_t code, uint16_t subcode,
 		  uint8_t *resp_data, uint16_t resp_len)
 {
 #define HNS3_MAX_RETRY_MS	500
 #define HNS3_WAIT_RESP_US	100
 	struct hns3_adapter *hns = HNS3_DEV_HW_TO_ADAPTER(hw);
 	struct hns3_mbx_resp_status *mbx_resp;
+	bool received;
 	uint64_t now;
 	uint64_t end;
 
@@ -59,8 +77,7 @@ hns3_get_mbx_resp(struct hns3_hw *hw, uint16_t code0, uint16_t code1,
 
 	now = get_timeofday_ms();
 	end = now + HNS3_MAX_RETRY_MS;
-	while ((hw->mbx_resp.head != hw->mbx_resp.tail + hw->mbx_resp.lost) &&
-	       (now < end)) {
+	while (now < end) {
 		if (__atomic_load_n(&hw->reset.disable_cmd, __ATOMIC_RELAXED)) {
 			hns3_err(hw, "Don't wait for mbx respone because of "
 				 "disable_cmd");
@@ -77,16 +94,20 @@ hns3_get_mbx_resp(struct hns3_hw *hw, uint16_t code0, uint16_t code1,
 		hns3_dev_handle_mbx_msg(hw);
 		rte_delay_us(HNS3_WAIT_RESP_US);
 
+		if (hw->mbx_resp.matching_scheme ==
+		    HNS3_MBX_RESP_MATCHING_SCHEME_OF_ORIGINAL)
+			received = (hw->mbx_resp.head ==
+				    hw->mbx_resp.tail + hw->mbx_resp.lost);
+		else
+			received = hw->mbx_resp.received_match_resp;
+		if (received)
+			break;
+
 		now = get_timeofday_ms();
 	}
 	hw->mbx_resp.req_msg_data = 0;
 	if (now >= end) {
-		hw->mbx_resp.lost++;
-		hns3_err(hw,
-			 "VF could not get mbx(%u,%u) head(%u) tail(%u) "
-			 "lost(%u) from PF",
-			 code0, code1, hw->mbx_resp.head, hw->mbx_resp.tail,
-			 hw->mbx_resp.lost);
+		hns3_mbx_proc_timeout(hw, code, subcode);
 		return -ETIME;
 	}
 	rte_io_rmb();
@@ -101,6 +122,29 @@ hns3_get_mbx_resp(struct hns3_hw *hw, uint16_t code0, uint16_t code1,
 	return 0;
 }
 
+static void
+hns3_mbx_prepare_resp(struct hns3_hw *hw, uint16_t code, uint16_t subcode)
+{
+	/*
+	 * Init both matching scheme fields because we may not know the exact
+	 * scheme will be used when in the initial phase.
+	 *
+	 * Also, there are OK to init both matching scheme fields even though
+	 * we get the exact scheme which is used.
+	 */
+	hw->mbx_resp.req_msg_data = (uint32_t)code << 16 | subcode;
+	hw->mbx_resp.head++;
+
+	/* Update match_id and ensure the value of match_id is not zero */
+	hw->mbx_resp.match_id++;
+	if (hw->mbx_resp.match_id == 0)
+		hw->mbx_resp.match_id = 1;
+	hw->mbx_resp.received_match_resp = false;
+
+	hw->mbx_resp.resp_status = 0;
+	memset(hw->mbx_resp.additional_info, 0, HNS3_MBX_MAX_RESP_DATA_SIZE);
+}
+
 int
 hns3_send_mbx_msg(struct hns3_hw *hw, uint16_t code, uint16_t subcode,
 		  const uint8_t *msg_data, uint8_t msg_len, bool need_resp,
@@ -138,8 +182,8 @@ hns3_send_mbx_msg(struct hns3_hw *hw, uint16_t code, uint16_t subcode,
 	if (need_resp) {
 		req->mbx_need_resp |= HNS3_MBX_NEED_RESP_BIT;
 		rte_spinlock_lock(&hw->mbx_resp.lock);
-		hw->mbx_resp.req_msg_data = (uint32_t)code << 16 | subcode;
-		hw->mbx_resp.head++;
+		hns3_mbx_prepare_resp(hw, code, subcode);
+		req->match_id = hw->mbx_resp.match_id;
 		ret = hns3_cmd_send(hw, &desc, 1);
 		if (ret) {
 			hw->mbx_resp.head--;
@@ -244,6 +288,46 @@ hns3_update_resp_position(struct hns3_hw *hw, uint32_t resp_msg)
 }
 
 static void
+hns3_handle_mbx_response(struct hns3_hw *hw, struct hns3_mbx_pf_to_vf_cmd *req)
+{
+	struct hns3_mbx_resp_status *resp = &hw->mbx_resp;
+	uint32_t msg_data;
+
+	if (req->match_id != 0) {
+		/*
+		 * If match_id is not zero, it means PF support copy request's
+		 * match_id to its response. So VF could use the match_id
+		 * to match the request.
+		 */
+		if (resp->matching_scheme !=
+		    HNS3_MBX_RESP_MATCHING_SCHEME_OF_MATCH_ID) {
+			resp->matching_scheme =
+				HNS3_MBX_RESP_MATCHING_SCHEME_OF_MATCH_ID;
+			hns3_info(hw, "detect mailbox support match id!");
+		}
+		if (req->match_id == resp->match_id) {
+			resp->resp_status = hns3_resp_to_errno(req->msg[3]);
+			memcpy(resp->additional_info, &req->msg[4],
+			       HNS3_MBX_MAX_RESP_DATA_SIZE);
+			rte_io_wmb();
+			resp->received_match_resp = true;
+		}
+		return;
+	}
+
+	/*
+	 * If the below instructions can be executed, it means PF does not
+	 * support copy request's match_id to its response. So VF follows the
+	 * original scheme to process.
+	 */
+	resp->resp_status = hns3_resp_to_errno(req->msg[3]);
+	memcpy(resp->additional_info, &req->msg[4],
+	       HNS3_MBX_MAX_RESP_DATA_SIZE);
+	msg_data = (uint32_t)req->msg[1] << 16 | req->msg[2];
+	hns3_update_resp_position(hw, msg_data);
+}
+
+static void
 hns3_link_fail_parse(struct hns3_hw *hw, uint8_t link_fail_code)
 {
 	switch (link_fail_code) {
@@ -319,15 +403,11 @@ hns3_handle_promisc_info(struct hns3_hw *hw, uint16_t promisc_en)
 void
 hns3_dev_handle_mbx_msg(struct hns3_hw *hw)
 {
-	struct hns3_mbx_resp_status *resp = &hw->mbx_resp;
 	struct hns3_cmq_ring *crq = &hw->cmq.crq;
 	struct hns3_mbx_pf_to_vf_cmd *req;
 	struct hns3_cmd_desc *desc;
-	uint32_t msg_data;
 	uint8_t opcode;
 	uint16_t flag;
-	uint8_t *temp;
-	int i;
 
 	rte_spinlock_lock(&hw->cmq.crq.lock);
 
@@ -355,15 +435,7 @@ hns3_dev_handle_mbx_msg(struct hns3_hw *hw)
 
 		switch (opcode) {
 		case HNS3_MBX_PF_VF_RESP:
-			resp->resp_status = hns3_resp_to_errno(req->msg[3]);
-
-			temp = (uint8_t *)&req->msg[4];
-			for (i = 0; i < HNS3_MBX_MAX_RESP_DATA_SIZE; i++) {
-				resp->additional_info[i] = *temp;
-				temp++;
-			}
-			msg_data = (uint32_t)req->msg[1] << 16 | req->msg[2];
-			hns3_update_resp_position(hw, msg_data);
+			hns3_handle_mbx_response(hw, req);
 			break;
 		case HNS3_MBX_LINK_STAT_CHANGE:
 			hns3vf_handle_link_change_event(hw, req);
diff --git a/drivers/net/hns3/hns3_mbx.h b/drivers/net/hns3/hns3_mbx.h
index 45aa4cd..0e9194d 100644
--- a/drivers/net/hns3/hns3_mbx.h
+++ b/drivers/net/hns3/hns3_mbx.h
@@ -83,12 +83,26 @@ enum hns3_mbx_link_fail_subcode {
 #define HNS3_MBX_RING_MAP_BASIC_MSG_NUM	3
 #define HNS3_MBX_RING_NODE_VARIABLE_NUM	3
 
+enum {
+	HNS3_MBX_RESP_MATCHING_SCHEME_OF_ORIGINAL = 0,
+	HNS3_MBX_RESP_MATCHING_SCHEME_OF_MATCH_ID
+};
+
 struct hns3_mbx_resp_status {
 	rte_spinlock_t lock; /* protects against contending sync cmd resp */
+
+	uint8_t matching_scheme;
+
+	/* The following fields used in the matching scheme for original */
 	uint32_t req_msg_data;
 	uint32_t head;
 	uint32_t tail;
 	uint32_t lost;
+
+	/* The following fields used in the matching scheme for match_id */
+	uint16_t match_id;
+	bool received_match_resp;
+
 	int resp_status;
 	uint8_t additional_info[HNS3_MBX_MAX_RESP_DATA_SIZE];
 };
@@ -106,7 +120,8 @@ struct hns3_mbx_vf_to_pf_cmd {
 	uint8_t mbx_need_resp;
 	uint8_t rsv1;
 	uint8_t msg_len;
-	uint8_t rsv2[3];
+	uint8_t rsv2;
+	uint16_t match_id;
 	uint8_t msg[HNS3_MBX_MAX_MSG_SIZE];
 };
 
@@ -114,7 +129,8 @@ struct hns3_mbx_pf_to_vf_cmd {
 	uint8_t dest_vfid;
 	uint8_t rsv[3];
 	uint8_t msg_len;
-	uint8_t rsv1[3];
+	uint8_t rsv1;
+	uint16_t match_id;
 	uint16_t msg[8];
 };
 
-- 
2.7.4

[dpdk-dev] [PATCH 03/12] net/hns3: fix VF may report LSC event in secondary process

[Min Hu (Connor)]

From: Chengwen Feng <fengchengwen@huawei.com>

VF will build two queues (csq: command send queue, crq: command receive
queue) with firmware, the crq may contain the following messages:
1) mailbox response message which was the ack of mailbox sync request.
2) PF's link status change message which may send by PF at anytime;

Currently, any threads in the primary and secondary processes could
send mailbox sync request, so it will need to process the crq messages
in there own thread context.

If the crq hold two messages: a) PF's link status change message, b)
mailbox response message when secondary process deals with the crq
messages, it will lead to report lsc event in secondary process
because it uses the policy of processing all pending messages at once.

We use the following scheme to solve it:
1) threads in secondary process could only process specifics messages
(eg. mailbox response message) in crq, if the message processed, its
opcode will rewrite with zero, then the intr thread in primary process
will not process again.
2) threads other than intr thread in the primary process use the same
processing logic as the threads in secondary process.
3) intr thread in the primary process could process all messages.

Fixes: 76a3836b98c4 ("net/hns3: fix setting default MAC address in bonding of VF")
Fixes: 463e748964f5 ("net/hns3: support mailbox")
Cc: stable@dpdk.org

Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
---
 drivers/net/hns3/hns3_mbx.c | 68 +++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 68 insertions(+)

diff --git a/drivers/net/hns3/hns3_mbx.c b/drivers/net/hns3/hns3_mbx.c
index 8e38649..c5b0856 100644
--- a/drivers/net/hns3/hns3_mbx.c
+++ b/drivers/net/hns3/hns3_mbx.c
@@ -400,6 +400,44 @@ hns3_handle_promisc_info(struct hns3_hw *hw, uint16_t promisc_en)
 	}
 }
 
+static void
+hns3_handle_mbx_msg_out_intr(struct hns3_hw *hw)
+{
+	struct hns3_cmq_ring *crq = &hw->cmq.crq;
+	struct hns3_mbx_pf_to_vf_cmd *req;
+	struct hns3_cmd_desc *desc;
+	uint32_t tail, next_to_use;
+	uint8_t opcode;
+	uint16_t flag;
+
+	tail = hns3_read_dev(hw, HNS3_CMDQ_RX_TAIL_REG);
+	next_to_use = crq->next_to_use;
+	while (next_to_use != tail) {
+		desc = &crq->desc[next_to_use];
+		req = (struct hns3_mbx_pf_to_vf_cmd *)desc->data;
+		opcode = req->msg[0] & 0xff;
+
+		flag = rte_le_to_cpu_16(crq->desc[next_to_use].flag);
+		if (!hns3_get_bit(flag, HNS3_CMDQ_RX_OUTVLD_B))
+			goto scan_next;
+
+		if (crq->desc[next_to_use].opcode == 0)
+			goto scan_next;
+
+		if (opcode == HNS3_MBX_PF_VF_RESP) {
+			hns3_handle_mbx_response(hw, req);
+			/*
+			 * Clear opcode to inform intr thread don't process
+			 * again.
+			 */
+			crq->desc[crq->next_to_use].opcode = 0;
+		}
+
+scan_next:
+		next_to_use = (next_to_use + 1) % hw->cmq.crq.desc_num;
+	}
+}
+
 void
 hns3_dev_handle_mbx_msg(struct hns3_hw *hw)
 {
@@ -411,6 +449,29 @@ hns3_dev_handle_mbx_msg(struct hns3_hw *hw)
 
 	rte_spinlock_lock(&hw->cmq.crq.lock);
 
+	if (rte_eal_process_type() != RTE_PROC_PRIMARY ||
+	    !rte_thread_is_intr()) {
+		/*
+		 * Currently, any threads in the primary and secondary processes
+		 * could send mailbox sync request, so it will need to process
+		 * the crq message (which is the HNS3_MBX_PF_VF_RESP) in there
+		 * own thread context. It may also process other messages
+		 * because it uses the policy of processing all pending messages
+		 * at once.
+		 * But some messages such as HNS3_MBX_PUSH_LINK_STATUS could
+		 * only process within the intr thread in primary process,
+		 * otherwise it may lead to report lsc event in secondary
+		 * process.
+		 * So the threads other than intr thread in primary process
+		 * could only process HNS3_MBX_PF_VF_RESP message, if the
+		 * message processed, its opcode will rewrite with zero, then
+		 * the intr thread in primary process will not process again.
+		 */
+		hns3_handle_mbx_msg_out_intr(hw);
+		rte_spinlock_unlock(&hw->cmq.crq.lock);
+		return;
+	}
+
 	while (!hns3_cmd_crq_empty(hw)) {
 		if (__atomic_load_n(&hw->reset.disable_cmd, __ATOMIC_RELAXED)) {
 			rte_spinlock_unlock(&hw->cmq.crq.lock);
@@ -433,6 +494,13 @@ hns3_dev_handle_mbx_msg(struct hns3_hw *hw)
 			continue;
 		}
 
+		if (desc->opcode == 0) {
+			/* Message already processed by other thread */
+			crq->desc[crq->next_to_use].flag = 0;
+			hns3_mbx_ring_ptr_move_crq(crq);
+			continue;
+		}
+
 		switch (opcode) {
 		case HNS3_MBX_PF_VF_RESP:
 			hns3_handle_mbx_response(hw, req);
-- 
2.7.4

[dpdk-dev] [PATCH 04/12] net/hns3: fix potentially incorrect timing in MBX

[Min Hu (Connor)]

From: Chengchang Tang <tangchengchang@huawei.com>

Currently, when processing MBX messages, the system timestamp is obtained
to determine whether timeout occurs. However, the gettimeofday function
is not monotonically increasing. Therefore, this may lead to incorrect
judgment or difficulty exiting the loop. And actually, in this scenario,
it is not necessary to obatain the timestamp.

This patch deletes the call to the gettimeofday function during MBX
message processing.

Fixes: 463e748964f5 ("net/hns3: support mailbox")
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_mbx.c | 13 +++++--------
 1 file changed, 5 insertions(+), 8 deletions(-)

diff --git a/drivers/net/hns3/hns3_mbx.c b/drivers/net/hns3/hns3_mbx.c
index c5b0856..eb202dd 100644
--- a/drivers/net/hns3/hns3_mbx.c
+++ b/drivers/net/hns3/hns3_mbx.c
@@ -61,13 +61,12 @@ static int
 hns3_get_mbx_resp(struct hns3_hw *hw, uint16_t code, uint16_t subcode,
 		  uint8_t *resp_data, uint16_t resp_len)
 {
-#define HNS3_MAX_RETRY_MS	500
+#define HNS3_MAX_RETRY_US	500000
 #define HNS3_WAIT_RESP_US	100
 	struct hns3_adapter *hns = HNS3_DEV_HW_TO_ADAPTER(hw);
 	struct hns3_mbx_resp_status *mbx_resp;
+	uint32_t wait_time = 0;
 	bool received;
-	uint64_t now;
-	uint64_t end;
 
 	if (resp_len > HNS3_MBX_MAX_RESP_DATA_SIZE) {
 		hns3_err(hw, "VF mbx response len(=%u) exceeds maximum(=%d)",
@@ -75,9 +74,7 @@ hns3_get_mbx_resp(struct hns3_hw *hw, uint16_t code, uint16_t subcode,
 		return -EINVAL;
 	}
 
-	now = get_timeofday_ms();
-	end = now + HNS3_MAX_RETRY_MS;
-	while (now < end) {
+	while (wait_time < HNS3_MAX_RETRY_US) {
 		if (__atomic_load_n(&hw->reset.disable_cmd, __ATOMIC_RELAXED)) {
 			hns3_err(hw, "Don't wait for mbx respone because of "
 				 "disable_cmd");
@@ -103,10 +100,10 @@ hns3_get_mbx_resp(struct hns3_hw *hw, uint16_t code, uint16_t subcode,
 		if (received)
 			break;
 
-		now = get_timeofday_ms();
+		wait_time += HNS3_WAIT_RESP_US;
 	}
 	hw->mbx_resp.req_msg_data = 0;
-	if (now >= end) {
+	if (wait_time >= HNS3_MAX_RETRY_US) {
 		hns3_mbx_proc_timeout(hw, code, subcode);
 		return -ETIME;
 	}
-- 
2.7.4

[dpdk-dev] [PATCH 05/12] net/hns3: fix incorrect use of CMD status enumeration type

[Min Hu (Connor)]

From: Chengchang Tang <tangchengchang@huawei.com>

The type of return value of hns3_cmd_send is int, some function declare
the return value as hns3_cmd_status.

This patch fix the incorrect use of the enum hns3_cmd_status.

Fixes: 737f30e1c3ab ("net/hns3: support command interface with firmware")
Fixes: 02a7b55657b2 ("net/hns3: support Rx interrupt")
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.c    |  2 +-
 drivers/net/hns3/hns3_cmd.h    |  9 +--------
 drivers/net/hns3/hns3_ethdev.c | 12 ++++++------
 3 files changed, 8 insertions(+), 15 deletions(-)

diff --git a/drivers/net/hns3/hns3_cmd.c b/drivers/net/hns3/hns3_cmd.c
index 1d8ef7a..df167f1 100644
--- a/drivers/net/hns3/hns3_cmd.c
+++ b/drivers/net/hns3/hns3_cmd.c
@@ -450,7 +450,7 @@ hns3_build_api_caps(void)
 	return rte_cpu_to_le_32(api_caps);
 }
 
-static enum hns3_cmd_status
+static int
 hns3_cmd_query_firmware_version_and_capability(struct hns3_hw *hw)
 {
 	struct hns3_query_version_cmd *resp;
diff --git a/drivers/net/hns3/hns3_cmd.h b/drivers/net/hns3/hns3_cmd.h
index 9958fde..e88bf4a 100644
--- a/drivers/net/hns3/hns3_cmd.h
+++ b/drivers/net/hns3/hns3_cmd.h
@@ -56,13 +56,6 @@ enum hns3_cmd_return_status {
 	HNS3_CMD_ROH_CHECK_FAIL = 12
 };
 
-enum hns3_cmd_status {
-	HNS3_STATUS_SUCCESS     = 0,
-	HNS3_ERR_CSQ_FULL       = -1,
-	HNS3_ERR_CSQ_TIMEOUT    = -2,
-	HNS3_ERR_CSQ_ERROR      = -3,
-};
-
 struct hns3_misc_vector {
 	uint8_t *addr;
 	int vector_irq;
@@ -72,7 +65,7 @@ struct hns3_cmq {
 	struct hns3_cmq_ring csq;
 	struct hns3_cmq_ring crq;
 	uint16_t tx_timeout;
-	enum hns3_cmd_status last_status;
+	enum hns3_cmd_return_status last_status;
 };
 
 enum hns3_opcode_type {
diff --git a/drivers/net/hns3/hns3_ethdev.c b/drivers/net/hns3/hns3_ethdev.c
index 846e5a2..05ccc2e 100644
--- a/drivers/net/hns3/hns3_ethdev.c
+++ b/drivers/net/hns3/hns3_ethdev.c
@@ -2310,11 +2310,11 @@ hns3_bind_ring_with_vector(struct hns3_hw *hw, uint16_t vector_id, bool en,
 	struct hns3_cmd_desc desc;
 	struct hns3_ctrl_vector_chain_cmd *req =
 		(struct hns3_ctrl_vector_chain_cmd *)desc.data;
-	enum hns3_cmd_status status;
 	enum hns3_opcode_type op;
 	uint16_t tqp_type_and_id = 0;
 	uint16_t type;
 	uint16_t gl;
+	int ret;
 
 	op = en ? HNS3_OPC_ADD_RING_TO_VECTOR : HNS3_OPC_DEL_RING_TO_VECTOR;
 	hns3_cmd_setup_basic_desc(&desc, op, false);
@@ -2337,11 +2337,11 @@ hns3_bind_ring_with_vector(struct hns3_hw *hw, uint16_t vector_id, bool en,
 		       gl);
 	req->tqp_type_and_id[0] = rte_cpu_to_le_16(tqp_type_and_id);
 	req->int_cause_num = 1;
-	status = hns3_cmd_send(hw, &desc, 1);
-	if (status) {
-		hns3_err(hw, "%s TQP %u fail, vector_id is %u, status is %d.",
-			 en ? "Map" : "Unmap", queue_id, vector_id, status);
-		return status;
+	ret = hns3_cmd_send(hw, &desc, 1);
+	if (ret) {
+		hns3_err(hw, "%s TQP %u fail, vector_id = %u, ret = %d.",
+			 en ? "Map" : "Unmap", queue_id, vector_id, ret);
+		return ret;
 	}
 
 	return 0;
-- 
2.7.4

[dpdk-dev] [PATCH 06/12] net/hns3: fix miss verification of whether NEON supported

[Min Hu (Connor)]

From: Chengwen Feng <fengchengwen@huawei.com>

This patch adds verification of whether NEON supported.

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

Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
---
 drivers/net/hns3/hns3_rxtx.c | 26 ++++++++++++++++++++------
 1 file changed, 20 insertions(+), 6 deletions(-)

diff --git a/drivers/net/hns3/hns3_rxtx.c b/drivers/net/hns3/hns3_rxtx.c
index 19adf00..1c22f34 100644
--- a/drivers/net/hns3/hns3_rxtx.c
+++ b/drivers/net/hns3/hns3_rxtx.c
@@ -11,7 +11,7 @@
 #include <rte_io.h>
 #include <rte_net.h>
 #include <rte_malloc.h>
-#if defined(RTE_ARCH_ARM64) && defined(__ARM_FEATURE_SVE)
+#if defined(RTE_ARCH_ARM64)
 #include <rte_cpuflags.h>
 #endif
 
@@ -2766,7 +2766,17 @@ hns3_rx_burst_mode_get(struct rte_eth_dev *dev, __rte_unused uint16_t queue_id,
 }
 
 static bool
-hns3_check_sve_support(void)
+hns3_get_default_vec_support(void)
+{
+#if defined(RTE_ARCH_ARM64)
+	if (rte_cpu_get_flag_enabled(RTE_CPUFLAG_NEON))
+		return true;
+#endif
+	return false;
+}
+
+static bool
+hns3_get_sve_support(void)
 {
 #if defined(RTE_ARCH_ARM64) && defined(__ARM_FEATURE_SVE)
 	if (rte_cpu_get_flag_enabled(RTE_CPUFLAG_SVE))
@@ -2781,9 +2791,11 @@ hns3_get_rx_function(struct rte_eth_dev *dev)
 	struct hns3_adapter *hns = dev->data->dev_private;
 	uint64_t offloads = dev->data->dev_conf.rxmode.offloads;
 	bool vec_allowed, sve_allowed, simple_allowed;
+	bool vec_support;
 
-	vec_allowed = hns3_rx_check_vec_support(dev) == 0;
-	sve_allowed = vec_allowed && hns3_check_sve_support();
+	vec_support = hns3_rx_check_vec_support(dev) == 0;
+	vec_allowed = vec_support && hns3_get_default_vec_support();
+	sve_allowed = vec_support && hns3_get_sve_support();
 	simple_allowed = !dev->data->scattered_rx &&
 			 (offloads & DEV_RX_OFFLOAD_TCP_LRO) == 0;
 
@@ -4170,9 +4182,11 @@ hns3_get_tx_function(struct rte_eth_dev *dev, eth_tx_prep_t *prep)
 {
 	struct hns3_adapter *hns = dev->data->dev_private;
 	bool vec_allowed, sve_allowed, simple_allowed;
+	bool vec_support;
 
-	vec_allowed = hns3_tx_check_vec_support(dev) == 0;
-	sve_allowed = vec_allowed && hns3_check_sve_support();
+	vec_support = hns3_tx_check_vec_support(dev) == 0;
+	vec_allowed = vec_support && hns3_get_default_vec_support();
+	sve_allowed = vec_support && hns3_get_sve_support();
 	simple_allowed = hns3_tx_check_simple_support(dev);
 
 	*prep = NULL;
-- 
2.7.4

[dpdk-dev] [PATCH 07/12] net/hns3: fix missing outer L4 UDP flag for VXLAN packet

[Min Hu (Connor)]

From: Chengwen Feng <fengchengwen@huawei.com>

This patch adds RTE_PTYPE_L4_UDP flag when parsed tunnel vxlan packet.

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

Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
---
 drivers/net/hns3/hns3_rxtx.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/hns3/hns3_rxtx.c b/drivers/net/hns3/hns3_rxtx.c
index 1c22f34..3d94f72 100644
--- a/drivers/net/hns3/hns3_rxtx.c
+++ b/drivers/net/hns3/hns3_rxtx.c
@@ -2051,7 +2051,7 @@ hns3_init_tunnel_ptype_tbl(struct hns3_ptype_table *tbl)
 	tbl->ol3table[5] = RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV6_EXT;
 
 	tbl->ol4table[0] = RTE_PTYPE_UNKNOWN;
-	tbl->ol4table[1] = RTE_PTYPE_TUNNEL_VXLAN;
+	tbl->ol4table[1] = RTE_PTYPE_L4_UDP | RTE_PTYPE_TUNNEL_VXLAN;
 	tbl->ol4table[2] = RTE_PTYPE_TUNNEL_NVGRE;
 }
 
-- 
2.7.4

[dpdk-dev] [PATCH 08/12] net/hns3: add reporting TUNNEL GRE packet type

[Min Hu (Connor)]

From: Chengwen Feng <fengchengwen@huawei.com>

This patch supports reporting TUNNEL GRE packet type when rxd advanced
layout enabled.

Fixes: fb5e90694022 ("net/hns3: support Rx descriptor advanced layout")

Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
---
 drivers/net/hns3/hns3_rxtx.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/net/hns3/hns3_rxtx.c b/drivers/net/hns3/hns3_rxtx.c
index 3d94f72..87d2df7 100644
--- a/drivers/net/hns3/hns3_rxtx.c
+++ b/drivers/net/hns3/hns3_rxtx.c
@@ -2074,8 +2074,8 @@ hns3_init_adv_layout_ptype(struct hns3_ptype_table *tbl)
 		    RTE_PTYPE_L4_UDP;
 	ptype[20] = RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV4_EXT_UNKNOWN |
 		    RTE_PTYPE_L4_TCP;
-	/* The next ptype is GRE over IPv4 */
-	ptype[21] = RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV4_EXT_UNKNOWN;
+	ptype[21] = RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV4_EXT_UNKNOWN |
+		    RTE_PTYPE_TUNNEL_GRE;
 	ptype[22] = RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV4_EXT_UNKNOWN |
 		    RTE_PTYPE_L4_SCTP;
 	ptype[23] = RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV4_EXT_UNKNOWN |
@@ -2162,8 +2162,8 @@ hns3_init_adv_layout_ptype(struct hns3_ptype_table *tbl)
 		     RTE_PTYPE_L4_UDP;
 	ptype[114] = RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV6_EXT_UNKNOWN |
 		     RTE_PTYPE_L4_TCP;
-	/* The next ptype is GRE over IPv6 */
-	ptype[115] = RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV6_EXT_UNKNOWN;
+	ptype[115] = RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV6_EXT_UNKNOWN |
+		     RTE_PTYPE_TUNNEL_GRE;
 	ptype[116] = RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV6_EXT_UNKNOWN |
 		     RTE_PTYPE_L4_SCTP;
 	ptype[117] = RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV6_EXT_UNKNOWN |
-- 
2.7.4

[dpdk-dev] [PATCH 09/12] net/hns3: fix PTP caps report

[Min Hu (Connor)]

From: Chengwen Feng <fengchengwen@huawei.com>

The PTP depends on special packet type reported by hardware which
enabled rxd advanced layout, so if the hardware doesn't support rxd
advanced layout, driver should ignore the PTP capability.

Fixes: 438752358158 ("net/hns3: get device capability from firmware")
Cc: stable@dpdk.org

Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
---
 drivers/net/hns3/hns3_cmd.c | 15 +++++++++++++--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/drivers/net/hns3/hns3_cmd.c b/drivers/net/hns3/hns3_cmd.c
index df167f1..b571999 100644
--- a/drivers/net/hns3/hns3_cmd.c
+++ b/drivers/net/hns3/hns3_cmd.c
@@ -422,8 +422,19 @@ hns3_parse_capability(struct hns3_hw *hw,
 	if (hns3_get_bit(caps, HNS3_CAPS_FD_QUEUE_REGION_B))
 		hns3_set_bit(hw->capability, HNS3_DEV_SUPPORT_FD_QUEUE_REGION_B,
 			     1);
-	if (hns3_get_bit(caps, HNS3_CAPS_PTP_B))
-		hns3_set_bit(hw->capability, HNS3_DEV_SUPPORT_PTP_B, 1);
+	if (hns3_get_bit(caps, HNS3_CAPS_PTP_B)) {
+		/*
+		 * PTP depends on special packet type reported by hardware which
+		 * enabled rxd advanced layout, so if the hardware doesn't
+		 * support rxd advanced layout, driver should ignore the PTP
+		 * capability.
+		 */
+		if (hns3_get_bit(caps, HNS3_CAPS_RXD_ADV_LAYOUT_B))
+			hns3_set_bit(hw->capability, HNS3_DEV_SUPPORT_PTP_B, 1);
+		else
+			hns3_warn(hw, "ignore PTP capability due to lack of "
+				  "rxd advanced layout capability.");
+	}
 	if (hns3_get_bit(caps, HNS3_CAPS_TX_PUSH_B))
 		hns3_set_bit(hw->capability, HNS3_DEV_SUPPORT_TX_PUSH_B, 1);
 	if (hns3_get_bit(caps, HNS3_CAPS_PHY_IMP_B))
-- 
2.7.4

[dpdk-dev] [PATCH 10/12] net/hns3: rename Rx burst API

[Min Hu (Connor)]

From: Chengwen Feng <fengchengwen@huawei.com>

Currently, user could use runtime config "rx_func_hint=simple" to
select the hns3_recv_pkts API, but the API's name get from
rte_eth_rx_burst_mode_get is "Scalar" which has not reflected "simple".

So this patch renames hns3_recv_pkts to hns3_recv_pkts_simple, and
also change it's name which gets from rte_eth_rx_burst_mode_get to
"Scalar Simple" to maintain conceptual consistency.

Also changes the hns3_recv_scattered_pkts API's name which gets from
rte_eth_rx_burst_mode_get to "Scalar".

Fixes: 521ab3e93361 ("net/hns3: add simple Rx path")
Cc: stable@dpdk.org

Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
---
 drivers/net/hns3/hns3_rxtx.c | 20 +++++++++++---------
 drivers/net/hns3/hns3_rxtx.h |  4 ++--
 2 files changed, 13 insertions(+), 11 deletions(-)

diff --git a/drivers/net/hns3/hns3_rxtx.c b/drivers/net/hns3/hns3_rxtx.c
index 87d2df7..c524d5a 100644
--- a/drivers/net/hns3/hns3_rxtx.c
+++ b/drivers/net/hns3/hns3_rxtx.c
@@ -1992,7 +1992,7 @@ hns3_dev_supported_ptypes_get(struct rte_eth_dev *dev)
 		RTE_PTYPE_UNKNOWN
 	};
 
-	if (dev->rx_pkt_burst == hns3_recv_pkts ||
+	if (dev->rx_pkt_burst == hns3_recv_pkts_simple ||
 	    dev->rx_pkt_burst == hns3_recv_scattered_pkts ||
 	    dev->rx_pkt_burst == hns3_recv_pkts_vec ||
 	    dev->rx_pkt_burst == hns3_recv_pkts_vec_sve)
@@ -2360,7 +2360,9 @@ hns3_rx_ptp_timestamp_handle(struct hns3_rx_queue *rxq, struct rte_mbuf *mbuf,
 }
 
 uint16_t
-hns3_recv_pkts(void *rx_queue, struct rte_mbuf **rx_pkts, uint16_t nb_pkts)
+hns3_recv_pkts_simple(void *rx_queue,
+		      struct rte_mbuf **rx_pkts,
+		      uint16_t nb_pkts)
 {
 	volatile struct hns3_desc *rx_ring;  /* RX ring (desc) */
 	volatile struct hns3_desc *rxdp;     /* pointer of the current desc */
@@ -2743,10 +2745,10 @@ hns3_rx_burst_mode_get(struct rte_eth_dev *dev, __rte_unused uint16_t queue_id,
 		eth_rx_burst_t pkt_burst;
 		const char *info;
 	} burst_infos[] = {
-		{ hns3_recv_pkts,		"Scalar" },
-		{ hns3_recv_scattered_pkts,	"Scalar Scattered" },
-		{ hns3_recv_pkts_vec,		"Vector Neon" },
-		{ hns3_recv_pkts_vec_sve,	"Vector Sve" },
+		{ hns3_recv_pkts_simple,	"Scalar Simple" },
+		{ hns3_recv_scattered_pkts,	"Scalar"        },
+		{ hns3_recv_pkts_vec,		"Vector Neon"   },
+		{ hns3_recv_pkts_vec_sve,	"Vector Sve"    },
 	};
 
 	eth_rx_burst_t pkt_burst = dev->rx_pkt_burst;
@@ -2804,14 +2806,14 @@ hns3_get_rx_function(struct rte_eth_dev *dev)
 	if (hns->rx_func_hint == HNS3_IO_FUNC_HINT_SVE && sve_allowed)
 		return hns3_recv_pkts_vec_sve;
 	if (hns->rx_func_hint == HNS3_IO_FUNC_HINT_SIMPLE && simple_allowed)
-		return hns3_recv_pkts;
+		return hns3_recv_pkts_simple;
 	if (hns->rx_func_hint == HNS3_IO_FUNC_HINT_COMMON)
 		return hns3_recv_scattered_pkts;
 
 	if (vec_allowed)
 		return hns3_recv_pkts_vec;
 	if (simple_allowed)
-		return hns3_recv_pkts;
+		return hns3_recv_pkts_simple;
 
 	return hns3_recv_scattered_pkts;
 }
@@ -4488,7 +4490,7 @@ hns3_dev_rx_descriptor_status(void *rx_queue, uint16_t offset)
 	rxdp = &rxq->rx_ring[desc_id];
 	bd_base_info = rte_le_to_cpu_32(rxdp->rx.bd_base_info);
 	dev = &rte_eth_devices[rxq->port_id];
-	if (dev->rx_pkt_burst == hns3_recv_pkts ||
+	if (dev->rx_pkt_burst == hns3_recv_pkts_simple ||
 	    dev->rx_pkt_burst == hns3_recv_scattered_pkts) {
 		if (offset >= rxq->nb_rx_desc - rxq->rx_free_hold)
 			return RTE_ETH_RX_DESC_UNAVAIL;
diff --git a/drivers/net/hns3/hns3_rxtx.h b/drivers/net/hns3/hns3_rxtx.h
index 10a6c64..ad85d0d 100644
--- a/drivers/net/hns3/hns3_rxtx.h
+++ b/drivers/net/hns3/hns3_rxtx.h
@@ -683,8 +683,8 @@ int hns3_dev_rx_queue_start(struct rte_eth_dev *dev, uint16_t rx_queue_id);
 int hns3_dev_rx_queue_stop(struct rte_eth_dev *dev, uint16_t rx_queue_id);
 int hns3_dev_tx_queue_start(struct rte_eth_dev *dev, uint16_t tx_queue_id);
 int hns3_dev_tx_queue_stop(struct rte_eth_dev *dev, uint16_t tx_queue_id);
-uint16_t hns3_recv_pkts(void *rx_queue, struct rte_mbuf **rx_pkts,
-			uint16_t nb_pkts);
+uint16_t hns3_recv_pkts_simple(void *rx_queue, struct rte_mbuf **rx_pkts,
+				uint16_t nb_pkts);
 uint16_t hns3_recv_scattered_pkts(void *rx_queue, struct rte_mbuf **rx_pkts,
 				  uint16_t nb_pkts);
 uint16_t hns3_recv_pkts_vec(void *rx_queue, struct rte_mbuf **rx_pkts,
-- 
2.7.4

[dpdk-dev] [PATCH 11/12] net/hns3: add supported ptypes list for RXD advanced layout

[Min Hu (Connor)]

From: Chengwen Feng <fengchengwen@huawei.com>

Kunpeng 930 supports RXD advanced layout. If enabled the layout, the
hardware will report packet type by 8-bit PTYPE filed in the Rx
descriptor, and the supported ptypes are different from original
scheme. So this patch adds supported list for RXD advanced layout.

Fixes: fb5e90694022 ("net/hns3: support Rx descriptor advanced layout")

Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
---
 drivers/net/hns3/hns3_rxtx.c | 37 +++++++++++++++++++++++++++++++++++--
 1 file changed, 35 insertions(+), 2 deletions(-)

diff --git a/drivers/net/hns3/hns3_rxtx.c b/drivers/net/hns3/hns3_rxtx.c
index c524d5a..59fb974 100644
--- a/drivers/net/hns3/hns3_rxtx.c
+++ b/drivers/net/hns3/hns3_rxtx.c
@@ -1991,12 +1991,45 @@ hns3_dev_supported_ptypes_get(struct rte_eth_dev *dev)
 		RTE_PTYPE_TUNNEL_NVGRE,
 		RTE_PTYPE_UNKNOWN
 	};
+	static const uint32_t adv_layout_ptypes[] = {
+		RTE_PTYPE_L2_ETHER,
+		RTE_PTYPE_L2_ETHER_TIMESYNC,
+		RTE_PTYPE_L2_ETHER_LLDP,
+		RTE_PTYPE_L2_ETHER_ARP,
+		RTE_PTYPE_L3_IPV4_EXT_UNKNOWN,
+		RTE_PTYPE_L3_IPV6_EXT_UNKNOWN,
+		RTE_PTYPE_L4_FRAG,
+		RTE_PTYPE_L4_NONFRAG,
+		RTE_PTYPE_L4_UDP,
+		RTE_PTYPE_L4_TCP,
+		RTE_PTYPE_L4_SCTP,
+		RTE_PTYPE_L4_IGMP,
+		RTE_PTYPE_L4_ICMP,
+		RTE_PTYPE_TUNNEL_GRE,
+		RTE_PTYPE_TUNNEL_GRENAT,
+		RTE_PTYPE_INNER_L2_ETHER,
+		RTE_PTYPE_INNER_L3_IPV4_EXT_UNKNOWN,
+		RTE_PTYPE_INNER_L3_IPV6_EXT_UNKNOWN,
+		RTE_PTYPE_INNER_L4_FRAG,
+		RTE_PTYPE_INNER_L4_ICMP,
+		RTE_PTYPE_INNER_L4_NONFRAG,
+		RTE_PTYPE_INNER_L4_UDP,
+		RTE_PTYPE_INNER_L4_TCP,
+		RTE_PTYPE_INNER_L4_SCTP,
+		RTE_PTYPE_INNER_L4_ICMP,
+		RTE_PTYPE_UNKNOWN
+	};
+	struct hns3_hw *hw = HNS3_DEV_PRIVATE_TO_HW(dev->data->dev_private);
 
 	if (dev->rx_pkt_burst == hns3_recv_pkts_simple ||
 	    dev->rx_pkt_burst == hns3_recv_scattered_pkts ||
 	    dev->rx_pkt_burst == hns3_recv_pkts_vec ||
-	    dev->rx_pkt_burst == hns3_recv_pkts_vec_sve)
-		return ptypes;
+	    dev->rx_pkt_burst == hns3_recv_pkts_vec_sve) {
+		if (hns3_dev_rxd_adv_layout_supported(hw))
+			return adv_layout_ptypes;
+		else
+			return ptypes;
+	}
 
 	return NULL;
 }
-- 
2.7.4

[dpdk-dev] [PATCH 12/12] net/hns3: remove VLAN/QINQ ptypes from support list

[Min Hu (Connor)]

From: Chengwen Feng <fengchengwen@huawei.com>

In the previous patch, driver will calculate packet type by ignoring
VLAN information because the packet type may calculate error when
exist VLAN and VLAN strip.

So here remove the following ptypes from support list:
1) RTE_PTYPE_L2_ETHER_VLAN
2) RTE_PTYPE_L2_ETHER_QINQ
3) RTE_PTYPE_INNER_L2_ETHER_VLAN
4) RTE_PTYPE_INNER_L2_ETHER_QINQ

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

Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
---
 drivers/net/hns3/hns3_rxtx.c | 4 ----
 1 file changed, 4 deletions(-)

diff --git a/drivers/net/hns3/hns3_rxtx.c b/drivers/net/hns3/hns3_rxtx.c
index 59fb974..ac1bab7 100644
--- a/drivers/net/hns3/hns3_rxtx.c
+++ b/drivers/net/hns3/hns3_rxtx.c
@@ -1962,8 +1962,6 @@ hns3_dev_supported_ptypes_get(struct rte_eth_dev *dev)
 {
 	static const uint32_t ptypes[] = {
 		RTE_PTYPE_L2_ETHER,
-		RTE_PTYPE_L2_ETHER_VLAN,
-		RTE_PTYPE_L2_ETHER_QINQ,
 		RTE_PTYPE_L2_ETHER_LLDP,
 		RTE_PTYPE_L2_ETHER_ARP,
 		RTE_PTYPE_L3_IPV4,
@@ -1977,8 +1975,6 @@ hns3_dev_supported_ptypes_get(struct rte_eth_dev *dev)
 		RTE_PTYPE_L4_UDP,
 		RTE_PTYPE_TUNNEL_GRE,
 		RTE_PTYPE_INNER_L2_ETHER,
-		RTE_PTYPE_INNER_L2_ETHER_VLAN,
-		RTE_PTYPE_INNER_L2_ETHER_QINQ,
 		RTE_PTYPE_INNER_L3_IPV4,
 		RTE_PTYPE_INNER_L3_IPV6,
 		RTE_PTYPE_INNER_L3_IPV4_EXT,
-- 
2.7.4

Re: [dpdk-dev] [PATCH 10/12] net/hns3: rename Rx burst API

[Ferruh Yigit]

On 4/13/2021 12:50 PM, Min Hu (Connor) wrote:
> From: Chengwen Feng <fengchengwen@huawei.com>
> 
> Currently, user could use runtime config "rx_func_hint=simple" to
> select the hns3_recv_pkts API, but the API's name get from
> rte_eth_rx_burst_mode_get is "Scalar" which has not reflected "simple".
> 
> So this patch renames hns3_recv_pkts to hns3_recv_pkts_simple, and
> also change it's name which gets from rte_eth_rx_burst_mode_get to
> "Scalar Simple" to maintain conceptual consistency.
> 
> Also changes the hns3_recv_scattered_pkts API's name which gets from
> rte_eth_rx_burst_mode_get to "Scalar".
> 
> Fixes: 521ab3e93361 ("net/hns3: add simple Rx path")
> Cc: stable@dpdk.org
> 
> Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
> Signed-off-by: Min Hu (Connor) <humin29@huawei.com>

<...>

> @@ -2743,10 +2745,10 @@ hns3_rx_burst_mode_get(struct rte_eth_dev *dev, __rte_unused uint16_t queue_id,
>   		eth_rx_burst_t pkt_burst;
>   		const char *info;
>   	} burst_infos[] = {
> -		{ hns3_recv_pkts,		"Scalar" },
> -		{ hns3_recv_scattered_pkts,	"Scalar Scattered" },
> -		{ hns3_recv_pkts_vec,		"Vector Neon" },
> -		{ hns3_recv_pkts_vec_sve,	"Vector Sve" },
> +		{ hns3_recv_pkts_simple,	"Scalar Simple" },
> +		{ hns3_recv_scattered_pkts,	"Scalar"        },
> +		{ hns3_recv_pkts_vec,		"Vector Neon"   },
> +		{ hns3_recv_pkts_vec_sve,	"Vector Sve"    },

No concern on the burst function rename, that is driver internal, but related to 
the above change, I think new value "Scalar Simple" is not clear, what does 
'Simple' mean?
At least previously "Scalar Scattered" vs "Scalar" was more clear, one can 
easily say difference is scattered Rx support, but with "Scalar" vs "Scalar 
Simple" the difference is not clear.

Re: [dpdk-dev] [PATCH 00/12] Bugfix for hns3 PMD

[Ferruh Yigit]

On 4/13/2021 12:49 PM, Min Hu (Connor) wrote:
> This set of patches contains 12 bugfixes for hns3 PMD.
> 
> Chengchang Tang (2):
>    net/hns3: fix potentially incorrect timing in MBX
>    net/hns3: fix incorrect use of CMD status enumeration type
> 
> Chengwen Feng (10):
>    net/hns3: delete mailbox arq ring
>    net/hns3: fix possible mismatches response of mailbox
>    net/hns3: fix VF may report LSC event in secondary process
>    net/hns3: fix miss verification of whether NEON supported
>    net/hns3: fix missing outer L4 UDP flag for VXLAN packet
>    net/hns3: add reporting TUNNEL GRE packet type
>    net/hns3: fix PTP caps report
>    net/hns3: rename Rx burst API
>    net/hns3: add supported ptypes list for RXD advanced layout
>    net/hns3: remove VLAN/QINQ ptypes from support list
> 

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

Patch 10/12 has no dependency in the set, so it can be discussed/updated separately.

[dpdk-dev] [PATCH v2] net/hns3: rename Rx burst API

[Min Hu (Connor)]

From: Chengwen Feng <fengchengwen@huawei.com>

Currently, user could use runtime config "rx_func_hint=simple" to
select the hns3_recv_pkts API, but the API's name get from
rte_eth_rx_burst_mode_get is "Scalar" which has not reflected "simple".

So this patch renames hns3_recv_pkts to hns3_recv_pkts_simple, and
also change it's name which gets from rte_eth_rx_burst_mode_get to
"Scalar Simple" to maintain conceptual consistency.

Also changes the hns3_recv_scattered_pkts API's name which gets from
rte_eth_rx_burst_mode_get to "Scalar".

Fixes: 521ab3e93361 ("net/hns3: add simple Rx path")
Cc: stable@dpdk.org

Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
---
v2:
* revert "Scalar Scattered".
---
 drivers/net/hns3/hns3_rxtx.c | 18 ++++++++++--------
 drivers/net/hns3/hns3_rxtx.h |  4 ++--
 2 files changed, 12 insertions(+), 10 deletions(-)

diff --git a/drivers/net/hns3/hns3_rxtx.c b/drivers/net/hns3/hns3_rxtx.c
index 19adf00..bc087fc 100644
--- a/drivers/net/hns3/hns3_rxtx.c
+++ b/drivers/net/hns3/hns3_rxtx.c
@@ -1992,7 +1992,7 @@ hns3_dev_supported_ptypes_get(struct rte_eth_dev *dev)
 		RTE_PTYPE_UNKNOWN
 	};
 
-	if (dev->rx_pkt_burst == hns3_recv_pkts ||
+	if (dev->rx_pkt_burst == hns3_recv_pkts_simple ||
 	    dev->rx_pkt_burst == hns3_recv_scattered_pkts ||
 	    dev->rx_pkt_burst == hns3_recv_pkts_vec ||
 	    dev->rx_pkt_burst == hns3_recv_pkts_vec_sve)
@@ -2360,7 +2360,9 @@ hns3_rx_ptp_timestamp_handle(struct hns3_rx_queue *rxq, struct rte_mbuf *mbuf,
 }
 
 uint16_t
-hns3_recv_pkts(void *rx_queue, struct rte_mbuf **rx_pkts, uint16_t nb_pkts)
+hns3_recv_pkts_simple(void *rx_queue,
+		      struct rte_mbuf **rx_pkts,
+		      uint16_t nb_pkts)
 {
 	volatile struct hns3_desc *rx_ring;  /* RX ring (desc) */
 	volatile struct hns3_desc *rxdp;     /* pointer of the current desc */
@@ -2743,10 +2745,10 @@ hns3_rx_burst_mode_get(struct rte_eth_dev *dev, __rte_unused uint16_t queue_id,
 		eth_rx_burst_t pkt_burst;
 		const char *info;
 	} burst_infos[] = {
-		{ hns3_recv_pkts,		"Scalar" },
+		{ hns3_recv_pkts_simple,	"Scalar Simple" },
 		{ hns3_recv_scattered_pkts,	"Scalar Scattered" },
-		{ hns3_recv_pkts_vec,		"Vector Neon" },
-		{ hns3_recv_pkts_vec_sve,	"Vector Sve" },
+		{ hns3_recv_pkts_vec,		"Vector Neon"   },
+		{ hns3_recv_pkts_vec_sve,	"Vector Sve"    },
 	};
 
 	eth_rx_burst_t pkt_burst = dev->rx_pkt_burst;
@@ -2792,14 +2794,14 @@ hns3_get_rx_function(struct rte_eth_dev *dev)
 	if (hns->rx_func_hint == HNS3_IO_FUNC_HINT_SVE && sve_allowed)
 		return hns3_recv_pkts_vec_sve;
 	if (hns->rx_func_hint == HNS3_IO_FUNC_HINT_SIMPLE && simple_allowed)
-		return hns3_recv_pkts;
+		return hns3_recv_pkts_simple;
 	if (hns->rx_func_hint == HNS3_IO_FUNC_HINT_COMMON)
 		return hns3_recv_scattered_pkts;
 
 	if (vec_allowed)
 		return hns3_recv_pkts_vec;
 	if (simple_allowed)
-		return hns3_recv_pkts;
+		return hns3_recv_pkts_simple;
 
 	return hns3_recv_scattered_pkts;
 }
@@ -4474,7 +4476,7 @@ hns3_dev_rx_descriptor_status(void *rx_queue, uint16_t offset)
 	rxdp = &rxq->rx_ring[desc_id];
 	bd_base_info = rte_le_to_cpu_32(rxdp->rx.bd_base_info);
 	dev = &rte_eth_devices[rxq->port_id];
-	if (dev->rx_pkt_burst == hns3_recv_pkts ||
+	if (dev->rx_pkt_burst == hns3_recv_pkts_simple ||
 	    dev->rx_pkt_burst == hns3_recv_scattered_pkts) {
 		if (offset >= rxq->nb_rx_desc - rxq->rx_free_hold)
 			return RTE_ETH_RX_DESC_UNAVAIL;
diff --git a/drivers/net/hns3/hns3_rxtx.h b/drivers/net/hns3/hns3_rxtx.h
index 10a6c64..ad85d0d 100644
--- a/drivers/net/hns3/hns3_rxtx.h
+++ b/drivers/net/hns3/hns3_rxtx.h
@@ -683,8 +683,8 @@ int hns3_dev_rx_queue_start(struct rte_eth_dev *dev, uint16_t rx_queue_id);
 int hns3_dev_rx_queue_stop(struct rte_eth_dev *dev, uint16_t rx_queue_id);
 int hns3_dev_tx_queue_start(struct rte_eth_dev *dev, uint16_t tx_queue_id);
 int hns3_dev_tx_queue_stop(struct rte_eth_dev *dev, uint16_t tx_queue_id);
-uint16_t hns3_recv_pkts(void *rx_queue, struct rte_mbuf **rx_pkts,
-			uint16_t nb_pkts);
+uint16_t hns3_recv_pkts_simple(void *rx_queue, struct rte_mbuf **rx_pkts,
+				uint16_t nb_pkts);
 uint16_t hns3_recv_scattered_pkts(void *rx_queue, struct rte_mbuf **rx_pkts,
 				  uint16_t nb_pkts);
 uint16_t hns3_recv_pkts_vec(void *rx_queue, struct rte_mbuf **rx_pkts,
-- 
2.7.4

Re: [dpdk-dev] [PATCH 10/12] net/hns3: rename Rx burst API

[Min Hu (Connor)]

在 2021/4/15 1:41, Ferruh Yigit 写道:
> On 4/13/2021 12:50 PM, Min Hu (Connor) wrote:
>> From: Chengwen Feng <fengchengwen@huawei.com>
>>
>> Currently, user could use runtime config "rx_func_hint=simple" to
>> select the hns3_recv_pkts API, but the API's name get from
>> rte_eth_rx_burst_mode_get is "Scalar" which has not reflected "simple".
>>
>> So this patch renames hns3_recv_pkts to hns3_recv_pkts_simple, and
>> also change it's name which gets from rte_eth_rx_burst_mode_get to
>> "Scalar Simple" to maintain conceptual consistency.
>>
>> Also changes the hns3_recv_scattered_pkts API's name which gets from
>> rte_eth_rx_burst_mode_get to "Scalar".
>>
>> Fixes: 521ab3e93361 ("net/hns3: add simple Rx path")
>> Cc: stable@dpdk.org
>>
>> Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
>> Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
> 
> <...>
> 
>> @@ -2743,10 +2745,10 @@ hns3_rx_burst_mode_get(struct rte_eth_dev 
>> *dev, __rte_unused uint16_t queue_id,
>>           eth_rx_burst_t pkt_burst;
>>           const char *info;
>>       } burst_infos[] = {
>> -        { hns3_recv_pkts,        "Scalar" },
>> -        { hns3_recv_scattered_pkts,    "Scalar Scattered" },
>> -        { hns3_recv_pkts_vec,        "Vector Neon" },
>> -        { hns3_recv_pkts_vec_sve,    "Vector Sve" },
>> +        { hns3_recv_pkts_simple,    "Scalar Simple" },
>> +        { hns3_recv_scattered_pkts,    "Scalar"        },
>> +        { hns3_recv_pkts_vec,        "Vector Neon"   },
>> +        { hns3_recv_pkts_vec_sve,    "Vector Sve"    },
> 
> No concern on the burst function rename, that is driver internal, but 
> related to the above change, I think new value "Scalar Simple" is not 
> clear, what does 'Simple' mean?
> At least previously "Scalar Scattered" vs "Scalar" was more clear, one 
> can easily say difference is scattered Rx support, but with "Scalar" vs 
> "Scalar Simple" the difference is not clear.
> 
Agreed to retain the hns3_recv_scattered_pkts name "Scalar Scattered",
but suggests changing the hns3_recv_pkts_simple name to "Scalar Simple"
for the following reasons:
1. Currently, the transmit and receive algorithms implemented in C language
only process single-BD algorithms. The Rx direction is Scalar, while the
Tx direction is Scalar Simple. The two do not correspond with each other.
2. The algorithm name selected by using rx_func_hint=simple does not contain
simple. The DPDK user may be confused.

BTW, v2 has been sent, please check it out, thanks.
> .

Re: [dpdk-dev] [PATCH 10/12] net/hns3: rename Rx burst API

[Ferruh Yigit]

On 4/15/2021 2:58 AM, Min Hu (Connor) wrote:
> 
> 
> 在 2021/4/15 1:41, Ferruh Yigit 写道:
>> On 4/13/2021 12:50 PM, Min Hu (Connor) wrote:
>>> From: Chengwen Feng <fengchengwen@huawei.com>
>>>
>>> Currently, user could use runtime config "rx_func_hint=simple" to
>>> select the hns3_recv_pkts API, but the API's name get from
>>> rte_eth_rx_burst_mode_get is "Scalar" which has not reflected "simple".
>>>
>>> So this patch renames hns3_recv_pkts to hns3_recv_pkts_simple, and
>>> also change it's name which gets from rte_eth_rx_burst_mode_get to
>>> "Scalar Simple" to maintain conceptual consistency.
>>>
>>> Also changes the hns3_recv_scattered_pkts API's name which gets from
>>> rte_eth_rx_burst_mode_get to "Scalar".
>>>
>>> Fixes: 521ab3e93361 ("net/hns3: add simple Rx path")
>>> Cc: stable@dpdk.org
>>>
>>> Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
>>> Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
>>
>> <...>
>>
>>> @@ -2743,10 +2745,10 @@ hns3_rx_burst_mode_get(struct rte_eth_dev *dev, 
>>> __rte_unused uint16_t queue_id,
>>>           eth_rx_burst_t pkt_burst;
>>>           const char *info;
>>>       } burst_infos[] = {
>>> -        { hns3_recv_pkts,        "Scalar" },
>>> -        { hns3_recv_scattered_pkts,    "Scalar Scattered" },
>>> -        { hns3_recv_pkts_vec,        "Vector Neon" },
>>> -        { hns3_recv_pkts_vec_sve,    "Vector Sve" },
>>> +        { hns3_recv_pkts_simple,    "Scalar Simple" },
>>> +        { hns3_recv_scattered_pkts,    "Scalar"        },
>>> +        { hns3_recv_pkts_vec,        "Vector Neon"   },
>>> +        { hns3_recv_pkts_vec_sve,    "Vector Sve"    },
>>
>> No concern on the burst function rename, that is driver internal, but related 
>> to the above change, I think new value "Scalar Simple" is not clear, what does 
>> 'Simple' mean?
>> At least previously "Scalar Scattered" vs "Scalar" was more clear, one can 
>> easily say difference is scattered Rx support, but with "Scalar" vs "Scalar 
>> Simple" the difference is not clear.
>>
> Agreed to retain the hns3_recv_scattered_pkts name "Scalar Scattered",
> but suggests changing the hns3_recv_pkts_simple name to "Scalar Simple"
> for the following reasons:
> 1. Currently, the transmit and receive algorithms implemented in C language
> only process single-BD algorithms. The Rx direction is Scalar, while the
> Tx direction is Scalar Simple. The two do not correspond with each other.
> 2. The algorithm name selected by using rx_func_hint=simple does not contain
> simple. The DPDK user may be confused.
> 

ack

> BTW, v2 has been sent, please check it out, thanks.
>> .

[dpdk-dev] [PATCH v3] net/hns3: rename Rx burst API

[Min Hu (Connor)]

From: Chengwen Feng <fengchengwen@huawei.com>

Currently, user could use runtime config "rx_func_hint=simple" to
select the hns3_recv_pkts API, but the API's name get from
rte_eth_rx_burst_mode_get is "Scalar" which has not reflected "simple".

So this patch renames hns3_recv_pkts to hns3_recv_pkts_simple, and
also change it's name which gets from rte_eth_rx_burst_mode_get to
"Scalar Simple" to maintain conceptual consistency.

Fixes: 521ab3e93361 ("net/hns3: add simple Rx path")
Cc: stable@dpdk.org

Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
Acked-by: Ferruh Yigit <ferruh.yigit@intel.com>
---
v3:
* Modify commit info.

v2:
* Revert "Scalar Scattered".
---
 drivers/net/hns3/hns3_rxtx.c | 18 ++++++++++--------
 drivers/net/hns3/hns3_rxtx.h |  4 ++--
 2 files changed, 12 insertions(+), 10 deletions(-)

diff --git a/drivers/net/hns3/hns3_rxtx.c b/drivers/net/hns3/hns3_rxtx.c
index ce5d852..bc107d0 100644
--- a/drivers/net/hns3/hns3_rxtx.c
+++ b/drivers/net/hns3/hns3_rxtx.c
@@ -1991,7 +1991,7 @@ hns3_dev_supported_ptypes_get(struct rte_eth_dev *dev)
 		RTE_PTYPE_UNKNOWN
 	};
 
-	if (dev->rx_pkt_burst == hns3_recv_pkts ||
+	if (dev->rx_pkt_burst == hns3_recv_pkts_simple ||
 	    dev->rx_pkt_burst == hns3_recv_scattered_pkts ||
 	    dev->rx_pkt_burst == hns3_recv_pkts_vec ||
 	    dev->rx_pkt_burst == hns3_recv_pkts_vec_sve)
@@ -2366,7 +2366,9 @@ hns3_rx_alloc_buffer(struct hns3_rx_queue *rxq)
 }
 
 uint16_t
-hns3_recv_pkts(void *rx_queue, struct rte_mbuf **rx_pkts, uint16_t nb_pkts)
+hns3_recv_pkts_simple(void *rx_queue,
+		      struct rte_mbuf **rx_pkts,
+		      uint16_t nb_pkts)
 {
 	volatile struct hns3_desc *rx_ring;  /* RX ring (desc) */
 	volatile struct hns3_desc *rxdp;     /* pointer of the current desc */
@@ -2742,10 +2744,10 @@ hns3_rx_burst_mode_get(struct rte_eth_dev *dev, __rte_unused uint16_t queue_id,
 		eth_rx_burst_t pkt_burst;
 		const char *info;
 	} burst_infos[] = {
-		{ hns3_recv_pkts,		"Scalar" },
+		{ hns3_recv_pkts_simple,	"Scalar Simple" },
 		{ hns3_recv_scattered_pkts,	"Scalar Scattered" },
-		{ hns3_recv_pkts_vec,		"Vector Neon" },
-		{ hns3_recv_pkts_vec_sve,	"Vector Sve" },
+		{ hns3_recv_pkts_vec,		"Vector Neon"   },
+		{ hns3_recv_pkts_vec_sve,	"Vector Sve"    },
 	};
 
 	eth_rx_burst_t pkt_burst = dev->rx_pkt_burst;
@@ -2792,14 +2794,14 @@ hns3_get_rx_function(struct rte_eth_dev *dev)
 	if (hns->rx_func_hint == HNS3_IO_FUNC_HINT_SVE && sve_allowed)
 		return hns3_recv_pkts_vec_sve;
 	if (hns->rx_func_hint == HNS3_IO_FUNC_HINT_SIMPLE && simple_allowed)
-		return hns3_recv_pkts;
+		return hns3_recv_pkts_simple;
 	if (hns->rx_func_hint == HNS3_IO_FUNC_HINT_COMMON)
 		return hns3_recv_scattered_pkts;
 
 	if (vec_allowed)
 		return hns3_recv_pkts_vec;
 	if (simple_allowed)
-		return hns3_recv_pkts;
+		return hns3_recv_pkts_simple;
 
 	return hns3_recv_scattered_pkts;
 }
@@ -4433,7 +4435,7 @@ hns3_dev_rx_descriptor_status(void *rx_queue, uint16_t offset)
 	rxdp = &rxq->rx_ring[desc_id];
 	bd_base_info = rte_le_to_cpu_32(rxdp->rx.bd_base_info);
 	dev = &rte_eth_devices[rxq->port_id];
-	if (dev->rx_pkt_burst == hns3_recv_pkts ||
+	if (dev->rx_pkt_burst == hns3_recv_pkts_simple ||
 	    dev->rx_pkt_burst == hns3_recv_scattered_pkts) {
 		if (offset >= rxq->nb_rx_desc - rxq->rx_free_hold)
 			return RTE_ETH_RX_DESC_UNAVAIL;
diff --git a/drivers/net/hns3/hns3_rxtx.h b/drivers/net/hns3/hns3_rxtx.h
index 6689397..d4ac12e 100644
--- a/drivers/net/hns3/hns3_rxtx.h
+++ b/drivers/net/hns3/hns3_rxtx.h
@@ -680,8 +680,8 @@ int hns3_dev_rx_queue_start(struct rte_eth_dev *dev, uint16_t rx_queue_id);
 int hns3_dev_rx_queue_stop(struct rte_eth_dev *dev, uint16_t rx_queue_id);
 int hns3_dev_tx_queue_start(struct rte_eth_dev *dev, uint16_t tx_queue_id);
 int hns3_dev_tx_queue_stop(struct rte_eth_dev *dev, uint16_t tx_queue_id);
-uint16_t hns3_recv_pkts(void *rx_queue, struct rte_mbuf **rx_pkts,
-			uint16_t nb_pkts);
+uint16_t hns3_recv_pkts_simple(void *rx_queue, struct rte_mbuf **rx_pkts,
+				uint16_t nb_pkts);
 uint16_t hns3_recv_scattered_pkts(void *rx_queue, struct rte_mbuf **rx_pkts,
 				  uint16_t nb_pkts);
 uint16_t hns3_recv_pkts_vec(void *rx_queue, struct rte_mbuf **rx_pkts,
-- 
2.7.4

Re: [dpdk-dev] [PATCH v3] net/hns3: rename Rx burst API

[Ferruh Yigit]

On 4/15/2021 9:35 AM, Min Hu (Connor) wrote:
> From: Chengwen Feng <fengchengwen@huawei.com>
> 
> Currently, user could use runtime config "rx_func_hint=simple" to
> select the hns3_recv_pkts API, but the API's name get from
> rte_eth_rx_burst_mode_get is "Scalar" which has not reflected "simple".
> 
> So this patch renames hns3_recv_pkts to hns3_recv_pkts_simple, and
> also change it's name which gets from rte_eth_rx_burst_mode_get to
> "Scalar Simple" to maintain conceptual consistency.
> 
> Fixes: 521ab3e93361 ("net/hns3: add simple Rx path")
> Cc: stable@dpdk.org
> 
> Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
> Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
> Acked-by: Ferruh Yigit <ferruh.yigit@intel.com>

Applied to dpdk-next-net/main, thanks.