From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id 29C4D5A92 for ; Wed, 1 Jun 2016 17:16:42 +0200 (CEST) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga102.fm.intel.com with ESMTP; 01 Jun 2016 08:16:41 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.26,401,1459839600"; d="scan'208";a="988940493" Received: from yliu-dev.sh.intel.com (HELO yliu-dev) ([10.239.67.162]) by orsmga002.jf.intel.com with ESMTP; 01 Jun 2016 08:16:39 -0700 Date: Wed, 1 Jun 2016 23:19:34 +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: <20160601151934.GN10038@yliu-dev.sh.intel.com> References: <20160601060454.GJ5641@yliu-dev.sh.intel.com> <1678551.cSLFzQVbpG@xps13> <20160601131929.GM10038@yliu-dev.sh.intel.com> <7474094.KBPFc4pl5y@xps13> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7474094.KBPFc4pl5y@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 15:16:42 -0000 On Wed, Jun 01, 2016 at 04:03:07PM +0200, Thomas Monjalon wrote: > 2016-06-01 21:19, Yuanhan Liu: > > 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? > > I like the idea :) Superb! > One important benefit of having only one option is to make easier to rename > in applications to e.g. --dpdk-options and pass the string to the DPDK > parsing function. > I think we must allow several occurences of this new option on the CLI. No idea so far; I'm thinking one should be enough. But I also see no issue when allowing several occurences. Let's recheck it later. > > At the end, the main issue is to find a shiny name for this option ;) You know what, I'm really not good at naming, so might need your help :-) --yliu