From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-f169.google.com (mail-wr0-f169.google.com [209.85.128.169]) by dpdk.org (Postfix) with ESMTP id 99BD4CFBA for ; Tue, 28 Mar 2017 15:35:25 +0200 (CEST) Received: by mail-wr0-f169.google.com with SMTP id u1so105752195wra.2 for ; Tue, 28 Mar 2017 06:35:25 -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=uIdfCEMzZ8YyqKOtJyU6sYgYdhlYSzAAGrPsZDtJU+8=; b=zvJ9Zch7ap7TXuGQ9FlecIxtnBulIQulQHhy9IK4xQBDy29jYTLmP+1lDfFjIDySSt dbmRbMv6ULmctoWiHcHzIRefPfidZpHDmYT/q+CTexZ3UX8JtKhLItYgzqHs659ivjIP 8O2fujcQnJIhazbMw6fo0kR3CHsVYZdjlZZMwi5o6rgrmqpoPmfQdZtoAm230ko0Y40X 1F86TipZsb4aL4JxttIvq/fIGfu/JH1AjvH4qZP94jk3aGH4/hsh7czPCBlNzichBFV2 IBV6kL2BcaE9UQRoYZXrOnxFc4n3NW4NmMlnap/gnyfOZz/q/USZZ+etmvnhzMLKYot6 U0oQ== 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=uIdfCEMzZ8YyqKOtJyU6sYgYdhlYSzAAGrPsZDtJU+8=; b=uNUWoONKAeODAqa1Gu94FgXemYxZFL7PDgF7FEWPR6c3AQE1+yr/HzUjK85bi9AdXK wfj8+A2H1YKU8/mKT6ASQ04o1jL4K3gFLm4CLw3Wtc3rTsI5+XntcI3xugtRdBmokzkw 1eZudVIiwoaahxMUQfAs8OudsNFRWmLhkAWdw77Os+gqulsTa6B86XqMnQO5XW+ISRGX 5RBVIaWAeFEg5uonF7kgbXqFfNRHx0qy6Al8K3RY7cBi+p7UfL5OgKY9JC5te1VgIzMA tpr2WjjvXlonRajxnXwBVpyjaHKGEMlCZgt70yzz4xfwSiZOVBJUQTFFKRMpUzmKxPfi juFA== X-Gm-Message-State: AFeK/H0i+OVOX2+Z1Jfh2NFPfGoUlFdiXHocyJ4VK+n7ADpqIzDDsOE2lbMEGY63gXAcZty6 X-Received: by 10.223.157.17 with SMTP id k17mr12694665wre.156.1490708125264; Tue, 28 Mar 2017 06:35:25 -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 m188sm3678576wmm.7.2017.03.28.06.35.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Mar 2017 06:35:24 -0700 (PDT) Date: Tue, 28 Mar 2017 15:35:16 +0200 From: =?iso-8859-1?Q?Ga=EBtan?= Rivet To: Bruce Richardson Cc: dev@dpdk.org, Thomas Monjalon Message-ID: <20170328133516.GE7450@bidouze.vm.6wind.com> References: <1490701917-17089-1-git-send-email-gaetan.rivet@6wind.com> <1490702489-17950-1-git-send-email-gaetan.rivet@6wind.com> <20170328122000.GA24328@bricha3-MOBL3.ger.corp.intel.com> <20170328124409.GC7450@bidouze.vm.6wind.com> <20170328130347.GA22460@bricha3-MOBL3.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20170328130347.GA22460@bricha3-MOBL3.ger.corp.intel.com> User-Agent: Mutt/1.5.23 (2014-03-12) Subject: Re: [dpdk-dev] [PATCH v2 1/1] pci: default to whitelist mode 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: Tue, 28 Mar 2017 13:35:25 -0000 On Tue, Mar 28, 2017 at 02:03:48PM +0100, Bruce Richardson wrote: >On Tue, Mar 28, 2017 at 02:44:09PM +0200, Gaëtan Rivet wrote: >> On Tue, Mar 28, 2017 at 01:20:00PM +0100, Bruce Richardson wrote: >> > On Tue, Mar 28, 2017 at 02:01:29PM +0200, Gaetan Rivet wrote: >> > > Expects all devices to be explicitly defined before being probed. >> > > >> > > The blacklist mode can be prone to errors, coaxing users in >> > > capturing devices that could be used for management or otherwise. >> > > The whitelist mode offers users more control and highlight >> > > mistakes by making them visible on the command line. >> > > >> > > This is more useful to have a clear idea of the state of the >> > > system used, which is better in the context of standalone / >> > > headless applications. >> > > >> > > Using the -b option will revert to the original behavior. >> > > >> > > Signed-off-by: Gaetan Rivet --- v2: >> > > justify this default behavior evolution. --- >> > >> > I don't have major objections to this patch, though it does make it >> > mandatory to use port parameters where before it was not. The one >> > suggestion I will make is that, if we take this approach, we should >> > probably add a --wl-all (whitelist-all) flag to go back to having >> > all ports automatically bound, if so desired. >> > >> >> Are there use cases where the blacklist mode would be used without >> blacklisting any device? The current -b option is almost enough for >> the same level of functionality. >> >Yes. >For ports used for management, those will probably remain bound to >the regular kernel driver, and not available for DPDK use. That means >that the DPDK app need not specify any blacklist or whitelist options >right now, you can determine what ports to use or not simply by binding >to a uio/vfio driver or not at system setup time. > Yes, what I (slightly) dislike about that is that we uselessly scan a few devices as well as run probes against them by enumerating all DPDK drivers and seeing what sticks to the wall. Sure it works and it worked that way for some time, but in the end this just seems a little hackish. >Is this not the normal way people do port setup for DPDK? > I cannot really speak for other users, my point in putting this patch out there is also to have a survey of usages and see if anyone is resolutely against it. At least for 6WIND, we indeed use the whitelist mode in general. This is better for having deterministic test runs among heterogeneous hardware platforms and explicit test and bug reports. >> If there is an actual need to a full PCI probe, adding this option is >> certainly possible. I was thinking otherwise of allowing "all" as an >> argument to -w, which would have our users using -wall or -w=all, which >> seems clear enough. This would essentially be the inverse of the --no-pci >> parameter. >> >> Which could probably be removed if this patch is accepted. >> >> -- >> Gaëtan Rivet >> 6WIND -- Gaëtan Rivet 6WIND