From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Monjalon Subject: Re: [RFC] kernel paramters like DPDK CLI options Date: Wed, 01 Jun 2016 12:17:50 +0200 Message-ID: <2257651.YBvHY4sFXa@xps13> References: <20160601060454.GJ5641@yliu-dev.sh.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit Cc: dev@dpdk.org, Bruce Richardson , "Tan, Jianfeng" , Stephen Hemminger , Christian Ehrhardt , Panu Matilainen , Olivier Matz To: Yuanhan Liu Return-path: Received: from mail-wm0-f50.google.com (mail-wm0-f50.google.com [74.125.82.50]) by dpdk.org (Postfix) with ESMTP id 965865A53 for ; Wed, 1 Jun 2016 12:17:52 +0200 (CEST) Received: by mail-wm0-f50.google.com with SMTP id n184so23803018wmn.1 for ; Wed, 01 Jun 2016 03:17:52 -0700 (PDT) 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" 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 - to virtual device via --vdev 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. 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). > 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.