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 20CFE4606C; Mon, 13 Jan 2025 09:16:56 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id A97C9402A7; Mon, 13 Jan 2025 09:16:55 +0100 (CET) Received: from fout-a3-smtp.messagingengine.com (fout-a3-smtp.messagingengine.com [103.168.172.146]) by mails.dpdk.org (Postfix) with ESMTP id 2D3D140261 for ; Mon, 13 Jan 2025 09:16:54 +0100 (CET) Received: from phl-compute-01.internal (phl-compute-01.phl.internal [10.202.2.41]) by mailfout.phl.internal (Postfix) with ESMTP id 7C90B1380167; Mon, 13 Jan 2025 03:16:53 -0500 (EST) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-01.internal (MEProxy); Mon, 13 Jan 2025 03:16:53 -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=1736756213; x=1736842613; bh=bPh3sXipbDt0qccEmkpG7RNUnpvJGTR7MkZZziHYras=; b= XDsynvDPHX+QT1g3PKaz/op94iXp004CHivtKwHeFy71FyHzNA37lyvNPNFfkMUp eoxedwGGlkgWiDO/47KFQOmKDFwtWvy8ojD6uL4xx7X4ciC3ghTpdrToDT6S7rId UCEw8seXbJf7fqfCRQgQExrfcfEpIrtB9VVbTFhBwOKk7cp/DKIz0P2oH5qVWgbA 19LqTGJHeUy262xREMp8fJjoq4blkwCIhHdNePdtQf3zHG5R4cFKYBWw0Hfk6PAH FinPQnSu0WedLiFdort24E2A/+zsMKrW60xCwDIB5oAsMG2EbwhDFCYUsAZUsrVH flerSszN+lZ5iuD672skxA== 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=1736756213; x= 1736842613; bh=bPh3sXipbDt0qccEmkpG7RNUnpvJGTR7MkZZziHYras=; b=a BPbpfq5nNlANSw0AxqwmIDi7tFSIldRFlSfkCc65YIIdKWaYCYARut4F9/h0tx/C TYo4yshQkdofO9VtTHRSpsKkMinauWccnOeNyR9Qi/IGu88cYMOT737J7GvaYJWb 0vKCkaDM6lpf8ZcyiEIzPqercUoaRdLA2YrpG0u79Uzf5eujxBPYXnpHHzH/x+t+ OtMdc4YxGp+kYoyVJO8wArAN7h96EJuECZa1kAQFO3ry8qDjbFBT9d/WyxP/Pp6z MhrGPCYloAsAs0GYHSYZ6feOcxxGQCDLhzFGhOU00Wd04CccJp++s80tiN4mtNHx OTmE1rR9ygc2SvRfR9/Jw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefuddrudehfedgudduiecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpggftfghnshhusghstghrihgsvgdp uffrtefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivg hnthhsucdlqddutddtmdenucfjughrpefhvfevufffkfgjfhgggfgtsehtufertddttdej necuhfhrohhmpefvhhhomhgrshcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjh grlhhonhdrnhgvtheqnecuggftrfgrthhtvghrnhepjeduveehieevuddutdevfffgtdeg keeuveejffejgedtgeegkefgvdeugfefkeejnecuvehluhhsthgvrhfuihiivgeptdenuc frrghrrghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvthdp nhgspghrtghpthhtohepudejpdhmohguvgepshhmthhpohhuthdprhgtphhtthhopehlih hhuhhishhonhhgsehhuhgrfigvihdrtghomhdprhgtphhtthhopeguvghvseguphgukhdr ohhrghdprhgtphhtthhopehsthgvphhhvghnsehnvghtfihorhhkphhluhhmsggvrhdroh hrghdprhgtphhtthhopehfvghrrhhuhhdrhihighhithesrghmugdrtghomhdprhgtphht thhopegrjhhithdrkhhhrghprghruggvsegsrhhorggutghomhdrtghomhdprhgtphhtth hopehsohhmnhgrthhhrdhkohhtuhhrsegsrhhorggutghomhdrtghomhdprhgtphhtthho pehprhgrvhgvvghnrdhshhgvthhthiesihhnthgvlhdrtghomhdprhgtphhtthhopegrnh gurhgvfidrsghohigvrhesrghmugdrtghomhdprhgtphhtthhopegushhoshhnohifshhk ihesnhhvihguihgrrdgtohhm X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 13 Jan 2025 03:16:50 -0500 (EST) From: Thomas Monjalon To: Huisong Li 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 09:16:48 +0100 Message-ID: <1988729.PYKUYFuaPT@thomas> In-Reply-To: <20250113025521.32703-3-lihuisong@huawei.com> References: <20250113025521.32703-1-lihuisong@huawei.com> <20250113025521.32703-3-lihuisong@huawei.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit 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 03:55, Huisong Li: > The event callback in application may use the macro RTE_ETH_FOREACH_DEV to > iterate over all enabled ports to do something(like, verifying the port 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 probing > 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 ethdev > 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 if 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. 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.