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 492A0200 for ; Mon, 16 Jul 2018 00:25:41 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 82CC221B52; Sun, 15 Jul 2018 18:25:40 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Sun, 15 Jul 2018 18:25:40 -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=l2EKD7uwsa7X9HhG/CnGqScF8Z pwOmMY5hltI+xo4jY=; b=XhKycwYaIcCbLUYEqf0l5/SQC7NONMoCPYy5XkK/2D y27LOfq6HYYB+wWV9Saf1eTCELjGMGlR18U6ITAKLvai0p84nINW5gII8D7T7SK6 7eg7F9kKejz/T/sZND8rV9jjvTpjbSh6fixRSH9wxE/WqkESIIPgj6ON886hMUZk o= 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=l2EKD7 uwsa7X9HhG/CnGqScF8ZpwOmMY5hltI+xo4jY=; b=vGKHZ8wxpITWPRVcva3Foa MT/b7JAfnTlukoRSX4RZQTN6yQZGIdPEkYBkywxItADFWbTVFZ6sZuFJXpoojMSs Z8hzc5wU6GTlyllllJ+teYBrbQYq8IuGTexnZFELugJGrt4ICsGBS+R1AIA8p97D 3ZWXx6hcjxyKANfQZGcX2qDpWWzo/VlP3JZH5S090bVMHXIOM3M9SCB7bHP29h+X R9UnX3yVKD8Yo3e92YRLDbdmea+LD2IgzEEPgW9q43U6+HIkQ9ooJJoKBpSBlRRT NkGtGF5RtrLhq0g5lWqUnmmThBQQEZHRE/9dlsC+TmYTS40M5OrpOgcIGSJbquLw == X-ME-Proxy: X-ME-Sender: Received: from xps.localnet (unknown [31.154.190.114]) by mail.messagingengine.com (Postfix) with ESMTPA id 55FE810261; Sun, 15 Jul 2018 18:25:38 -0400 (EDT) From: Thomas Monjalon To: Pavan Nikhilesh Cc: dev@dpdk.org, =?ISO-8859-1?Q?Ga=EBtan?= Rivet , Shahaf Shuler , "jerin.jacob@caviumnetworks.com" , Ferruh Yigit Date: Mon, 16 Jul 2018 00:25:29 +0200 Message-ID: <11431324.P0YfK9v5sK@xps> In-Reply-To: <20180710101946.GB30393@ltp-pvn> References: <20180615044359.20692-1-pbhagavatula@caviumnetworks.com> <20180627095736.jty7lbqesxufwiby@bidouze.vm.6wind.com> <20180710101946.GB30393@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: Sun, 15 Jul 2018 22:25:41 -0000 10/07/2018 12:19, Pavan Nikhilesh: > Hi Ga=EBtan,Ferruh, >=20 > 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 supp= ly 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 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 ar= gs 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 sco= pe? > > > > > > > > > > > > > Indeed it does. > > > > > > > > Pavan, I have submitted a new version of a series adding generic kv= args > > > > 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 bu= t couldn't > > > do it at a glance. For example, the following patch[1] reads kvargs t= hrough > > > 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. >=20 > The feature is very much needed to avoid polluting the cmdline args when = we are > trying to configure a device at probe (for now). >=20 > > > > Instead of going this way, I would advise to separate the two features. > > > > If buses could be configured with a generic EAL option > > "--blacklist=3Dpci,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. >=20 > I think this can be done as a future work and is not in the scope of this > patch. >=20 > @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.