From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id 098FC5A9C for ; Wed, 1 Jun 2016 15:16:37 +0200 (CEST) Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by orsmga103.jf.intel.com with ESMTP; 01 Jun 2016 06:16:35 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.26,401,1459839600"; d="scan'208";a="114117125" Received: from yliu-dev.sh.intel.com (HELO yliu-dev) ([10.239.67.162]) by fmsmga004.fm.intel.com with ESMTP; 01 Jun 2016 06:16:34 -0700 Date: Wed, 1 Jun 2016 21:19:29 +0800 From: Yuanhan Liu To: Thomas Monjalon Cc: dev@dpdk.org, Bruce Richardson , "Tan, Jianfeng" , Stephen Hemminger , Christian Ehrhardt , Panu Matilainen , Olivier Matz Message-ID: <20160601131929.GM10038@yliu-dev.sh.intel.com> References: <20160601060454.GJ5641@yliu-dev.sh.intel.com> <2257651.YBvHY4sFXa@xps13> <20160601114054.GK10038@yliu-dev.sh.intel.com> <1678551.cSLFzQVbpG@xps13> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1678551.cSLFzQVbpG@xps13> User-Agent: Mutt/1.5.23 (2014-03-12) Subject: Re: [dpdk-dev] [RFC] kernel paramters like DPDK CLI options X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 13:16:38 -0000 On Wed, Jun 01, 2016 at 02:39:28PM +0200, Thomas Monjalon wrote: > I was thinking to implement the library options parsing in DPDK. > But if the application implements its own options parsing without using > the DPDK one, yes the option parsing is obviously done in the application. > > > I'd say, that would work, but I see inflexibility and some drawbacks: > > > > - I would assume "--pciopt" has the input style of > > > > "domain:bus:devid:func,option1,option2,..." > > > > It then looks hard to me to use it: I need figure out the > > pci id first. > > What do you suggest instead of PCI id? That might depend on what you need: if you want to configure a specific device, yes, PCI is needed (or even, a must). In such case, the --pciopt or the side effect of --pci-whitelist could help. I confess this would be helpful in some cases. I guess there is another need is that we might want to pass an option to a driver, say ixgbe, that would work for all devices operated by it. In such case, we could use driver name (see the example below). > > - For the libraries, we have to write code to add new options for > > each applictions. With the generic option, user just need use it; > > don't need write a single line of code, which could save user's > > effort. It also gives user an united interface. > > Applications can leverage the DPDK options parsing (without writing > any new line of code). > > > And to make it clear, as stated, I don't object to having an API. > > I mean, the generic option gives us a chance to do the right > > configuration at startup time: it would still invoke the right > > API to do the right thing in the end. > > I agree. I just want to split your --extra-option proposal in few options > with a bit more context. Firstly, the name "--extra-option" might not be well taken :( I just want to show the idea first. Secondly, splitting it to more options would result to quite many options introduced; it's also hard to list all of them. User intend to get lost if so many options provided. It also introduces more chaos, especially when we are going to add one option for each library. For the context issue, I guess we could address it by adding a prefix. Such as, --extra-options (or --whatever) "vhost.owner=kvm:kvm virtio.force_legacy mempool.handler=xxx" Based on that, we could introduce other sematics, to let it be: driver.opt | driver.pci_id.opt Where, - driver.opt applies to all devices operated by this driver - driver.pci_id.opt applies only to a specific device with the same pci ID. This could save us changing the --pci-whitelist sematic, yet it saves us introducing a new option (--pciopt). What do you think of it? --yliu