From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-f170.google.com (mail-wr0-f170.google.com [209.85.128.170]) by dpdk.org (Postfix) with ESMTP id BF3B837B2 for ; Thu, 30 Mar 2017 21:36:45 +0200 (CEST) Received: by mail-wr0-f170.google.com with SMTP id w43so75020751wrb.0 for ; Thu, 30 Mar 2017 12:36:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:user-agent:in-reply-to :references:mime-version:content-transfer-encoding; bh=d/LwZL8V7s05PK1Cpp/JLvCHXqfnKgjtFx8lW0SscaM=; b=Arv8O52Bxk5AaKn3FGZeqRRNcayxyofqGOBvfvjH1MCbK70s1z3kHVVedACqYYdpwl hnfw5tOVI22T0EjKiyAANDUkz3J0A1d+O91XtJSvoobROWUVvvvYM0itryKwtMOFIyr4 2VhdrcmXfA/q2vQW2gf2gYnF87gC6r+U//mdW1XXd8Oh6puNesJemSmDZYEZs7jhSvBF 1FGsXm/fUwkCQbGb0mETCr9//vLSgKoiTivYjKQ2ijqwAnLyRj/6vg31JSxrg0bDeQC+ GRXACY5y7MG4tIo4cOtDud3W5amXjRmfwPuVNe0K2LamUeSAtU1jOrJ6DvFtOlOmB6FV 5gsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:user-agent :in-reply-to:references:mime-version:content-transfer-encoding; bh=d/LwZL8V7s05PK1Cpp/JLvCHXqfnKgjtFx8lW0SscaM=; b=tHhH9HeEJhVA8zFYCDM1B9Q8Z+ue0o0XeejCWEp9W6UizfYaKimm+2Kqnzrh4xxxfT PLvKAXJXUYAH7fQORnH0IoKqYOeNr2gR0yO8D0s2Y6Hb617TgyOk3KMnsKeocVopWcI3 pTW3HXTq0lYZ3t2RYZ0bRgqaSUBfzyBUpN3nsooR/AHbSSdJTwBejnTKT/kETZhAdSKi B+q7MJoj3lZa9vgaGDNY0Nh3HLdpiHaryafbhfcBSGTRjD1u0jtROzzO3PCzarOWEz39 3/mTwkEpzAKMH2uyrao9K63tK/S4FwuSorh8wNwi6MGt+sKzhjafgCsJTBw2zuO+jQ0A ViqA== X-Gm-Message-State: AFeK/H2j8xWzdpfMklMfYK1I95C/QkfDBYOIRS7yyBJeqiOHw1UdsVH+qwxO6fjZCasdUdsg X-Received: by 10.223.161.220 with SMTP id v28mr1357543wrv.54.1490902605474; Thu, 30 Mar 2017 12:36:45 -0700 (PDT) Received: from xps13.localnet (184.203.134.77.rev.sfr.net. [77.134.203.184]) by smtp.gmail.com with ESMTPSA id x127sm58338wmf.31.2017.03.30.12.36.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Mar 2017 12:36:44 -0700 (PDT) From: Thomas Monjalon To: =?ISO-8859-1?Q?Ga=EBtan?= Rivet Cc: "Van Haaren, Harry" , dev@dpdk.org, "Richardson, Bruce" Date: Thu, 30 Mar 2017 21:36:43 +0200 Message-ID: <2981401.fEuT21do2s@xps13> User-Agent: KMail/4.14.10 (Linux/4.5.4-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: References: <1490701917-17089-1-git-send-email-gaetan.rivet@6wind.com> <20170328124409.GC7450@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 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: Thu, 30 Mar 2017 19:36:46 -0000 2017-03-28 13:02, Van Haaren, Harry: > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Ga=EBtan Rivet= > > 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 capt= uring > > >> devices that could be used for management or otherwise. > > >> The whitelist mode offers users more control and highlight mista= kes by > > >> making them visible on the command line. > > >> > > >> This is more useful to have a clear idea of the state of the sys= tem used, > > >> which is better in the context of standalone / headless applicat= ions. > > >> > > >> 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 i= t > > >mandatory to use port parameters where before it was not. The one > > >suggestion I will make is that, if we take this approach, we shoul= d > > >probably add a --wl-all (whitelist-all) flag to go back to having = all > > >ports automatically bound, if so desired. > > > > >=20 > > 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. > >=20 > > 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 a= n > > argument to -w, which would have our users using -wall or -w=3Dall,= which > > seems clear enough. >=20 >=20 > If I understand correctly an app that runs without any port parameter= s to EAL would now fail to find any ports? >=20 > That would result in; > - testing frameworks (DTS, fd.io perf lab, customers, etc) would fail= if not specifying ports > - beginners just running ./app/testpmd would need to specify the "mag= ic" -w-all > - confusion about why previously working DPDK apps are now failing du= e to not finding any devices >=20 > I'm not totally opposed, but we should consider carefully what impact= s this change will have across the whole DPDK ecosystem, and if the cha= nge is worth it. If decided that "Yes its worth it", we would need to c= ommunicate this change very clearly. All documentation regarding runnin= g any DPDK app would need to be updated as part of this change. >=20 > Personally I don't see the large benefit this patch brings, but more = of a disturbance in the DPDK; I'm open to be convinced otherwise. I agree it is much more a disturbance to change the default behaviour. Both options -b/-w are already available for people who really care. Anyway, the default behaviour should be an application policy. One day, we will have to make all these command line magics optional, and rely on the application implementation.