From mboxrd@z Thu Jan 1 00:00:00 1970 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) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:user-agent:in-reply-to :references:mime-version:content-transfer-encoding; bh=SNMQsAs2VzO/ZkFWmaCLR6wcN0WE7vuqndgQXPKmEEo=; b=N86cmawtKTIFYQtph+8f7opJd5rQeTO6UFK50qV9Zu/F9zwjcRXzznkY8akvxnn+TG nkAlQYJUGMX3XXXqkvn2ro+jT4aTomQowO9CmynLODmKZ2eNau9xEWMwhh/0XBApA+mR 9uaUqbsoUF28NpPwLL1M444K3k0Z+kKu1JpShcoTpaqWaDbv7PW1ZrN68pyIiQ10FlDW QrzP2F2r0pHSyb8BN+0yUhmquWkaqP9oLGuATLmEwCNSXyTfl53izpQHdNCi2ARJmIUf cV9hcTWU3GAeBli0p174spfqBhsdLSr24CK+d3RoAJajZ9/ZZre5hOCgQAE36ONMctWu ahfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:user-agent :in-reply-to:references:mime-version:content-transfer-encoding; bh=SNMQsAs2VzO/ZkFWmaCLR6wcN0WE7vuqndgQXPKmEEo=; b=KGoJ6arofQ42Ej7fRo6rpuKpDspcGLSMRaNy45KizAJJWCPTQNt5kHC0Bpv0RleKfO YAtEzg1MuTsFTYIJhpppaiDNYkEFQMthws3Tsc3nCujbxXR/biS7KmrbuWQDfo1ySgML QJkHtVGK9jp/ydRvvWDtkb3O9nIVQhdzlNDxH+1Kd1U6Fhec5ZpL7HVYWl3KJn+zN5Oq 9VZCsURsSrjNnTtpt13oNTTmG7rcKU8rQODNgBES2nABPtyc6lqDev6Ft7gSSFlcaGhI Rd3sWdgU0+i2cx+C2KcnSgOPHlwNqvQ49LNCCAvnzN6CkYGtJRIJTbIPdPFTa6+iGZbw uq6Q== X-Gm-Message-State: ALyK8tISrjj6uG29iXnpnZKuqU0bw3cN020sSNV5io6jXXxs03OHRw9GkQEu97hkX6NEv9gM X-Received: by 10.28.232.136 with SMTP id f8mr3003357wmi.52.1464776272299; Wed, 01 Jun 2016 03:17:52 -0700 (PDT) Received: from xps13.localnet ([2001:660:330f:38:7e7a:91ff:fe14:f0d2]) by smtp.gmail.com with ESMTPSA id k62sm34108536wmb.7.2016.06.01.03.17.51 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 01 Jun 2016 03:17:51 -0700 (PDT) From: Thomas Monjalon To: Yuanhan Liu Cc: dev@dpdk.org, Bruce Richardson , "Tan, Jianfeng" , Stephen Hemminger , Christian Ehrhardt , Panu Matilainen , Olivier Matz Date: Wed, 01 Jun 2016 12:17:50 +0200 Message-ID: <2257651.YBvHY4sFXa@xps13> User-Agent: KMail/4.14.10 (Linux/4.5.4-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <20160601060454.GJ5641@yliu-dev.sh.intel.com> References: <20160601060454.GJ5641@yliu-dev.sh.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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 10:17:52 -0000 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.