From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by dpdk.org (Postfix) with ESMTP id E2743201 for ; Mon, 16 Jul 2018 14:14:29 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 3063221CE1; Mon, 16 Jul 2018 08:14:29 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Mon, 16 Jul 2018 08:14:29 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=mesmtp; bh=cLZ79xYOPyYCgGE2IsA/ZbE9Gr Vz8aQdfrHcT6UfajI=; b=mXOjQwAHz3Zl9XuIVHkahd1LXQ3GbDlyrm1RtH5QA4 LXlzs1WtQKyUs8glm1/0w/Eh89H+9K0CTicH5VEGtpu9oxOwg82okPseqgk3AfCV SWn7wy8Fok/WMN09cMPTDnES/RRD0knsQ5IfSxadK6LX/nm10MeOsXUQ0dr/TcyR M= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=cLZ79x YOPyYCgGE2IsA/ZbE9GrVz8aQdfrHcT6UfajI=; b=sGRpWqEQp6+QzDkLWNGvF2 flNyG4mF4MyhA6pWnvdbs3OOEeMg/g7hVLO2l0eOjjE4GdfnVifT6xBXytWKu49p SHn4HaYx7KdmVpt9stBdwO2isXz9ka5QOEIcIXEmRPWbdufa0cr5D2jk2BXBY2PD QGwnKZmrXOETOa89OV2F3fhS/0d9mIvCgaR/Dz5KwBJWCmp541MAf71sS/NrZflK /Jgq/9yxYotQoQJJMsM5d5tCviP3A9uMu0a7Qygj/vmOsemSK4s+GNzx67pd+Tr2 VND8HqhfKfxINcr+MjN2U5XXcWZkrgNe68M9suw6xniXJ5Yl5tUucR1d6EsP7xCw == X-ME-Proxy: X-ME-Sender: Received: from xps.localnet (unknown [193.47.165.251]) by mail.messagingengine.com (Postfix) with ESMTPA id 87AB01025D; Mon, 16 Jul 2018 08:14:27 -0400 (EDT) From: Thomas Monjalon To: Pavan Nikhilesh Cc: =?ISO-8859-1?Q?Ga=EBtan?= Rivet , Shahaf Shuler , "jerin.jacob@caviumnetworks.com" , Ferruh Yigit , dev@dpdk.org Date: Mon, 16 Jul 2018 14:14:25 +0200 Message-ID: <5892149.yHDs5QQrxV@xps> In-Reply-To: <20180716110550.GA32313@ltp-pvn> References: <20180615044359.20692-1-pbhagavatula@caviumnetworks.com> <11431324.P0YfK9v5sK@xps> <20180716110550.GA32313@ltp-pvn> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Subject: Re: [dpdk-dev] [PATCH v2] eal/devargs: add option to supply PCI dev args 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: Mon, 16 Jul 2018 12:14:30 -0000 16/07/2018 13:05, Pavan Nikhilesh: > On Mon, Jul 16, 2018 at 12:25:29AM +0200, Thomas Monjalon wrote: > > External Email > > > > 10/07/2018 12:19, Pavan Nikhilesh: > > > Hi Ga=EBtan,Ferruh, > > > > > > On Wed, Jun 27, 2018 at 11:57:36AM +0200, Ga=EBtan Rivet wrote: > > > > On Wed, Jun 27, 2018 at 02:25:30PM +0530, Pavan Nikhilesh wrote: > > > > > Hi Ga=EBtan, > > > > > > > > > > On Wed, Jun 27, 2018 at 10:39:59AM +0200, Ga=EBtan 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=3D1. This is n= ot 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 devic= e args without the > > > > > > > >> need to whitelist the devices. > > > > > > > >> --pci-args 000X:00:0X.0,self_test=3D1 > > > > > > > >> > > > > > > > >> 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 generi= c 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 specif= ic > > > > > > parameters, that could showcase the functionality. > > > > > > > > > > The idea of the patch is to avoid whitelising a device when we wa= nt to > > > > > supply kvargs to it, I tried mapping it to devargs rework patchse= t but couldn't > > > > > do it at a glance. For example, the following patch[1] reads kvar= gs 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 w= hen we are > > > trying to configure a device at probe (for now). > > > > > > > > > > > Instead of going this way, I would advise to separate the two featu= res. > > > > > > > > If buses could be configured with a generic EAL option > > > > "--blacklist=3Dpci,vdev" for example, then you could provide devarg= s as > > > > much as you want, the buses themselves would stay properly configur= ed. > > > > > > > > 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=EBtan mentioned this patch is not related to devargs rework can= we make > > > some forward progress. > > > > No, we should not add a new parameter just to fix one use case for one = bus. > > The work of Gaetan is opening the door to a generic syntax which can be > > used for device matching (like for whitelisting), or for settings > > (what you need) of any bus, any device class or any driver. > > We can discuss about which option to add for generic device settings, > > and whether or not it should be mixed with whitelisting, > > but please let's work on a generic solution. >=20 > Ok, I guess this can be taken up once Ga=EBtan devarsg patches are comple= tely > merged. If we split the work into a smaller list we could load balance the > work and work towards 18.11?. Yes, we must split and share the work. Some patches from Gaetan are in 18.08 in order to provide some parsing help= ers. What we must do next: =2D implement identification by bus properties =2D implement identification by device class properties =2D choose how we want to manage whitelist/blacklist =2D choose syntax to set some properties (to be used by API or command line= or config file)