From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by dpdk.org (Postfix) with ESMTP id 9A3F14C95 for ; Wed, 27 Feb 2019 11:51:39 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 1792621E00; Wed, 27 Feb 2019 05:51:39 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Wed, 27 Feb 2019 05:51:39 -0500 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=ZqcRmSWQSbEN5Q2oPedvC217hahX7jy0RsLi0GKb79M=; b=VXd/Wnqarw3w L6Q+A7jmToD3o2RbcOEi7dcLCFwo+s4TIQ19qKq3rkiDYtKCs4jGa6sXGVZFXB60 rZi+vOlEkH2a0Wu7plTuzrVtRSY3kxV8fLSYfiDiSD4VcyTiniOshzD2kxvZ+jHN Gf7lmgbpnrOXMEslvQMO97BbLvRLyEM= 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=ZqcRmSWQSbEN5Q2oPedvC217hahX7jy0RsLi0GKb7 9M=; b=aTD+pALhxbepXzW+SgHCFo7Yjvk/R3o+5oIS/CE8onvgV12NhEPPFjzqM 5hHCQ3GQ2XVNXaiqPmWDjWlYZSsFdNCFG5Yohg/zYZwHZW0l0ooGb97P518RAWS/ ZDUsEjOypfn9VLpZnL+4TvCVJWO5A4KXjfT1YWXAc+PiuFJFS+EgeiESvrC6G/nm xbaSjP0VtPUsrAqVQOUsSEB+hG9oYzwSUZJ+yb91pUJKC/m3CutLh6ftKt3hHYfo La67NrydNiT27I7dGxaj9B00CviyuWsTa0LSjlJbqKZ2n/l1LUHNNM+Y5PUaCna9 0z0/mPW/iQQ5+uKIjIrguzCoN30Og== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedutddrvddugddvudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthhqredttddtudenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucfkph epleefrdeirddugeelrdduudegnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhhomhgr shesmhhonhhjrghlohhnrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from xps.localnet (114.149.6.93.rev.sfr.net [93.6.149.114]) by mail.messagingengine.com (Postfix) with ESMTPA id 00153E4339; Wed, 27 Feb 2019 05:51:36 -0500 (EST) From: Thomas Monjalon To: =?ISO-8859-1?Q?Ga=EBtan?= Rivet Cc: Ferruh Yigit , Andrew Rybchenko , dev@dpdk.org Date: Wed, 27 Feb 2019 11:51:34 +0100 Message-ID: <5809024.HDbGbE6FtF@xps> In-Reply-To: <20190227100724.tjkxtuis5yfwvvrd@bidouze.vm.6wind.com> References: <20181130002716.27325-1-thomas@monjalon.net> <20190220221051.7928-3-thomas@monjalon.net> <20190227100724.tjkxtuis5yfwvvrd@bidouze.vm.6wind.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" 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: , X-List-Received-Date: Wed, 27 Feb 2019 10:51:39 -0000 27/02/2019 11:07, Ga=EBtan Rivet: > Hi Thomas, >=20 > On Wed, Feb 20, 2019 at 11:10:49PM +0100, Thomas Monjalon wrote: > > If multiple ports share the same hardware device (rte_device), > > they are siblings and can be found thanks to the new functions > > and loop macros. > > One iterator takes a port id as reference, > > while the other one directly refers to the parent device. > >=20 > > The ownership is not checked because siblings may have > > different owners. > >=20 > > Signed-off-by: Thomas Monjalon > > --- > > lib/librte_ethdev/rte_ethdev.c | 20 +++++++++++ > > lib/librte_ethdev/rte_ethdev.h | 46 ++++++++++++++++++++++++ > > lib/librte_ethdev/rte_ethdev_version.map | 2 ++ > > 3 files changed, 68 insertions(+) > >=20 > > diff --git a/lib/librte_ethdev/rte_ethdev.c b/lib/librte_ethdev/rte_eth= dev.c > > index b3b2fb1dba..42154787f8 100644 > > --- a/lib/librte_ethdev/rte_ethdev.c > > +++ b/lib/librte_ethdev/rte_ethdev.c > > @@ -340,6 +340,26 @@ rte_eth_find_next(uint16_t port_id) > > return port_id; > > } > > =20 > > +uint16_t __rte_experimental > > +rte_eth_find_next_of(uint16_t port_id, const struct rte_device *parent) > > +{ > > + 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 t= he > logic expressed in several places would make reworking the device states = more > complicated than necessary if it were to happen (just as you did when swi= tching > the test from !(ATTACHED || REMOVED) to (UNUSED). 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.