From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id C3A00A00E6 for ; Thu, 18 Apr 2019 14:47:19 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 65FC91B9F8; Thu, 18 Apr 2019 14:47:18 +0200 (CEST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by dpdk.org (Postfix) with ESMTP id 410C41B9F6 for ; Thu, 18 Apr 2019 14:47:16 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id C320C21FBF; Thu, 18 Apr 2019 08:47:15 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Thu, 18 Apr 2019 08:47:15 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=mesmtp; bh=zI32nFY2/btGT0yp/PllXUzbDEtCS0D6sm9XwFz/H5c=; b=CKlgnLbOpYbQ qDQZ44asb6r+H8eTfdD5pvBn1BGudlAwFaVrE+bZkiQjJ3gmBpJ73c5kAdqfMUNa DI90hIt9fLCib2EPj7Pwq2inBIvNFvbvnTU96RapxoBAsbI52RIluNdT+4+myCLZ bBvf/wEV4B9dZtrX/it2WoSzH7+V7IU= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=zI32nFY2/btGT0yp/PllXUzbDEtCS0D6sm9XwFz/H 5c=; b=F69MPPV7LyT4Tba0pyH6A4diuSb104V3QbN1t6RoEtZau17hdLT8kYh/E iav1eJ8vPyakzWfR+s+sOPMMnDNHtPSUeFom+6hfffDoWX+VWGWttmiRVEhuJqwZ Ztichj9krqQZrhxEd2l7TqXKu/0ZGcwIowCEpytvoAsA1PvA5mHUwvZqjkGdxK3A IsboZlyD5KEKfi2ikGW45xJovDf1VcQhzJY++CWOnJ//7WgzAjrpAnDyvYf5bW0V qNEXgOve7t6+8vKIOSBZdFZRQGQqQXnt/eo1bLBRixGrRsOekUcnzr22nk3jMdz/ IggQTnvD+zn/5a9QffnkpfvmawrFA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrfeehgdefhecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucfkph epjeejrddufeegrddvtdefrddukeegnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhho mhgrshesmhhonhhjrghlohhnrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 7A071E43A3; Thu, 18 Apr 2019 08:47:14 -0400 (EDT) From: Thomas Monjalon To: Ferruh Yigit Cc: Shahaf Shuler , Yongseok Koh , Andrew Rybchenko , dev@dpdk.org Date: Thu, 18 Apr 2019 14:47:11 +0200 Message-ID: <3775228.0GTJhU53Hy@xps> In-Reply-To: References: <20190417225928.8962-1-thomas@monjalon.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [PATCH 1/2] ethdev: avoid explicit check of valid port state X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Message-ID: <20190418124711.vwdAM36tJn3Ha_r2ZqnwtGzC7YZ_3XbrlNwkIVZza-Q@z> 18/04/2019 13:50, Ferruh Yigit: > On 4/17/2019 11:59 PM, Thomas Monjalon wrote: > > Some port iterations are manually checking against RTE_ETH_DEV_UNUSED > > instead of using the iterators based on rte_eth_find_next(). > > > > A new macro RTE_ETH_FOREACH_VALID_DEV() is introduced, but kept private > > because there should be no need of iterating over all devices in the API. > > The public iterators have additional filters for ownership, parent device > > or sibling ports. > > > > Signed-off-by: Thomas Monjalon > > --- > > drivers/net/mlx5/mlx5.c | 9 ++------- > > lib/librte_ethdev/rte_ethdev.c | 25 ++++++++++++------------- > > No strong opinion but should we separate patch for driver and the library, > logically both changes RTE_ETH_DEV_UNUSED check with macros, but there is no > dependency, I mean they are individual changes, driver patch will be valid on > its own. This is the same change. I removed usage of RTE_ETH_DEV_UNUSED. By chance, it was used only in ethdev and mlx5. I don't feel the need to split because there are usages in different files. > > +#define RTE_ETH_FOREACH_VALID_DEV(port_id) \ > > + for (port_id = rte_eth_find_next(0); \ > > + port_id < RTE_MAX_ETHPORTS; \ > > + port_id = rte_eth_find_next(port_id + 1)) > > + > > What do you think adding some documentation to the new macro, specially I think > documenting the difference between "RTE_ETH_FOREACH_DEV" and this one can be > good otherwise it may confuse people that "RTE_ETH_FOREACH_DEV" iterates on > invalid devices too? This one is not part of the API. I am not sure what I can document more than "iterating all valid ports"? About RTE_ETH_FOREACH_DEV, it is already documented: "Macro to iterate over all enabled and ownerless ethdev ports."