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 BAEB5379B for ; Wed, 1 Jun 2016 08:02:05 +0200 (CEST) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga103.jf.intel.com with ESMTP; 31 May 2016 23:02:06 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.26,399,1459839600"; d="scan'208";a="978439431" Received: from yliu-dev.sh.intel.com (HELO yliu-dev) ([10.239.67.162]) by fmsmga001.fm.intel.com with ESMTP; 31 May 2016 23:02:03 -0700 Date: Wed, 1 Jun 2016 14:04:54 +0800 From: Yuanhan Liu To: dpdk Cc: Thomas Monjalon , Bruce Richardson , "Tan, Jianfeng" , Stephen Hemminger , Christian Ehrhardt , Panu Matilainen , Olivier Matz Message-ID: <20160601060454.GJ5641@yliu-dev.sh.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) Subject: [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 06:02:06 -0000 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