From patchwork Tue Apr 13 11:50:00 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "humin (Q)" X-Patchwork-Id: 91239 X-Patchwork-Delegate: ferruh.yigit@amd.com Return-Path: X-Original-To: patchwork@inbox.dpdk.org Delivered-To: patchwork@inbox.dpdk.org Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id E86D4A0524; Tue, 13 Apr 2021 13:50:47 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 56B6E160EBF; Tue, 13 Apr 2021 13:50:12 +0200 (CEST) Received: from szxga07-in.huawei.com (szxga07-in.huawei.com [45.249.212.35]) by mails.dpdk.org (Postfix) with ESMTP id 5433F160E91 for ; Tue, 13 Apr 2021 13:50:04 +0200 (CEST) Received: from DGGEMS410-HUB.china.huawei.com (unknown [172.30.72.59]) by szxga07-in.huawei.com (SkyGuard) with ESMTP id 4FKP3z2MM0z9yCn for ; Tue, 13 Apr 2021 19:47:43 +0800 (CST) Received: from localhost.localdomain (10.69.192.56) by DGGEMS410-HUB.china.huawei.com (10.3.19.210) with Microsoft SMTP Server id 14.3.498.0; Tue, 13 Apr 2021 19:49:54 +0800 From: "Min Hu (Connor)" To: CC: Date: Tue, 13 Apr 2021 19:50:00 +0800 Message-ID: <1618314611-47978-2-git-send-email-humin29@huawei.com> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1618314611-47978-1-git-send-email-humin29@huawei.com> References: <1618314611-47978-1-git-send-email-humin29@huawei.com> MIME-Version: 1.0 X-Originating-IP: [10.69.192.56] X-CFilter-Loop: Reflected Subject: [dpdk-dev] [PATCH 01/12] net/hns3: delete mailbox arq ring X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" From: Chengwen Feng 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 Signed-off-by: Min Hu (Connor) --- 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); From patchwork Tue Apr 13 11:50:01 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "humin (Q)" X-Patchwork-Id: 91238 X-Patchwork-Delegate: ferruh.yigit@amd.com Return-Path: X-Original-To: patchwork@inbox.dpdk.org Delivered-To: patchwork@inbox.dpdk.org Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 31441A0524; Tue, 13 Apr 2021 13:50:42 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 09362160EB7; Tue, 13 Apr 2021 13:50:11 +0200 (CEST) Received: from szxga07-in.huawei.com (szxga07-in.huawei.com [45.249.212.35]) by mails.dpdk.org (Postfix) with ESMTP id 5C1ED160E94 for ; Tue, 13 Apr 2021 13:50:04 +0200 (CEST) Received: from DGGEMS410-HUB.china.huawei.com (unknown [172.30.72.59]) by szxga07-in.huawei.com (SkyGuard) with ESMTP id 4FKP3z2jMYz9ydV for ; Tue, 13 Apr 2021 19:47:43 +0800 (CST) Received: from localhost.localdomain (10.69.192.56) by DGGEMS410-HUB.china.huawei.com (10.3.19.210) with Microsoft SMTP Server id 14.3.498.0; Tue, 13 Apr 2021 19:49:55 +0800 From: "Min Hu (Connor)" To: CC: Date: Tue, 13 Apr 2021 19:50:01 +0800 Message-ID: <1618314611-47978-3-git-send-email-humin29@huawei.com> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1618314611-47978-1-git-send-email-humin29@huawei.com> References: <1618314611-47978-1-git-send-email-humin29@huawei.com> MIME-Version: 1.0 X-Originating-IP: [10.69.192.56] X-CFilter-Loop: Reflected Subject: [dpdk-dev] [PATCH 02/12] net/hns3: fix possible mismatches response of mailbox X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" From: Chengwen Feng 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 Signed-off-by: Min Hu (Connor) --- 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]; }; From patchwork Tue Apr 13 11:50:02 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "humin (Q)" X-Patchwork-Id: 91233 X-Patchwork-Delegate: ferruh.yigit@amd.com Return-Path: X-Original-To: patchwork@inbox.dpdk.org Delivered-To: patchwork@inbox.dpdk.org Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id C3226A0524; Tue, 13 Apr 2021 13:50:12 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id DA8AD160E93; Tue, 13 Apr 2021 13:50:04 +0200 (CEST) Received: from szxga07-in.huawei.com (szxga07-in.huawei.com [45.249.212.35]) by mails.dpdk.org (Postfix) with ESMTP id 865FE160E81 for ; Tue, 13 Apr 2021 13:50:01 +0200 (CEST) Received: from DGGEMS410-HUB.china.huawei.com (unknown [172.30.72.59]) by szxga07-in.huawei.com (SkyGuard) with ESMTP id 4FKP3z3tBNzB04K for ; Tue, 13 Apr 2021 19:47:43 +0800 (CST) Received: from localhost.localdomain (10.69.192.56) by DGGEMS410-HUB.china.huawei.com (10.3.19.210) with Microsoft SMTP Server id 14.3.498.0; Tue, 13 Apr 2021 19:49:55 +0800 From: "Min Hu (Connor)" To: CC: Date: Tue, 13 Apr 2021 19:50:02 +0800 Message-ID: <1618314611-47978-4-git-send-email-humin29@huawei.com> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1618314611-47978-1-git-send-email-humin29@huawei.com> References: <1618314611-47978-1-git-send-email-humin29@huawei.com> MIME-Version: 1.0 X-Originating-IP: [10.69.192.56] X-CFilter-Loop: Reflected Subject: [dpdk-dev] [PATCH 03/12] net/hns3: fix VF may report LSC event in secondary process X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" From: Chengwen Feng 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 Signed-off-by: Min Hu (Connor) --- 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); From patchwork Tue Apr 13 11:50:03 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "humin (Q)" X-Patchwork-Id: 91241 X-Patchwork-Delegate: ferruh.yigit@amd.com Return-Path: X-Original-To: patchwork@inbox.dpdk.org Delivered-To: patchwork@inbox.dpdk.org Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 78589A0524; Tue, 13 Apr 2021 13:50:59 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id AB06D160ECA; Tue, 13 Apr 2021 13:50:14 +0200 (CEST) Received: from szxga07-in.huawei.com (szxga07-in.huawei.com [45.249.212.35]) by mails.dpdk.org (Postfix) with ESMTP id C6E82160E9C for ; Tue, 13 Apr 2021 13:50:05 +0200 (CEST) Received: from DGGEMS410-HUB.china.huawei.com (unknown [172.30.72.59]) by szxga07-in.huawei.com (SkyGuard) with ESMTP id 4FKP3z4GGHzB04h for ; Tue, 13 Apr 2021 19:47:43 +0800 (CST) Received: from localhost.localdomain (10.69.192.56) by DGGEMS410-HUB.china.huawei.com (10.3.19.210) with Microsoft SMTP Server id 14.3.498.0; Tue, 13 Apr 2021 19:49:55 +0800 From: "Min Hu (Connor)" To: CC: Date: Tue, 13 Apr 2021 19:50:03 +0800 Message-ID: <1618314611-47978-5-git-send-email-humin29@huawei.com> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1618314611-47978-1-git-send-email-humin29@huawei.com> References: <1618314611-47978-1-git-send-email-humin29@huawei.com> MIME-Version: 1.0 X-Originating-IP: [10.69.192.56] X-CFilter-Loop: Reflected Subject: [dpdk-dev] [PATCH 04/12] net/hns3: fix potentially incorrect timing in MBX X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" From: Chengchang Tang 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 Signed-off-by: Min Hu (Connor) --- 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; } From patchwork Tue Apr 13 11:50:04 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "humin (Q)" X-Patchwork-Id: 91240 X-Patchwork-Delegate: ferruh.yigit@amd.com Return-Path: X-Original-To: patchwork@inbox.dpdk.org Delivered-To: patchwork@inbox.dpdk.org Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 90231A0524; Tue, 13 Apr 2021 13:50:53 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 8E31B160EC4; Tue, 13 Apr 2021 13:50:13 +0200 (CEST) Received: from szxga07-in.huawei.com (szxga07-in.huawei.com [45.249.212.35]) by mails.dpdk.org (Postfix) with ESMTP id BE5DD160E96 for ; Tue, 13 Apr 2021 13:50:04 +0200 (CEST) Received: from DGGEMS410-HUB.china.huawei.com (unknown [172.30.72.59]) by szxga07-in.huawei.com (SkyGuard) with ESMTP id 4FKP3z44YlzB04S for ; Tue, 13 Apr 2021 19:47:43 +0800 (CST) Received: from localhost.localdomain (10.69.192.56) by DGGEMS410-HUB.china.huawei.com (10.3.19.210) with Microsoft SMTP Server id 14.3.498.0; Tue, 13 Apr 2021 19:49:55 +0800 From: "Min Hu (Connor)" To: CC: Date: Tue, 13 Apr 2021 19:50:04 +0800 Message-ID: <1618314611-47978-6-git-send-email-humin29@huawei.com> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1618314611-47978-1-git-send-email-humin29@huawei.com> References: <1618314611-47978-1-git-send-email-humin29@huawei.com> MIME-Version: 1.0 X-Originating-IP: [10.69.192.56] X-CFilter-Loop: Reflected Subject: [dpdk-dev] [PATCH 05/12] net/hns3: fix incorrect use of CMD status enumeration type X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" From: Chengchang Tang 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 Signed-off-by: Min Hu (Connor) --- 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; From patchwork Tue Apr 13 11:50:05 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "humin (Q)" X-Patchwork-Id: 91237 X-Patchwork-Delegate: ferruh.yigit@amd.com Return-Path: X-Original-To: patchwork@inbox.dpdk.org Delivered-To: patchwork@inbox.dpdk.org Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id D7601A0524; Tue, 13 Apr 2021 13:50:36 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id BCF04160EB2; Tue, 13 Apr 2021 13:50:09 +0200 (CEST) Received: from szxga07-in.huawei.com (szxga07-in.huawei.com [45.249.212.35]) by mails.dpdk.org (Postfix) with ESMTP id 5ABF5160E93 for ; Tue, 13 Apr 2021 13:50:04 +0200 (CEST) Received: from DGGEMS410-HUB.china.huawei.com (unknown [172.30.72.59]) by szxga07-in.huawei.com (SkyGuard) with ESMTP id 4FKP3z3DxbzB03G for ; Tue, 13 Apr 2021 19:47:43 +0800 (CST) Received: from localhost.localdomain (10.69.192.56) by DGGEMS410-HUB.china.huawei.com (10.3.19.210) with Microsoft SMTP Server id 14.3.498.0; Tue, 13 Apr 2021 19:49:55 +0800 From: "Min Hu (Connor)" To: CC: Date: Tue, 13 Apr 2021 19:50:05 +0800 Message-ID: <1618314611-47978-7-git-send-email-humin29@huawei.com> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1618314611-47978-1-git-send-email-humin29@huawei.com> References: <1618314611-47978-1-git-send-email-humin29@huawei.com> MIME-Version: 1.0 X-Originating-IP: [10.69.192.56] X-CFilter-Loop: Reflected Subject: [dpdk-dev] [PATCH 06/12] net/hns3: fix miss verification of whether NEON supported X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" From: Chengwen Feng 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 Signed-off-by: Min Hu (Connor) --- 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 #include #include -#if defined(RTE_ARCH_ARM64) && defined(__ARM_FEATURE_SVE) +#if defined(RTE_ARCH_ARM64) #include #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; From patchwork Tue Apr 13 11:50:06 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "humin (Q)" X-Patchwork-Id: 91243 X-Patchwork-Delegate: ferruh.yigit@amd.com Return-Path: X-Original-To: patchwork@inbox.dpdk.org Delivered-To: patchwork@inbox.dpdk.org Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id A6451A0524; Tue, 13 Apr 2021 13:51:12 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 3A890160EDF; Tue, 13 Apr 2021 13:50:17 +0200 (CEST) Received: from szxga07-in.huawei.com (szxga07-in.huawei.com [45.249.212.35]) by mails.dpdk.org (Postfix) with ESMTP id B4A43160E94 for ; Tue, 13 Apr 2021 13:50:05 +0200 (CEST) Received: from DGGEMS410-HUB.china.huawei.com (unknown [172.30.72.59]) by szxga07-in.huawei.com (SkyGuard) with ESMTP id 4FKP3z2C3lz9y61 for ; Tue, 13 Apr 2021 19:47:43 +0800 (CST) Received: from localhost.localdomain (10.69.192.56) by DGGEMS410-HUB.china.huawei.com (10.3.19.210) with Microsoft SMTP Server id 14.3.498.0; Tue, 13 Apr 2021 19:49:56 +0800 From: "Min Hu (Connor)" To: CC: Date: Tue, 13 Apr 2021 19:50:06 +0800 Message-ID: <1618314611-47978-8-git-send-email-humin29@huawei.com> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1618314611-47978-1-git-send-email-humin29@huawei.com> References: <1618314611-47978-1-git-send-email-humin29@huawei.com> MIME-Version: 1.0 X-Originating-IP: [10.69.192.56] X-CFilter-Loop: Reflected Subject: [dpdk-dev] [PATCH 07/12] net/hns3: fix missing outer L4 UDP flag for VXLAN packet X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" From: Chengwen Feng 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 Signed-off-by: Min Hu (Connor) --- 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; } From patchwork Tue Apr 13 11:50:07 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "humin (Q)" X-Patchwork-Id: 91242 X-Patchwork-Delegate: ferruh.yigit@amd.com Return-Path: X-Original-To: patchwork@inbox.dpdk.org Delivered-To: patchwork@inbox.dpdk.org Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id EF68AA0562; Tue, 13 Apr 2021 13:51:04 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id C36A1160ED3; Tue, 13 Apr 2021 13:50:15 +0200 (CEST) Received: from szxga07-in.huawei.com (szxga07-in.huawei.com [45.249.212.35]) by mails.dpdk.org (Postfix) with ESMTP id C3E42160E96 for ; Tue, 13 Apr 2021 13:50:05 +0200 (CEST) Received: from DGGEMS410-HUB.china.huawei.com (unknown [172.30.72.59]) by szxga07-in.huawei.com (SkyGuard) with ESMTP id 4FKP3z3ZNKzB03j for ; Tue, 13 Apr 2021 19:47:43 +0800 (CST) Received: from localhost.localdomain (10.69.192.56) by DGGEMS410-HUB.china.huawei.com (10.3.19.210) with Microsoft SMTP Server id 14.3.498.0; Tue, 13 Apr 2021 19:49:56 +0800 From: "Min Hu (Connor)" To: CC: Date: Tue, 13 Apr 2021 19:50:07 +0800 Message-ID: <1618314611-47978-9-git-send-email-humin29@huawei.com> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1618314611-47978-1-git-send-email-humin29@huawei.com> References: <1618314611-47978-1-git-send-email-humin29@huawei.com> MIME-Version: 1.0 X-Originating-IP: [10.69.192.56] X-CFilter-Loop: Reflected Subject: [dpdk-dev] [PATCH 08/12] net/hns3: add reporting TUNNEL GRE packet type X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" From: Chengwen Feng 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 Signed-off-by: Min Hu (Connor) --- 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 | From patchwork Tue Apr 13 11:50:08 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "humin (Q)" X-Patchwork-Id: 91234 X-Patchwork-Delegate: ferruh.yigit@amd.com Return-Path: X-Original-To: patchwork@inbox.dpdk.org Delivered-To: patchwork@inbox.dpdk.org Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 89E3BA0562; Tue, 13 Apr 2021 13:50:18 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 23D5B160E9F; Tue, 13 Apr 2021 13:50:06 +0200 (CEST) Received: from szxga07-in.huawei.com (szxga07-in.huawei.com [45.249.212.35]) by mails.dpdk.org (Postfix) with ESMTP id C6F05160E88 for ; Tue, 13 Apr 2021 13:50:01 +0200 (CEST) Received: from DGGEMS410-HUB.china.huawei.com (unknown [172.30.72.59]) by szxga07-in.huawei.com (SkyGuard) with ESMTP id 4FKP3z2YRqz9yLv for ; Tue, 13 Apr 2021 19:47:43 +0800 (CST) Received: from localhost.localdomain (10.69.192.56) by DGGEMS410-HUB.china.huawei.com (10.3.19.210) with Microsoft SMTP Server id 14.3.498.0; Tue, 13 Apr 2021 19:49:56 +0800 From: "Min Hu (Connor)" To: CC: Date: Tue, 13 Apr 2021 19:50:08 +0800 Message-ID: <1618314611-47978-10-git-send-email-humin29@huawei.com> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1618314611-47978-1-git-send-email-humin29@huawei.com> References: <1618314611-47978-1-git-send-email-humin29@huawei.com> MIME-Version: 1.0 X-Originating-IP: [10.69.192.56] X-CFilter-Loop: Reflected Subject: [dpdk-dev] [PATCH 09/12] net/hns3: fix PTP caps report X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" From: Chengwen Feng 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 Signed-off-by: Min Hu (Connor) --- 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)) From patchwork Tue Apr 13 11:50:09 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "humin (Q)" X-Patchwork-Id: 91235 X-Patchwork-Delegate: ferruh.yigit@amd.com Return-Path: X-Original-To: patchwork@inbox.dpdk.org Delivered-To: patchwork@inbox.dpdk.org Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 7B135A0524; Tue, 13 Apr 2021 13:50:24 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 5517A160EA4; Tue, 13 Apr 2021 13:50:07 +0200 (CEST) Received: from szxga07-in.huawei.com (szxga07-in.huawei.com [45.249.212.35]) by mails.dpdk.org (Postfix) with ESMTP id BC059160E87 for ; Tue, 13 Apr 2021 13:50:01 +0200 (CEST) Received: from DGGEMS410-HUB.china.huawei.com (unknown [172.30.72.59]) by szxga07-in.huawei.com (SkyGuard) with ESMTP id 4FKP3z2vW6zB034 for ; Tue, 13 Apr 2021 19:47:43 +0800 (CST) Received: from localhost.localdomain (10.69.192.56) by DGGEMS410-HUB.china.huawei.com (10.3.19.210) with Microsoft SMTP Server id 14.3.498.0; Tue, 13 Apr 2021 19:49:56 +0800 From: "Min Hu (Connor)" To: CC: Date: Tue, 13 Apr 2021 19:50:09 +0800 Message-ID: <1618314611-47978-11-git-send-email-humin29@huawei.com> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1618314611-47978-1-git-send-email-humin29@huawei.com> References: <1618314611-47978-1-git-send-email-humin29@huawei.com> MIME-Version: 1.0 X-Originating-IP: [10.69.192.56] X-CFilter-Loop: Reflected Subject: [dpdk-dev] [PATCH 10/12] net/hns3: rename Rx burst API X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" From: Chengwen Feng 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 Signed-off-by: Min Hu (Connor) --- 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, From patchwork Tue Apr 13 11:50:10 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "humin (Q)" X-Patchwork-Id: 91231 X-Patchwork-Delegate: ferruh.yigit@amd.com Return-Path: X-Original-To: patchwork@inbox.dpdk.org Delivered-To: patchwork@inbox.dpdk.org Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id DBA8AA0562; Tue, 13 Apr 2021 13:50:02 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id C308D160E83; Tue, 13 Apr 2021 13:50:02 +0200 (CEST) Received: from szxga07-in.huawei.com (szxga07-in.huawei.com [45.249.212.35]) by mails.dpdk.org (Postfix) with ESMTP id 8731B160E83 for ; Tue, 13 Apr 2021 13:50:01 +0200 (CEST) Received: from DGGEMS410-HUB.china.huawei.com (unknown [172.30.72.59]) by szxga07-in.huawei.com (SkyGuard) with ESMTP id 4FKP3z34hWzB03D for ; Tue, 13 Apr 2021 19:47:43 +0800 (CST) Received: from localhost.localdomain (10.69.192.56) by DGGEMS410-HUB.china.huawei.com (10.3.19.210) with Microsoft SMTP Server id 14.3.498.0; Tue, 13 Apr 2021 19:49:57 +0800 From: "Min Hu (Connor)" To: CC: Date: Tue, 13 Apr 2021 19:50:10 +0800 Message-ID: <1618314611-47978-12-git-send-email-humin29@huawei.com> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1618314611-47978-1-git-send-email-humin29@huawei.com> References: <1618314611-47978-1-git-send-email-humin29@huawei.com> MIME-Version: 1.0 X-Originating-IP: [10.69.192.56] X-CFilter-Loop: Reflected Subject: [dpdk-dev] [PATCH 11/12] net/hns3: add supported ptypes list for RXD advanced layout X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" From: Chengwen Feng 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 Signed-off-by: Min Hu (Connor) --- 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; } From patchwork Tue Apr 13 11:50:11 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "humin (Q)" X-Patchwork-Id: 91236 X-Patchwork-Delegate: ferruh.yigit@amd.com Return-Path: X-Original-To: patchwork@inbox.dpdk.org Delivered-To: patchwork@inbox.dpdk.org Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 72DB9A0524; Tue, 13 Apr 2021 13:50:31 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 80EDE160EA9; Tue, 13 Apr 2021 13:50:08 +0200 (CEST) Received: from szxga07-in.huawei.com (szxga07-in.huawei.com [45.249.212.35]) by mails.dpdk.org (Postfix) with ESMTP id 5495B160E92 for ; Tue, 13 Apr 2021 13:50:04 +0200 (CEST) Received: from DGGEMS410-HUB.china.huawei.com (unknown [172.30.72.59]) by szxga07-in.huawei.com (SkyGuard) with ESMTP id 4FKP3z3QWhzB03X for ; Tue, 13 Apr 2021 19:47:43 +0800 (CST) Received: from localhost.localdomain (10.69.192.56) by DGGEMS410-HUB.china.huawei.com (10.3.19.210) with Microsoft SMTP Server id 14.3.498.0; Tue, 13 Apr 2021 19:49:57 +0800 From: "Min Hu (Connor)" To: CC: Date: Tue, 13 Apr 2021 19:50:11 +0800 Message-ID: <1618314611-47978-13-git-send-email-humin29@huawei.com> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1618314611-47978-1-git-send-email-humin29@huawei.com> References: <1618314611-47978-1-git-send-email-humin29@huawei.com> MIME-Version: 1.0 X-Originating-IP: [10.69.192.56] X-CFilter-Loop: Reflected Subject: [dpdk-dev] [PATCH 12/12] net/hns3: remove VLAN/QINQ ptypes from support list X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" From: Chengwen Feng 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 Signed-off-by: Min Hu (Connor) --- 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,