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 21A6046070; Mon, 13 Jan 2025 11:57:17 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id B84EC402A7; Mon, 13 Jan 2025 11:57:16 +0100 (CET) Received: from fout-a5-smtp.messagingengine.com (fout-a5-smtp.messagingengine.com [103.168.172.148]) by mails.dpdk.org (Postfix) with ESMTP id BDE1D40261 for ; Mon, 13 Jan 2025 11:57:14 +0100 (CET) Received: from phl-compute-10.internal (phl-compute-10.phl.internal [10.202.2.50]) by mailfout.phl.internal (Postfix) with ESMTP id 54A59138014C; Mon, 13 Jan 2025 05:57:14 -0500 (EST) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-10.internal (MEProxy); Mon, 13 Jan 2025 05:57:14 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm2; t=1736765834; x=1736852234; bh=VSoY8fherCLvWlZHEONICeBy3jAGqM8bsP9CzBW2Mwk=; b= UP2yF8Vqx5nR99xm1AQ/5e4o0pBzt/zoeD8Q/FHtbHNDujxxh3SGCZcq1xb633em p2N4rRsinV5pm7cHvX4M5bkibgfccNYgB67ZxM8L4RWuqzjlidGeQqOQ9koby/cm dZfvvbvuz737sXi2QY7tlL2dTYx06xw1mTOJKLLv4ZSkfh2iH/hsHu7d70Clj8GT r1rzxBJY8GmZm2W9hfqXXLs7cKDH9NDh92jjDkHv25kpu32gu1hJbmK7r6Xn8G0l rfzS7m7P6WNVU4u92MucBls+gEzI8qgvqbc8fPj9WBk0tNlO5KDhqDtIdWUuJxvT lNhMUdFqGl+yEzcTmKDIpg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1736765834; x= 1736852234; bh=VSoY8fherCLvWlZHEONICeBy3jAGqM8bsP9CzBW2Mwk=; b=W par7gNzdIyv/BWZYh1VslBlImGSpzcwzjSjkAjjioxUUkvafEcTqGU3c0bPcMKRD MG/EVWrPaBQTGiUuvfElULAJiyowNYrSK9aZwIBSlHT0PrgwcR1MzsMFAPWDdBY4 eGDaFY7p5lQ73StNSOyHurt+0Va0RjDUumY79mogZmflASsX1qRN9ycyUR7GxlGN 7cHWuKQ1vsxUSF1VGJmqhN3zyOJzRvDCZc1DdFlIjUkEIGOPbECiyHz/GcyYpYe5 BihU7JWHSJODnmHQ7CY5leBAw3nivWLNSt/Bhup5st6L4xKXx3VlfEKAEOgVQ5Aw x0V+KFuLYhkXFx6cOXwJQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefuddrudehgedgvddvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh htshculddquddttddmnecujfgurhephffvvefufffkjghfggfgtgesthhqredttddtjeen ucfhrhhomhepvfhhohhmrghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrg hlohhnrdhnvghtqeenucggtffrrghtthgvrhhnpeegtddtleejjeegffekkeektdejvedt heevtdekiedvueeuvdeiuddvleevjeeujeenucevlhhushhtvghrufhiiigvpedtnecurf grrhgrmhepmhgrihhlfhhrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtpdhn sggprhgtphhtthhopedujedpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtoheplhhihh huihhsohhngheshhhurgifvghirdgtohhmpdhrtghpthhtohepuggvvhesughpughkrdho rhhgpdhrtghpthhtohepshhtvghphhgvnhesnhgvthifohhrkhhplhhumhgsvghrrdhorh hgpdhrtghpthhtohepfhgvrhhruhhhrdihihhgihhtsegrmhgurdgtohhmpdhrtghpthht oheprghjihhtrdhkhhgrphgrrhguvgessghrohgruggtohhmrdgtohhmpdhrtghpthhtoh epshhomhhnrghthhdrkhhothhurhessghrohgruggtohhmrdgtohhmpdhrtghpthhtohep phhrrghvvggvnhdrshhhvghtthihsehinhhtvghlrdgtohhmpdhrtghpthhtoheprghnug hrvgifrdgsohihvghrsegrmhgurdgtohhmpdhrtghpthhtohepughsohhsnhhofihskhhi sehnvhhiughirgdrtghomh X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 13 Jan 2025 05:57:11 -0500 (EST) From: Thomas Monjalon To: "lihuisong (C)" Cc: dev@dpdk.org, stephen@networkplumber.org, ferruh.yigit@amd.com, Ajit Khaparde , Somnath Kotur , Praveen Shetty , Andrew Boyer , Dariusz Sosnowski , Viacheslav Ovsiienko , Bing Zhao , Ori Kam , Suanming Mou , Matan Azrad , Chaoyong He , Andrew Rybchenko , fengchengwen@huawei.com Subject: Re: [PATCH v1 2/2] ethdev: fix skip valid port in probing callback Date: Mon, 13 Jan 2025 11:57:09 +0100 Message-ID: <9389517.CDJkKcVGEf@thomas> In-Reply-To: <0293d4d1-0df7-63e1-3dba-244729a78bb0@huawei.com> References: <20250113025521.32703-1-lihuisong@huawei.com> <1988729.PYKUYFuaPT@thomas> <0293d4d1-0df7-63e1-3dba-244729a78bb0@huawei.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" 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 13/01/2025 10:35, lihuisong (C): > =E5=9C=A8 2025/1/13 16:16, Thomas Monjalon =E5=86=99=E9=81=93: > > 13/01/2025 03:55, Huisong Li: > >> The event callback in application may use the macro RTE_ETH_FOREACH_DE= V to > >> iterate over all enabled ports to do something(like, verifying the por= t id > >> validity) when receive a probing event. If the ethdev state of a port = is > >> not RTE_ETH_DEV_UNUSED, this port will be considered as a valid port. > >> > >> However, this state is set to RTE_ETH_DEV_ATTACHED after pushing probi= ng > >> event. It means that probing callback will skip this port. But this > >> assignment can not move to front of probing notification. See > >> commit be8cd210379a ("ethdev: fix port probing notification") > >> > >> So this patch has to add a new state, RTE_ETH_DEV_ALLOCATED. Set the e= thdev > >> state to RTE_ETH_DEV_ALLOCATED before pushing probing event and set it= to > >> RTE_ETH_DEV_ATTACHED after definitely probed. And this port is valid i= f its > >> device state is 'ALLOCATED' or 'ATTACHED'. > > If you do that, changing the definition of eth_dev_find_free_port() > > you allow the application using a port before probing is finished. >=20 > Yes, it's not reasonable. >=20 > Thinking your comment twice, I feel that the root cause of this issue is= =20 > application want to check if the port id is valid. > However, application just receive the new event from the device and the=20 > port id of this device must be valid when report new event. > So application can think the received new event is valid and don't need=20 > to check, right? Yes Do you think it should be highlighted in the API doc? We currently have this: RTE_ETH_EVENT_NEW, /**< port is probed */ > If so I think this series can be dropped. > > It is the same as changing the state to RTE_ETH_DEV_ATTACHED > > before calling the event callback. > > > > So this is a NACK. > > > > Why do you need drivers to check the state of a notified device? > > If it is RTE_ETH_EVENT_NEW, you know that's a new device, > > there is nothing else to check. >=20 > It just modified the verification about RTE_ETH_DEV_UNUSED in the device= =20 > driver. > Driver not need to know the event. Sorry I was not clear. I said "drivers", but it should be "apps & drivers" because they can both register to the event RTE_ETH_EVENT_NEW. In some situations, it is convenient for a driver to listen to new ports (it was done for failsafe driver).