From mboxrd@z Thu Jan 1 00:00:00 1970 From: Yerden Zhumabekov Subject: Re: [RFC] kernel paramters like DPDK CLI options Date: Wed, 1 Jun 2016 16:24:34 +0600 Message-ID: <574EB7E2.4030908@sts.kz> References: <20160601060454.GJ5641@yliu-dev.sh.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: yuanhan.liu@linux.intel.com To: dev@dpdk.org Return-path: Received: from mgw.gov.kz (mgw.gov.kz [89.218.88.242]) by dpdk.org (Postfix) with ESMTP id 1A7E72BFE for ; Wed, 1 Jun 2016 12:24:36 +0200 (CEST) In-Reply-To: <20160601060454.GJ5641@yliu-dev.sh.intel.com> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" I recently felt tired enough of specifying various options for EAL, so I came up to use ini-based configuration. EAL parameters from dedicated section of ini file are parsed to argv array which is subsequently fed to rte_eal_init(). Quite handy, but maybe a little overkill. On 01.06.2016 12:04, Yuanhan Liu wrote: > 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". > > 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" > > 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? > > --yliu