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 EF0FAA0553; Sat, 11 Jun 2022 09:42:55 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 8BBBB427F9; Sat, 11 Jun 2022 09:42:51 +0200 (CEST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [45.249.212.187]) by mails.dpdk.org (Postfix) with ESMTP id D0B9C40689; Sat, 11 Jun 2022 09:42:49 +0200 (CEST) Received: from kwepemi500017.china.huawei.com (unknown [172.30.72.55]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4LKqXW21TmzjX8g; Sat, 11 Jun 2022 15:41:47 +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.2375.24; Sat, 11 Jun 2022 15:42:47 +0800 From: Dongdong Liu To: CC: , Huisong Li , Dongdong Liu , "Min Hu (Connor)" , Yisen Zhuang , Lijun Ou , Chengwen Feng Subject: [PATCH 1/2] net/hns3: fix fail to obtain VF LSC capability Date: Sat, 11 Jun 2022 15:42:26 +0800 Message-ID: <20220611074227.30276-2-liudongdong3@huawei.com> X-Mailer: git-send-email 2.22.0 In-Reply-To: <20220611074227.30276-1-liudongdong3@huawei.com> References: <20220611074227.30276-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: dggems705-chm.china.huawei.com (10.3.19.182) 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: Huisong Li Currently, the VF LSC capability is obtained from PF driver in the interrupt mailbox interrupt thread, it is asynchronous. The VF driver waits for 500ms to get this capability in probe process. The primary process will receive a message and do probe in the interrupt thread context when attach a device in the secondary process. At this case, VF driver never obtains this capability from PF. The root cause is that 'vf->pf_push_lsc_cap' is not updated by the handling mailbox thread until finishing probe. The reason this update wouldn't be done is that the handling mailbox interrupt thread and the probe alarm thread are both in epool thread, and the probe alarm thread is before the mailbox interrupt thread. Fixes: 9bc2289fe5ea ("net/hns3: refactor VF LSC event report") Cc: stable@dpdk.org Signed-off-by: Huisong Li Signed-off-by: Dongdong Liu --- drivers/net/hns3/hns3_ethdev_vf.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/drivers/net/hns3/hns3_ethdev_vf.c b/drivers/net/hns3/hns3_ethdev_vf.c index bebfaa6417..3abd4aafcb 100644 --- a/drivers/net/hns3/hns3_ethdev_vf.c +++ b/drivers/net/hns3/hns3_ethdev_vf.c @@ -777,6 +777,14 @@ hns3vf_get_push_lsc_cap(struct hns3_hw *hw) while (remain_ms > 0) { rte_delay_ms(HNS3_POLL_RESPONE_MS); + /* + * The probe process may perform in interrupt thread context. + * For example, users attach a device in the secondary process. + * At the moment, the handling mailbox task will be blocked. So + * driver has to actively handle the HNS3_MBX_LINK_STAT_CHANGE + * mailbox from PF driver to get this capability. + */ + hns3_dev_handle_mbx_msg(hw); if (__atomic_load_n(&vf->pf_push_lsc_cap, __ATOMIC_ACQUIRE) != HNS3_PF_PUSH_LSC_CAP_UNKNOWN) break; -- 2.22.0