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 8AA9AA00E6 for ; Tue, 19 Mar 2019 18:34:27 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id DA1981DBD; Tue, 19 Mar 2019 18:34:26 +0100 (CET) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by dpdk.org (Postfix) with ESMTP id 9E25D11A4 for ; Tue, 19 Mar 2019 18:34:25 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 35CEB22A0B; Tue, 19 Mar 2019 13:34:25 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Tue, 19 Mar 2019 13:34:25 -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=8ENyj/3/fRKiZsjdLv14T7EtmYOPsLF8g4c+fY31tRo=; b=jDjt7To1I/7U S9oS/b/j1RLk+15E+M0qCoONx7JwBv6RmqR5PihLHhXvMwxsXMAFWMSzmvx71yLX 7s95Wz/lBlJDEpv2hiM54CXIABH0OqSi+Cum5yFc2nJZu4Aedc1nMD2b5sbcBmUN LeF7bKShOFhmmf3M8a8/M9WFpjkFM7U= 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=8ENyj/3/fRKiZsjdLv14T7EtmYOPsLF8g4c+fY31t Ro=; b=Kx30QRAncx1dcgW/54pi5BlupT4+kqt+03tSrK3q3Jezuhzr/NcvtgBAt g+NROQc0e/H4NzhuQOcX2VKFevBDKeD4QjmSTvEwDXZeue4M4H2LT9LBXr5POwgN UK88KGPUpi1jZoHuqTd6pJRv6iBI2Ov+INsoNatN8lT2j5yhhhDIPQsDN2vnhdpn 3jgidgspndwXKQ2RHywbhlAT5o3ZhaRGjwVXz82YTmXhC7i5Q8TkiBkdufNzax9f PshA71ZiwrWxjtVZUZgMallxbuSOPfjqoq3LINXKl+19YQCrNCt1OFEwbkkmC1ct 7EfT7xj+jPlKsUE57RT0DWlR4uMyw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedutddrieeggddutdegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecukf hppeejjedrudefgedrvddtfedrudekgeenucfrrghrrghmpehmrghilhhfrhhomhepthhh ohhmrghssehmohhnjhgrlhhonhdrnhgvthenucevlhhushhtvghrufhiiigvpedt 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 07D3EE4818; Tue, 19 Mar 2019 13:34:23 -0400 (EDT) From: Thomas Monjalon To: Ferruh Yigit Cc: Andrew Rybchenko , dev@dpdk.org Date: Tue, 19 Mar 2019 18:34:21 +0100 Message-ID: <59747746.vl7xl9E5pD@xps> In-Reply-To: <0f5b0dc3-05c6-0f64-1643-7fc23aebfc0a@intel.com> References: <20181130002716.27325-1-thomas@monjalon.net> <20190220221051.7928-3-thomas@monjalon.net> <0f5b0dc3-05c6-0f64-1643-7fc23aebfc0a@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit 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: <20190319173421.YMXfottT2q_TEqQ9-O13j3bZAwVEzhBqFfQn2-5h6ZQ@z> 19/03/2019 16:47, Ferruh Yigit: > On 2/20/2019 10:10 PM, 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. > > > > The ownership is not checked because siblings may have > > different owners. > > > > 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(+) > > > > diff --git a/lib/librte_ethdev/rte_ethdev.c b/lib/librte_ethdev/rte_ethdev.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; > > } > > > > +uint16_t __rte_experimental > > Do we need _rte_experimental on function definitions? I guess only in .h file, > function declaration is enough. Yes we need them both in .h and .c files. > > +rte_eth_find_next_of(uint16_t port_id, const struct rte_device *parent) > > Out of curiosity, what '_of' refers to? It means "next port of parent". Is there a better word than "of"? > > +{ > > + while (port_id < RTE_MAX_ETHPORTS && > > + rte_eth_devices[port_id].state == RTE_ETH_DEV_UNUSED && > > + rte_eth_devices[port_id].device != parent) > > + port_id++; > > Is this logic correct, or am I missing something. > When port status is ATTACHED, check will return false and exit from loop without > checking if the 'device' is same. Oops, I think you are right. > +1 to Gaetan's suggestion to use 'rte_eth_find_next()', which moves status > concern to that function. OK, will change. > > + > > + if (port_id >= RTE_MAX_ETHPORTS) > > + return RTE_MAX_ETHPORTS; > > + > > + return port_id; > > +} > > + > > +uint16_t __rte_experimental > > +rte_eth_find_next_sibling(uint16_t port_id, uint16_t ref) > > I think better to say 'ref_port_id' to clarify what we expect here is a port_id OK > > +{ > > + return rte_eth_find_next_of(port_id, rte_eth_devices[ref].device); > > This is a public API, shouldn't we check if 'ref' if valid port_id value, before > accessing the '.device' field? I'm not a fan of extra checks, but yes we may add one. > > --- a/lib/librte_ethdev/rte_ethdev.h > > +++ b/lib/librte_ethdev/rte_ethdev.h > > +/** > > + * Iterates over ethdev ports of a specified device. > > + * > > + * @param port_id_start > > + * The id of the next possible valid port. > > + * @param parent > > + * The generic device behind the ports to iterate. > > + * @return > > + * Next port id of the device, RTE_MAX_ETHPORTS if there is none. > > Can return 'port_id_start', right? Should it be documented as it is done in > below 'next_sibling' one? Yes, OK. > > + */ > > +__rte_experimental > > +uint16_t rte_eth_find_next_of(uint16_t port_id_start, > > + const struct rte_device *parent); > > + > > +/** > > + * Macro to iterate over all ethdev ports sharing the same rte_device > > + * as the specified port. > > 'specified port'? No port specified, a device pointer is specified. Right, looks like a wrong a copy/paste. > > + * Note: the specified port is part of the loop iterations. > > + */ > > Does it make sense to clarify what 'p' is and what 'parent' is as we do in > function doxygen comments? Since these are macros, harder to grasp the types, I > think better to describe more in macro documentation. Absolutely, yes. I thought I did it. > > +#define RTE_ETH_FOREACH_DEV_OF(p, parent) \ > > + for (p = rte_eth_find_next_of(0, parent); \ > > + p < RTE_MAX_ETHPORTS; \ > > + p = rte_eth_find_next_of(p + 1, parent)) > > + > > +/** > > + * Iterates over sibling ethdev ports (i.e. sharing the same rte_device). > > + * > > + * @param port_id_start > > + * The id of the next possible valid sibling port. > > + * @param ref > > + * The id of a reference port to compare rte_device with. > > + * @return > > + * Next sibling port id (or ref itself), RTE_MAX_ETHPORTS if there is none. > > + */ > > +__rte_experimental > > +uint16_t rte_eth_find_next_sibling(uint16_t port_id_start, uint16_t ref); > > + > > +/** > > + * Macro to iterate over all ethdev ports sharing the same rte_device > > + * as the specified port. > > + * Note: the specified port is part of the loop iterations. > > + */ > > +#define RTE_ETH_FOREACH_DEV_SIBLING(p, ref) \ > > + for (p = rte_eth_find_next_sibling(0, ref); \ > > + p < RTE_MAX_ETHPORTS; \ > > + p = rte_eth_find_next_sibling(p + 1, ref)) Thanks for the complete review Ferruh.