From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id EB4F9A0A02 for ; Mon, 17 May 2021 18:15:04 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id E594340041; Mon, 17 May 2021 18:15:04 +0200 (CEST) Received: from youngberry.canonical.com (youngberry.canonical.com [91.189.89.112]) by mails.dpdk.org (Postfix) with ESMTP id B1BCF410E0 for ; Mon, 17 May 2021 18:15:02 +0200 (CEST) Received: from 2.general.paelzer.uk.vpn ([10.172.196.173] helo=Keschdeichel.fritz.box) by youngberry.canonical.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1liftW-00087o-GS; Mon, 17 May 2021 16:15:02 +0000 From: Christian Ehrhardt To: Chengwen Feng Cc: Min Hu , dpdk stable Date: Mon, 17 May 2021 18:09:04 +0200 Message-Id: <20210517161039.3132619-115-christian.ehrhardt@canonical.com> X-Mailer: git-send-email 2.31.1 In-Reply-To: <20210517161039.3132619-1-christian.ehrhardt@canonical.com> References: <20210517161039.3132619-1-christian.ehrhardt@canonical.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Subject: [dpdk-stable] patch 'net/hns3: fix VF handling LSC event in secondary process' has been queued to stable release 19.11.9 X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org Sender: "stable" Hi, FYI, your patch has been queued to stable release 19.11.9 Note it hasn't been pushed to http://dpdk.org/browse/dpdk-stable yet. It will be pushed if I get no objections before 05/19/21. So please shout if anyone has objections. Also note that after the patch there's a diff of the upstream commit vs the patch applied to the branch. This will indicate if there was any rebasing needed to apply to the stable branch. If there were code changes for rebasing (ie: not only metadata diffs), please double check that the rebase was correctly done. Queued patches are on a temporary branch at: https://github.com/cpaelzer/dpdk-stable-queue This queued commit can be viewed at: https://github.com/cpaelzer/dpdk-stable-queue/commit/67069d4cd10b98677d48de5b7e93d0ccfc5ebcd4 Thanks. Christian Ehrhardt --- >From 67069d4cd10b98677d48de5b7e93d0ccfc5ebcd4 Mon Sep 17 00:00:00 2001 From: Chengwen Feng Date: Tue, 13 Apr 2021 19:50:02 +0800 Subject: [PATCH] net/hns3: fix VF handling LSC event in secondary process [ upstream commit dbbbad23e380773b37872df2195c4529fd93ca6f ] 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") 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 3f97b8100b..f289d57012 100644 --- a/drivers/net/hns3/hns3_mbx.c +++ b/drivers/net/hns3/hns3_mbx.c @@ -327,6 +327,44 @@ hns3_handle_link_change_event(struct hns3_hw *hw, hns3_update_link_status(hw); } +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) { @@ -341,6 +379,29 @@ hns3_dev_handle_mbx_msg(struct hns3_hw *hw) uint8_t *temp; int i; + 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 (rte_atomic16_read(&hw->reset.disable_cmd)) return; @@ -361,6 +422,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: resp->resp_status = hns3_resp_to_errno(req->msg[3]); -- 2.31.1 --- Diff of the applied patch vs upstream commit (please double-check if non-empty: --- --- - 2021-05-17 17:40:33.949263197 +0200 +++ 0115-net-hns3-fix-VF-handling-LSC-event-in-secondary-proc.patch 2021-05-17 17:40:29.335810768 +0200 @@ -1 +1 @@ -From dbbbad23e380773b37872df2195c4529fd93ca6f Mon Sep 17 00:00:00 2001 +From 67069d4cd10b98677d48de5b7e93d0ccfc5ebcd4 Mon Sep 17 00:00:00 2001 @@ -5,0 +6,2 @@ +[ upstream commit dbbbad23e380773b37872df2195c4529fd93ca6f ] + @@ -31 +32,0 @@ -Cc: stable@dpdk.org @@ -40 +41 @@ -index 8e38649d21..c5b0856c96 100644 +index 3f97b8100b..f289d57012 100644 @@ -43,2 +44,2 @@ -@@ -400,6 +400,44 @@ hns3_handle_promisc_info(struct hns3_hw *hw, uint16_t promisc_en) - } +@@ -327,6 +327,44 @@ hns3_handle_link_change_event(struct hns3_hw *hw, + hns3_update_link_status(hw); @@ -88,3 +89,3 @@ -@@ -411,6 +449,29 @@ hns3_dev_handle_mbx_msg(struct hns3_hw *hw) - - rte_spinlock_lock(&hw->cmq.crq.lock); +@@ -341,6 +379,29 @@ hns3_dev_handle_mbx_msg(struct hns3_hw *hw) + uint8_t *temp; + int i; @@ -116,3 +117,3 @@ - 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) + if (rte_atomic16_read(&hw->reset.disable_cmd)) + return; +@@ -361,6 +422,13 @@ hns3_dev_handle_mbx_msg(struct hns3_hw *hw) @@ -131 +132 @@ - hns3_handle_mbx_response(hw, req); + resp->resp_status = hns3_resp_to_errno(req->msg[3]);