From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f44.google.com (mail-wm0-f44.google.com [74.125.82.44]) by dpdk.org (Postfix) with ESMTP id 07A1B1B5DD for ; Wed, 18 Oct 2017 10:20:35 +0200 (CEST) Received: by mail-wm0-f44.google.com with SMTP id m72so8370153wmc.1 for ; Wed, 18 Oct 2017 01:20:35 -0700 (PDT) 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=x7tx1jiVaZd450Q9/w4sLF+Jdz1zeM6mN0SdgGB4aM0=; b=MUxK1TtGQSAvPdU8uLSnDaYEWT5fRjCcndcA+08wry1mGvgnGFww66OP9+rMdNSSc6 5F+WVm2UcedFIGNSnEA9YtpFTZc3O/MrxZ1VNIJUvgFLXXJvPBXUmKmy69WDDNXQp0Oo L5VHSwsAYHzrgAqHFQt8ZYy3MIU/aFGXUzFZMLKqn4TSL7oTS8SHnD6iecqtJ+5Zmp8f 8wF6r1FCf0cmzynYp65zyrfekGE+yhf359+LN5LHalXJbh1SJ/wwHkNcLl+34KqBVCFw IUQnD45ccXSEIWbT11kJwKkKho0L454zy748gJKmNRjcQA4tU8rMuwbLzta3/GWNheE0 pKnA== 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=x7tx1jiVaZd450Q9/w4sLF+Jdz1zeM6mN0SdgGB4aM0=; b=WWhU3RBOUpeztRW6AXB5S10ksvstev15HFQfWAZx6sfabAF8jEHrAksFpJV/Q8CpMP izAc3XLDtGRmvOTyESWMnSc8p+8jgFz4bNi9N0I2qfpj7gdTWAbvW+5Ikx0idBCBB0ZN WYTDf/T56VNg6bt2sJMsAN7ZWPLFPA9wYUQIhf4l9eyAFQP7v2vYUh0+HMsF7Ijt9ZZI rTY52SfmQ7sZIDvhifTM9IR/YDxHsHz5Ias6xMGU/AXKyknSqiC1UNP0JE2FzAIvA1sA LzvLG6YZPKKccUkg/Pqt0ADEoO7pIA1GOOof4jYrXNx4KpHh8a3vpAKWsN97kBTF5lC2 gDGQ== X-Gm-Message-State: AMCzsaUHkVSNs/x0IIyLxFJLSmKGACpgjYD41VnJhKI74EUNhEwVfqK3 DDMwWF4f4gjbcZOw1/+x21J25Q== X-Google-Smtp-Source: AOwi7QB1N8akGAp9S6MP9dAxLtfG2Ay8I+sgqoS0NHukHUq+U4dyS0IPsUVlDvipxLPE3Jx4GEYDPQ== X-Received: by 10.80.171.198 with SMTP id u64mr20674813edc.21.1508314835530; Wed, 18 Oct 2017 01:20:35 -0700 (PDT) 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 g27sm7942524edf.43.2017.10.18.01.20.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 18 Oct 2017 01:20:34 -0700 (PDT) Date: Wed, 18 Oct 2017 10:20:18 +0200 From: =?iso-8859-1?Q?Ga=EBtan?= Rivet To: Aaron Conole Cc: dev@dpdk.org Message-ID: <20171018082018.GA3596@bidouze.vm.6wind.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Subject: Re: [dpdk-dev] [PATCH v2 02/18] eal: remove generic devtype 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, 18 Oct 2017 08:20:36 -0000 Hello Aaron, On Tue, Oct 17, 2017 at 02:16:59PM -0400, Aaron Conole wrote: > Gaetan Rivet writes: > > > The devtype is now entirely defined by the device bus. As such, it is > > already characterized by the bus identifier within an rte_devargs. > > > > The rte_devtype enum can disappear, along with crutches added during > > this transition. > > > > rte_eal_devargs_type_count becomes useless and is removed. > > > > Signed-off-by: Gaetan Rivet > > --- < ... > > > @@ -380,11 +371,8 @@ rte_pci_probe(void) > > probed++; > > > > devargs = dev->device.devargs; > > - /* probe all or only whitelisted devices */ > > - if (probe_all) > > - ret = pci_probe_all_drivers(dev); > > - else if (devargs != NULL && > > - devargs->policy == RTE_DEV_WHITELISTED) > > + /* probe all or only declared devices */ > > + if (probe_all ^ (devargs != NULL)) > > What is the intent of this? If probe_all is true, and devargs != null, > I think this branch isn't taken. > > Shouldn't this be ||? Maybe I missed something? > Here are the possible choices: probe_all \ devargs !NULL NULL --------------------------+----------------------+----------------------------+ true |blacklist and the |blacklist mode and no | |devargs describes a |devargs, meaning the device | |blacklisted device |is not blacklisted | |--> do not probe |--> do probe | --------------------------+----------------------+----------------------------+ false |whitelist mode and |whitelist mode and no | |whitelisted device |devargs, device has been | |using a devargs |scanned but not whitelisted | |--> do probe |--> do not probe | --------------------------+----------------------+----------------------------+ A XOR is thus the logical expression of this decision. What I could be doubtful about here is that using a xor anywhere can be confusing for some people and it could all be expressed in two simpler ifs. Also, probe_all could be renamed as "blacklist_mode" for example to be more descriptive. But unless I'm mistaken, the logic should be correct. > > ret = pci_probe_all_drivers(dev); > > if (ret < 0) { > > RTE_LOG(ERR, EAL, "Requested device " PCI_PRI_FMT < ... > -- Gaëtan Rivet 6WIND