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 6F904A0A0E; Wed, 3 Feb 2021 13:25:37 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 939D2240579; Wed, 3 Feb 2021 13:24:38 +0100 (CET) Received: from szxga06-in.huawei.com (szxga06-in.huawei.com [45.249.212.32]) by mails.dpdk.org (Postfix) with ESMTP id B517C24052C for ; Wed, 3 Feb 2021 13:24:30 +0100 (CET) Received: from DGGEMS401-HUB.china.huawei.com (unknown [172.30.72.60]) by szxga06-in.huawei.com (SkyGuard) with ESMTP id 4DW1710C6zzjHHr; Wed, 3 Feb 2021 20:23:25 +0800 (CST) Received: from localhost.localdomain (10.69.192.56) by DGGEMS401-HUB.china.huawei.com (10.3.19.201) with Microsoft SMTP Server id 14.3.498.0; Wed, 3 Feb 2021 20:24:24 +0800 From: Lijun Ou To: CC: , Date: Wed, 3 Feb 2021 20:23:55 +0800 Message-ID: <1612355037-48768-10-git-send-email-oulijun@huawei.com> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1612355037-48768-1-git-send-email-oulijun@huawei.com> References: <1612355037-48768-1-git-send-email-oulijun@huawei.com> MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [10.69.192.56] X-CFilter-Loop: Reflected Subject: [dpdk-dev] [PATCH 09/11] net/hns3: fix cmdq cleared during firmware 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: Chengchang Tang There are two scenarios that command queue uninit performed concurrently with the firmware command: asynchronous command and timeout command. For asynchronous command, if a large number of functions send commands, these commands may need to be queued to wait for firmware processing. If a function is uninited suddenly, CMDQ clearing and firmware processing may be performed concurrently. For timeout command, if the command failed due to busy scheduling of firmware, this command will be processed in the next scheduling. And this may lead to concurrency. The preceding concurrency may lead to a firmware exceptions. This patch add a waiting time to ensure the firmware complete the processing of left over command when PMD uninit. Fixes: 737f30e1c3ab ("net/hns3: support command interface with firmware") Cc: stable@dpdk.org Signed-off-by: Chengchang Tang Signed-off-by: Lijun Ou --- drivers/net/hns3/hns3_cmd.c | 14 +++++++++++++- drivers/net/hns3/hns3_cmd.h | 1 + 2 files changed, 14 insertions(+), 1 deletion(-) diff --git a/drivers/net/hns3/hns3_cmd.c b/drivers/net/hns3/hns3_cmd.c index 3d6ffc0..32cd56b 100644 --- a/drivers/net/hns3/hns3_cmd.c +++ b/drivers/net/hns3/hns3_cmd.c @@ -582,9 +582,21 @@ hns3_cmd_destroy_queue(struct hns3_hw *hw) void hns3_cmd_uninit(struct hns3_hw *hw) { + __atomic_store_n(&hw->reset.disable_cmd, 1, __ATOMIC_RELAXED); + + /* + * A delay is added to ensure that the register cleanup operations + * will not be performed concurrently with the firmware command and + * ensure that all the reserved commands are executed. + * Concurrency may occur in two scenarios: asynchronous command and + * timeout command. If the command fails to be executed due to busy + * scheduling, the command will be processed in the next scheduling + * of the firmware. + */ + rte_delay_ms(HNS3_CMDQ_CLEAR_WAIT_TIME); + rte_spinlock_lock(&hw->cmq.csq.lock); rte_spinlock_lock(&hw->cmq.crq.lock); - __atomic_store_n(&hw->reset.disable_cmd, 1, __ATOMIC_RELAXED); hns3_cmd_clear_regs(hw); rte_spinlock_unlock(&hw->cmq.crq.lock); rte_spinlock_unlock(&hw->cmq.csq.lock); diff --git a/drivers/net/hns3/hns3_cmd.h b/drivers/net/hns3/hns3_cmd.h index 5640fe4..5010278 100644 --- a/drivers/net/hns3/hns3_cmd.h +++ b/drivers/net/hns3/hns3_cmd.h @@ -8,6 +8,7 @@ #include #define HNS3_CMDQ_TX_TIMEOUT 30000 +#define HNS3_CMDQ_CLEAR_WAIT_TIME 200 #define HNS3_CMDQ_RX_INVLD_B 0 #define HNS3_CMDQ_RX_OUTVLD_B 1 #define HNS3_CMD_DESC_ALIGNMENT 4096 -- 2.7.4