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 AA01642B71; Mon, 22 May 2023 15:20:20 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 2D3C242D4D; Mon, 22 May 2023 15:20:06 +0200 (CEST) Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by mails.dpdk.org (Postfix) with ESMTP id 1D67840EE5; Mon, 22 May 2023 15:20:01 +0200 (CEST) Received: from kwepemi500017.china.huawei.com (unknown [172.30.72.55]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4QPybp70SlzTkd2; Mon, 22 May 2023 21:15:02 +0800 (CST) Received: from localhost.localdomain (10.28.79.22) by kwepemi500017.china.huawei.com (7.221.188.110) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.23; Mon, 22 May 2023 21:19:58 +0800 From: Dongdong Liu To: , , , , CC: , , , , Subject: [PATCH v2 4/5] net/hns3: fix receive multiple firmware reset interrupts Date: Mon, 22 May 2023 21:17:39 +0800 Message-ID: <20230522131740.30043-5-liudongdong3@huawei.com> X-Mailer: git-send-email 2.22.0 In-Reply-To: <20230522131740.30043-1-liudongdong3@huawei.com> References: <20230518112944.32276-1-liudongdong3@huawei.com> <20230522131740.30043-1-liudongdong3@huawei.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [10.28.79.22] X-ClientProxiedBy: dggems704-chm.china.huawei.com (10.3.19.181) To kwepemi500017.china.huawei.com (7.221.188.110) X-CFilter-Loop: Reflected 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 From: Chengwen Feng In the firmware (also known as IMP) reset scenario, driver interrupt processing and firmware watchdog initialization are asynchronous. If the driver interrupt processing is faster than firmware watchdog initialization (that is, the driver clears the firmware reset interrupt source before the firmware watchdog is initialized), the driver will receive multiple firmware reset interrupts. In the Kunpeng 920 platform, the above situation does not exist. But it does on the newer platforms. So we add 5ms delay before drivers clears the IMP reset interrupt source. As for the impact of 5ms, the number of PFs managed by a firmware is limited. Therefore, even if a DPDK process takes over all the PFs which managed by the firmware, the delay is controllable. Fixes: ee930d38ffca ("net/hns3: fix timing of clearing interrupt source") Cc: stable@dpdk.org Signed-off-by: Chengwen Feng Signed-off-by: Dongdong Liu --- drivers/net/hns3/hns3_ethdev.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/drivers/net/hns3/hns3_ethdev.c b/drivers/net/hns3/hns3_ethdev.c index 5ef66f96c6..664226a6ef 100644 --- a/drivers/net/hns3/hns3_ethdev.c +++ b/drivers/net/hns3/hns3_ethdev.c @@ -286,6 +286,19 @@ hns3_handle_mac_tnl(struct hns3_hw *hw) } } +static void +hns3_delay_before_clear_event_cause(struct hns3_hw *hw, uint32_t event_type, uint32_t regclr) +{ +#define IMPRESET_WAIT_MS_TIME 5 + + if (event_type == HNS3_VECTOR0_EVENT_RST && + regclr & BIT(HNS3_VECTOR0_IMPRESET_INT_B) && + hw->revision >= PCI_REVISION_ID_HIP09_A) { + rte_delay_ms(IMPRESET_WAIT_MS_TIME); + hns3_dbg(hw, "wait firmware watchdog initialization completed."); + } +} + static void hns3_interrupt_handler(void *param) { @@ -305,6 +318,7 @@ hns3_interrupt_handler(void *param) vector0_int = hns3_read_dev(hw, HNS3_VECTOR0_OTHER_INT_STS_REG); ras_int = hns3_read_dev(hw, HNS3_RAS_PF_OTHER_INT_STS_REG); cmdq_int = hns3_read_dev(hw, HNS3_VECTOR0_CMDQ_SRC_REG); + hns3_delay_before_clear_event_cause(hw, event_cause, clearval); hns3_clear_event_cause(hw, event_cause, clearval); /* vector 0 interrupt is shared with reset and mailbox source events. */ if (event_cause == HNS3_VECTOR0_EVENT_ERR) { -- 2.22.0