From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by dpdk.org (Postfix) with ESMTP id B677FD0FC for ; Tue, 28 Mar 2017 15:02:17 +0200 (CEST) Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga105.fm.intel.com with ESMTP; 28 Mar 2017 06:02:16 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.36,236,1486454400"; d="scan'208";a="80171839" Received: from irsmsx108.ger.corp.intel.com ([163.33.3.3]) by orsmga005.jf.intel.com with ESMTP; 28 Mar 2017 06:02:15 -0700 Received: from irsmsx102.ger.corp.intel.com ([169.254.2.153]) by IRSMSX108.ger.corp.intel.com ([169.254.11.239]) with mapi id 14.03.0319.002; Tue, 28 Mar 2017 14:02:13 +0100 From: "Van Haaren, Harry" To: =?iso-8859-1?Q?Ga=EBtan_Rivet?= CC: "dev@dpdk.org" , Thomas Monjalon , "Richardson, Bruce" Thread-Topic: [dpdk-dev] [PATCH v2 1/1] pci: default to whitelist mode Thread-Index: AQHSp7svkSUfQXOqIEWbu8YNyPr5saGqGwMAgAAGv4CAABKcwA== Date: Tue, 28 Mar 2017 13:02:13 +0000 Message-ID: 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> In-Reply-To: <20170328124409.GC7450@bidouze.vm.6wind.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiYjc0NGI4MTctMTc0MS00Mjc1LWJiNzQtZDNiNzJkNjM5MjNiIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX1BVQkxJQyJ9XX1dfSwiU3ViamVjdExhYmVscyI6W10sIlRNQ1ZlcnNpb24iOiIxNS45LjYuNiIsIlRydXN0ZWRMYWJlbEhhc2giOiJTblZLTjRqRUdNaU42NjkrWHExSk1Gb3g0aEhWV1p6MjRSN0JsQklRMVpJPSJ9 x-ctpclassification: CTP_PUBLIC x-originating-ip: [163.33.239.182] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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:02:18 -0000 > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Ga=EBtan Rivet > Sent: Tuesday, March 28, 2017 1:44 PM > To: Richardson, Bruce > Cc: dev@dpdk.org; Thomas Monjalon > Subject: Re: [dpdk-dev] [PATCH v2 1/1] pci: default to whitelist mode >=20 > 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 us= ed, > >> 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. > > >=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 an > argument to -w, which would have our users using -wall or -w=3Dall, which > seems clear enough. If I understand correctly an app that runs without any port parameters to E= AL would now fail to find any ports? That would result in; - testing frameworks (DTS, fd.io perf lab, customers, etc) would fail if no= t specifying ports - beginners just running ./app/testpmd would need to specify the "magic" -w= -all - confusion about why previously working DPDK apps are now failing due to n= ot finding any devices I'm not totally opposed, but we should consider carefully what impacts this= change will have across the whole DPDK ecosystem, and if the change is wor= th it. If decided that "Yes its worth it", we would need to communicate thi= s change very clearly. All documentation regarding running any DPDK app wou= ld need to be updated as part of this change. Personally I don't see the large benefit this patch brings, but more of a d= isturbance in the DPDK; I'm open to be convinced otherwise. > This would essentially be the inverse of the > --no-pci parameter. >=20 > Which could probably be removed if this patch is accepted. >=20 > -- > Ga=EBtan Rivet > 6WIND