From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pavan Nikhilesh Subject: Re: [PATCH v2] eal/devargs: add option to supply PCI dev args Date: Tue, 10 Jul 2018 15:49:47 +0530 Message-ID: <20180710101946.GB30393@ltp-pvn> References: <20180615044359.20692-1-pbhagavatula@caviumnetworks.com> <20180627083959.cqyq2bwwuz3z7vof@bidouze.vm.6wind.com> <20180627085529.GA14236@ltp-pvn> <20180627095736.jty7lbqesxufwiby@bidouze.vm.6wind.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: dev@dpdk.org To: =?iso-8859-1?Q?Ga=EBtan?= Rivet , Shahaf Shuler , "jerin.jacob@caviumnetworks.com" , Thomas Monjalon , Ferruh Yigit Return-path: Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0046.outbound.protection.outlook.com [104.47.33.46]) by dpdk.org (Postfix) with ESMTP id B64BD5F3B for ; Tue, 10 Jul 2018 12:20:07 +0200 (CEST) Content-Disposition: inline In-Reply-To: <20180627095736.jty7lbqesxufwiby@bidouze.vm.6wind.com> List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Hi Gaëtan,Ferruh, On Wed, Jun 27, 2018 at 11:57:36AM +0200, Gaëtan Rivet wrote: > On Wed, Jun 27, 2018 at 02:25:30PM +0530, Pavan Nikhilesh wrote: > > Hi Gaëtan, > > > > On Wed, Jun 27, 2018 at 10:39:59AM +0200, Gaëtan Rivet wrote: > > > Hi Ferruh, Pavan, > > > > > > sorry for the delay, > > > > > > On Tue, Jun 26, 2018 at 04:40:21PM +0100, Ferruh Yigit wrote: > > > > On 6/26/2018 1:48 PM, Shahaf Shuler wrote: > > > > > Hi Pavan, > > > > > > > > > > Friday, June 15, 2018 7:44 AM, Pavan Nikhilesh: > > > > >> Subject: [dpdk-dev] [PATCH v2] eal/devargs: add option to supply PCI dev > > > > >> args > > > > >> > > > > >> Currently, the only way of supplying device argument to a pci device is to > > > > >> whitelist it i.e. -w 000X:00:0X.0,self_test=1. This is not a very feasible method > > > > >> as whitelisting a device has its own side effects i.e only the whitelisted pci > > > > >> devices are probed. > > > > >> > > > > >> Add a new eal command line option --pci-args to pass device args without the > > > > >> need to whitelist the devices. > > > > >> --pci-args 000X:00:0X.0,self_test=1 > > > > >> > > > > >> Signed-off-by: Pavan Nikhilesh > > > > > > > > > > Tested-by: Shahaf Shuler > > > > > > > > > > It seems to work. > > > > > Please see small comments below > > > > > > > > Isn't this conflict with Gaetan's devarg work which has wider scope? > > > > > > > > > > Indeed it does. > > > > > > Pavan, I have submitted a new version of a series adding generic kvargs > > > to several layers (bus, class, driver). > > > > > > It does cover this exact use-case. > > > > > > However, while writing it, I wasn't able to find PCI bus specific > > > parameters, that could showcase the functionality. > > > > The idea of the patch is to avoid whitelising a device when we want to > > supply kvargs to it, I tried mapping it to devargs rework patchset but couldn't > > do it at a glance. For example, the following patch[1] reads kvargs through > > whitelisting which should be avoided. > > > > [1]http://patches.dpdk.org/patch/41223/ > > > > I see. > > Actually, your use-case won't be covered by the devargs rework. > > I am still dumbfounded by how this blacklist/whitelist mode stuff is > kept against all odds. But that's not the time to deal with it. > > The issue is that the two features "declaring a device" and > "configuring a bus" are currently awkwardly merged. You are piling stuff > on the "declaring a device" part to enhance the "configuring a bus" > feature. The feature is very much needed to avoid polluting the cmdline args when we are trying to configure a device at probe (for now). > > Instead of going this way, I would advise to separate the two features. > > If buses could be configured with a generic EAL option > "--blacklist=pci,vdev" for example, then you could provide devargs as > much as you want, the buses themselves would stay properly configured. > > This means removing devargs policy, device types and rewriting bus logic > about it. I think this can be done as a future work and is not in the scope of this patch. @Ferruh, As Gaëtan mentioned this patch is not related to devargs rework can we make some forward progress. > > Regards, > -- > Gaëtan Rivet > 6WIND Thanks, Pavan.