From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id E37075AA7 for ; Wed, 1 Jun 2016 13:38:02 +0200 (CEST) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga103.fm.intel.com with ESMTP; 01 Jun 2016 04:38:02 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.26,400,1459839600"; d="scan'208";a="988794333" Received: from yliu-dev.sh.intel.com (HELO yliu-dev) ([10.239.67.162]) by orsmga002.jf.intel.com with ESMTP; 01 Jun 2016 04:38:00 -0700 Date: Wed, 1 Jun 2016 19:40:54 +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: <20160601114054.GK10038@yliu-dev.sh.intel.com> References: <20160601060454.GJ5641@yliu-dev.sh.intel.com> <2257651.YBvHY4sFXa@xps13> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2257651.YBvHY4sFXa@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 11:38:03 -0000 On Wed, Jun 01, 2016 at 12:17:50PM +0200, Thomas Monjalon wrote: > Hi, > > 2016-06-01 14:04, Yuanhan Liu: > > Hi all, > > > > I guess we (maybe just me :) have stated few times something like > > "hey, this kind of stuff is good to have, but you are trying to > > add an EAL CLI option for a specific subsystem/driver, which is > > wrong". > > Yes > > > One recent example that is still fresh in my mind is the one from > > Christian [0], that he made a proposal to introduce two new EAL > > options, --vhost-owner and --vhost-perm, to configure the vhost > > user socket file permission. > > > > [0]: http://dpdk.org/ml/archives/dev/2016-April/037948.html > > > > Another example is the one I met while enabling virtio 1.0 support. > > QEMU has the ability to support both virtio 0.95 (legacy) and 1.0 > > (modern) at the same time for one virtio device, therefore, we > > could either use legacy driver or modern driver to operate the > > device. However, the current logic is we try with modern driver > > first, and then legacy driver if it failed. In above case, we will > > never hit the legacy driver. But sometimes, it's nice to let it > > force back to the legacy driver, say, for debug or compare purpose. > > > > Apparently, adding a new EAL option like "--force-legacy" looks > > wrong. > > > > The generic yet elegant solution I just thought of while having > > lunch is to add a new EAL option, say, --extra-options, where we > > could specify driver/subsystem specific options. As you see, it's > > nothing big deal, it just looks like Linux kernel parameters. > > > > Take above two cases as example, it could be: > > > > --extra-options "vhost-owner=kvm:kvm force-legacy" > > I think it's better to have CLI options per device. > Currently we can pass devargs > - to PCI device via --pci-whitelist Isn't it just for whitelisting a specific PCI device? > - to virtual device via --vdev Yes, --vdev works great here. However, as its name states, it's just for virtual devices. Say, it will not work for virtio PMD, the force-legacy option mentioned above. > I think we just need to refactor these options to have a generic > --device or keep the options in --vdev and add a new --pciopt > or something like that. --pciopt should be able to allow us pass more options to a specific driver. But what about a library, say vhost? > And more importantly, these devargs must be set via a new EAL API > to allow applications do these configurations without building/faking > some command line arguments. > > To make it clear, applications use API and users use CLI (which call API). I would agree with that. But that basically works for library; it does not quite make sense to me to introduce a new API for some a driver option, such as the force-legacy option for virtio PMD. So, let me make a summary from reading your email, to make sure I get you right: for drivers (virtual or physical), we could use --vdev or --pciopt for passing args, respectively. For the libraries, we should add a new API, and let the application to introduce some options to invoke it, to pass the options. 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. - 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. 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. > > Note that those options could also be delimited by comma. > > > > DPDK EAL then will provide some generic helper functions to get > > and parse those options, and let the specific driver/subsystem > > to invoke them to do the actual parse and do the proper action > > when some option is specified, say, virtio PMD driver will force > > back to legacy driver when "force-legacy" is given. > > > > Comments? Makes sense to you guys, or something nice to have? > > Thanks for starting the discussion. Thanks for making comments :) --yliu