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 AB07BA0542; Sat, 8 Oct 2022 06:09:06 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 5191740146; Sat, 8 Oct 2022 06:09:06 +0200 (CEST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [45.249.212.187]) by mails.dpdk.org (Postfix) with ESMTP id EE5CB40042 for ; Sat, 8 Oct 2022 06:09:03 +0200 (CEST) Received: from dggemv703-chm.china.huawei.com (unknown [172.30.72.56]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4Mks6W00WXzpVC7; Sat, 8 Oct 2022 12:05:54 +0800 (CST) Received: from kwepemm600004.china.huawei.com (7.193.23.242) by dggemv703-chm.china.huawei.com (10.3.19.46) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Sat, 8 Oct 2022 12:09:01 +0800 Received: from [10.67.103.231] (10.67.103.231) by kwepemm600004.china.huawei.com (7.193.23.242) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Sat, 8 Oct 2022 12:09:00 +0800 Message-ID: <53083e8e-b680-17d4-ce93-7c26bed14a57@huawei.com> Date: Sat, 8 Oct 2022 12:09:00 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.2.0 Subject: Re: [PATCH V2 3/6] ethdev: fix push new event To: Thomas Monjalon CC: , , , References: <20220825024425.10534-1-lihuisong@huawei.com> <20220915124522.5407-1-lihuisong@huawei.com> <20220915124522.5407-4-lihuisong@huawei.com> <1710029.vCJZsxu672@thomas> From: "lihuisong (C)" In-Reply-To: <1710029.vCJZsxu672@thomas> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.67.103.231] X-ClientProxiedBy: dggems705-chm.china.huawei.com (10.3.19.182) To kwepemm600004.china.huawei.com (7.193.23.242) 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 在 2022/9/27 18:49, Thomas Monjalon 写道: > 15/09/2022 14:45, Huisong Li: >> The 'state' in struct rte_eth_dev may be used to update some information >> when app receive these events. For example, when app receives a new event, >> app may get the socket id of this port by calling rte_eth_dev_socket_id to >> setup the attached port. The 'state' is used in rte_eth_dev_socket_id. >> >> If the state isn't modified to RTE_ETH_DEV_ATTACHED before pushing the new >> event, app will get the socket id failed. So this patch moves pushing event >> operation after the state updated. >> >> Fixes: 99a2dd955fba ("lib: remove librte_ prefix from directory names") >> Cc: stable@dpdk.org >> >> Signed-off-by: Huisong Li >> --- >> lib/ethdev/ethdev_driver.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/lib/ethdev/ethdev_driver.c b/lib/ethdev/ethdev_driver.c >> index a285f213f0..a6616f072b 100644 >> --- a/lib/ethdev/ethdev_driver.c >> +++ b/lib/ethdev/ethdev_driver.c >> @@ -206,9 +206,9 @@ rte_eth_dev_probing_finish(struct rte_eth_dev *dev) >> if (rte_eal_process_type() == RTE_PROC_SECONDARY) >> eth_dev_fp_ops_setup(rte_eth_fp_ops + dev->data->port_id, dev); >> >> - rte_eth_dev_callback_process(dev, RTE_ETH_EVENT_NEW, NULL); >> >> dev->state = RTE_ETH_DEV_ATTACHED; >> + rte_eth_dev_callback_process(dev, RTE_ETH_EVENT_NEW, NULL); >> } > As explained in the first patch, I don't think it is a good solution. > We should not allow the port to be used until the end of probing. > When RTE_ETH_EVENT_NEW is sent, the device is allocated but > not ready for use. If an entity like failsafe decides to take ownership > of the port, then the application should not consider it at all. > For these reasons, we should limit which operations can be done > during RTE_ETH_EVENT_NEW processing. > That's why I've proposed creating a new state RTE_ETH_DEV_ALLOCATED, > not sure why you didn't follow this advice. I want to put this problem to this case this patchset mentions, so as to have a better discussion. From the first patch, I know what you mean. But I still have some confusion: When a device taken by failsafe PMD push new event, all event callback will be called under this device. As you suggested, the device is a valid port if its state is ALLOCATED or ATTACHED. Now, the macro RTE_ETH_FOREACH_DEV uses the condition that device is valid(state is ALLOCATED or ATTACHED) and NOT owned. Even if we add the new ALLOCATED state, this device taken by failsafe is also a valid port in new event callback in application, and is in 'NO OWNER'. if event callback of application is called before one of failsafe PMD. As a result, application still can operate this device directly. Can we make sure that event callback of failsafe PMD is before one of application? > > > > > .