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 DA1EDA00C2; Tue, 27 Sep 2022 12:49:26 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 82A9A41133; Tue, 27 Sep 2022 12:49:26 +0200 (CEST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by mails.dpdk.org (Postfix) with ESMTP id 46C2A410D0 for ; Tue, 27 Sep 2022 12:49:25 +0200 (CEST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id E76B35C00C9; Tue, 27 Sep 2022 06:49:24 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Tue, 27 Sep 2022 06:49:24 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm2; t=1664275764; x= 1664362164; bh=eY4yE5zA+Wif9NrIvjS3jcEHwmOw1/dT7pITnu+9M5U=; b=I KfkuVgbYtttleSn0h7d46ysKXrthT36hXBjuVSlIvC2JdIlsI57z+20uAk0hMgo0 E0nsdUmAsax0fu4ABFN2XWzuGDuPe0f0xxxrmpSO2IEJuiHfkr3gS0xuhumXJpRS VQizQ2eC56ElV+4kHnQRd1uKEzOHLkzTUD/bN0BrMeBrSwx0fxZMsyHwPhv4a5fS odx+Ms781epnXM+Bh5CtHaukeWy2CvEKMPMcKcAdHsJ/VDJFIMM1AtvrSNLrkRlF bplA6cIM3Q5vdYS7aEUvox92oUKLHA1ZJxR8A9aemyturVstCVxR7mN1c2vWS2pW AcnCimg7cYg5l+8/5WjBg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1664275764; x= 1664362164; bh=eY4yE5zA+Wif9NrIvjS3jcEHwmOw1/dT7pITnu+9M5U=; b=y GhkkUwAJyyUlz816SnmkYJ1WBqMgkv6FPpC6Z4mH/pMS3FNRDrPNQwrvbJU8kaBR 3FbVHrtq0FnzBme6yAdnorDzEkWGS4Ig7BUiSJiPJk83aSFre9VYhIw57keLy9Ih QxmN68rD950ABCZRHjxbvsWIdOBQU13fr7Pjzw6kN00PYErVGA7LTVen+SDeF3Ur MYAXF/P7vdQuObSZ/Labl0OM/XRhkWv93Z6m8/rf/udw68EIl1NYT+57g8+c/K7Y wW8A15q1qLPwot1o65FoAzm89OXW8vb0a18jFmfK8WV6aqgw2HDZCRBZiP5Mhm0A AfG4Ee7C9DfxrvwZggaoA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrfeegiedgtdekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvvefufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpedtjeeiieefhedtfffgvdelteeufeefheeujefgueetfedttdei kefgkeduhedtgfenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 27 Sep 2022 06:49:23 -0400 (EDT) From: Thomas Monjalon To: Huisong Li Cc: dev@dpdk.org, ferruh.yigit@xilinx.com, andrew.rybchenko@oktetlabs.ru, huangdaode@huawei.com Subject: Re: [PATCH V2 3/6] ethdev: fix push new event Date: Tue, 27 Sep 2022 12:49:21 +0200 Message-ID: <1710029.vCJZsxu672@thomas> In-Reply-To: <20220915124522.5407-4-lihuisong@huawei.com> References: <20220825024425.10534-1-lihuisong@huawei.com> <20220915124522.5407-1-lihuisong@huawei.com> <20220915124522.5407-4-lihuisong@huawei.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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 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.