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 9CAFCA00B9 for ; Mon, 1 Apr 2019 03:59:50 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 542581150; Mon, 1 Apr 2019 03:59:49 +0200 (CEST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by dpdk.org (Postfix) with ESMTP id 266DF10A3 for ; Mon, 1 Apr 2019 03:59:48 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id A515B21C82; Sun, 31 Mar 2019 21:59:47 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Sun, 31 Mar 2019 21:59:47 -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=X3GyqeScqSplzyxnzXFf9tZKVlJuc9ktqJuqJbnT/7s=; b=ed8Yy1v3UD0n lsNCW9cRna1F1Lcy62qQOrIY0vB6JVS4YM2NT5vJQsr17fnIgCen9jTY+ejgZjMM ekPrv/+V2LioUlauewHL8ghEqZUcS+4wjworGHonMs59h51iJUdTCU4VhW0Pu1+N XbFlWoso2bxYal904L+Lcrj3ukLxH/k= 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=X3GyqeScqSplzyxnzXFf9tZKVlJuc9ktqJuqJbnT/ 7s=; b=GY2f4M/nm06yhOsYHpvDNqJzzC8fGXcP7F9Nmcu3cOEdWD/xWSPs+5RKw ec1zlGPVJFlyDi+6gFHzpJa+iq9wdhrQcrvx8V+b57z4vLm8R0iZ+7tkiE5rhyW9 x1ArRh7aE2WKcCFdT0xPnXXXvWPSpOeZDvqN8zYZzxbVqm4Kxv82Pth+WsIAk8Gt AmfmrczMyM0fjL67ixO/jAFHIKUy6HbumL0MKLg79O3kuBsWcJZWwf/wqRiiV1P6 NggWKAfHNkEu5RTC8O3InpCPJHvNhWLczrwPrLvMkSUK4zsBPWpM1quDyoU0JsQK e26nelpVY7hHIxqFWogvEOBOgliIg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedutddrleefgdehvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthhqredttddtudenucfhrhhomhepvfhhohhmrghs 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 71914E442F; Sun, 31 Mar 2019 21:59:46 -0400 (EDT) From: Thomas Monjalon To: =?ISO-8859-1?Q?Ga=EBtan?= Rivet Cc: dev@dpdk.org, Ferruh Yigit , Andrew Rybchenko Date: Mon, 01 Apr 2019 03:59:45 +0200 Message-ID: <2318869.vaV4MP09YM@xps> In-Reply-To: <5809024.HDbGbE6FtF@xps> References: <20181130002716.27325-1-thomas@monjalon.net> <20190227100724.tjkxtuis5yfwvvrd@bidouze.vm.6wind.com> <5809024.HDbGbE6FtF@xps> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [PATCH v2 2/4] ethdev: add siblings iterators 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: <20190401015945.XfMNC7RXAqyEnw1mfX1ONk7vmfl_gLfW43j7GwRKc9U@z> 27/02/2019 11:51, Thomas Monjalon: > 27/02/2019 11:07, Ga=EBtan Rivet: > > On Wed, Feb 20, 2019 at 11:10:49PM +0100, Thomas Monjalon wrote: > > > +uint16_t __rte_experimental > > > +rte_eth_find_next_of(uint16_t port_id, const struct rte_device *pare= nt) > > > +{ > > > + while (port_id < RTE_MAX_ETHPORTS && > > > + rte_eth_devices[port_id].state =3D=3D RTE_ETH_DEV_UNUSED && > > > + rte_eth_devices[port_id].device !=3D parent) > > > + port_id++; > >=20 > > Why not call rte_eth_find_next directly from this function, and > > add your specific test on top of it? > >=20 > > Something like: > >=20 > > while (port_id < RTE_MAX_ETHPORTS && > > rte_eth_devices[port_id].device !=3D parent) > > port_id =3D rte_eth_find_next(port_id + 1); > >=20 > > this way you won't have to rewrite the test on the device state. Having= the > > logic expressed in several places would make reworking the device state= s more > > complicated than necessary if it were to happen (just as you did when s= witching > > the test from !(ATTACHED || REMOVED) to (UNUSED). >=20 > About the intent, you are right. > About the solution, it seems buggy. We can try to find another way > of coding this loop by using rte_eth_find_next() > and adding the parent condition. Your proposal is correct if adding a first call before the loop: port_id =3D rte_eth_find_next(port_id);