From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-f67.google.com (mail-wm1-f67.google.com [209.85.128.67]) by dpdk.org (Postfix) with ESMTP id 395A84CAB for ; Wed, 27 Feb 2019 11:07:28 +0100 (CET) Received: by mail-wm1-f67.google.com with SMTP id z84so4962140wmg.4 for ; Wed, 27 Feb 2019 02:07:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=oUrXL2zL6eB8Xl3aESEdNci5+jEJYVZMVtnoJXTdPFI=; b=pQZ7n2DpTuhaYczooKf7R4nsTbj1KVo8jFig8BV2xsKOjXc2muZKQ8c48gxkNXFgt3 qqYV8BS+48AClMo+VPkJ9l/81kUSd/jf536ey1NlTQ2fukUOXhr7dLbiJxPFsICVUFAv Do016NXi6UfGSqpjW5qFT4XGZP5R+CokO5HBzhlN2FWjhheesPXn19vzlzgYJZwd5ACl n+XLi7BRXD8elSmM9IaG1FDqMiz21rUN0NLHnG5WtjcdvvpnitffKpB4RtgM/5gB9Awn paU3EqoXglZvPYgibrBPWZmHV52zsQS63lMSBmLnKixysGh3U08ggmjknN6HD5lZ/a5V ai7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=oUrXL2zL6eB8Xl3aESEdNci5+jEJYVZMVtnoJXTdPFI=; b=WG9S79Fh6IUYTS1hJDSmpSw7XTG9UNSU+b02BCN9EEH3svD7w1fZdGHgjjwrPLQpar m6qNVsiHl+/SUiqWtA2NObPUrKaXja6nlczC9fj1lXFp0XLaYbzKAl1ieIcXoVUYmkTs RYiq2unXWcmqT4C0r2H+ZlZ5G61jlndWtKQJQhWd7K9kIuUzinsc98tG1ucScHDbtaQ1 ZOZFZQRuYKNFLA1NZfZCVmNc3P5CljZNJdIfTEUFBfEvyIw0O8l3IVg8V15+dZL2VtsH eA0WlXz2Goa8jP2IZt5ImwhZRO/4h67EJAgR/BVgDWv3B/e2o6uTDojkXdvgOR7wLCB1 +kSQ== X-Gm-Message-State: AHQUAuaSfkxlnxZAAz9W49dHpXnu+PO/4dvAvjBCus1mVQOI2ccJUExd uVh7fYptD2xP6sE0DGzre9H20naItWE= X-Google-Smtp-Source: AHgI3IY5TVzBcjgMuPvQZEBkSBG5Asv6OWsmL5+5pUs1tFYZVJZ4IiM1HgU6u4a2mWctAxCijcx+Uw== X-Received: by 2002:a1c:7306:: with SMTP id d6mr1642463wmb.98.1551262047696; Wed, 27 Feb 2019 02:07:27 -0800 (PST) Received: from bidouze.vm.6wind.com (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78]) by smtp.gmail.com with ESMTPSA id c15sm9161742wrv.69.2019.02.27.02.07.25 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 27 Feb 2019 02:07:26 -0800 (PST) Date: Wed, 27 Feb 2019 11:07:24 +0100 From: =?iso-8859-1?Q?Ga=EBtan?= Rivet To: Thomas Monjalon Cc: Ferruh Yigit , Andrew Rybchenko , dev@dpdk.org Message-ID: <20190227100724.tjkxtuis5yfwvvrd@bidouze.vm.6wind.com> References: <20181130002716.27325-1-thomas@monjalon.net> <20190220221051.7928-1-thomas@monjalon.net> <20190220221051.7928-3-thomas@monjalon.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20190220221051.7928-3-thomas@monjalon.net> User-Agent: NeoMutt/20170113 (1.7.2) 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:07:28 -0000 Hi Thomas, 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. > > 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 > +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 == RTE_ETH_DEV_UNUSED && > + rte_eth_devices[port_id].device != parent) > + port_id++; Why not call rte_eth_find_next directly from this function, and add your specific test on top of it? Something like: while (port_id < RTE_MAX_ETHPORTS && rte_eth_devices[port_id].device != parent) port_id = rte_eth_find_next(port_id + 1); 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 states more complicated than necessary if it were to happen (just as you did when switching the test from !(ATTACHED || REMOVED) to (UNUSED). -- Gaëtan Rivet 6WIND