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 634522C08 for ; Wed, 1 Jun 2016 16:03:09 +0200 (CEST) Received: by mail-wm0-f50.google.com with SMTP id z87so31011789wmh.0 for ; Wed, 01 Jun 2016 07:03:09 -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=srrnh79RMqZ+JSQEpG8Nx7ldGpPiOmWR3s6C6PHskOQ=; b=0V8haAbKe32qtPXzFTRGz+XS1Xo+xRCkFdc3cDfqNylNtEpjDqj8kGEmJ1oMdqbeyZ FCmh8SNVZQkivdQzTgqrexYJKPHBSsV8WJjUFGzcBFsawrSv7Y5yRwGlgMk43o62rWij yriDutREiX14IHZkiAGU1UhlkXsnCIXuCDQO3HVeTGHuZCOd/ylJJukZrGLHiKc3qlPq tOExU+2Zrmn4iIPrVsJ+RG0aQFqmZdoKOxSxPes/rA6hXqDl8MRn9KH/LFLWI4r9MQmk e2pOe2aFW7omkRN92NFmxwtfOsptDKknlHShINlSzNXQR/53pcXasUCHwxGus8uWJCeQ WHxg== 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=srrnh79RMqZ+JSQEpG8Nx7ldGpPiOmWR3s6C6PHskOQ=; b=B9OjndSVLxd7C3F9316uxIc6E+g2Enhpty5Vsj9M68ZrA2WSFfJJ8I4UkoTXWHDmqF 6QPIV1JKc8AWWszguwEqWmZv/5HvYQ0SNYcekv/ILvhF4a76dvJn8TG5Ywnp2sdmzuoN zhQqGMd0emG+yyhhmbHiwIqEZrJBhENs9et3L50DlFRcOvgWKl6uUWMkBLgyZ5GXMJsP iApanw6PnAmQYf8hl/gAOJiuHK6E9m9Xp5jYBRSySCZU4GtdQPGarNuW5wSXnt5ZhLxi 3kQplLJ4cY4VGkbEURVw5WP/2bCEeM8lDnaB6Mq/MUqAU/Y/Q532GhAypYLqr02oxlbm 0Q4w== X-Gm-Message-State: ALyK8tIXQobdOZtSsX4oQEYxJL4e2txjpCZ1pi6wxQ2OFd8/PeO9gwBLnOA0wxvbOMFb59p/ X-Received: by 10.194.124.200 with SMTP id mk8mr3848845wjb.56.1464789789041; Wed, 01 Jun 2016 07:03:09 -0700 (PDT) Received: from xps13.localnet ([2001:660:330f:38:7e7a:91ff:fe14:f0d2]) by smtp.gmail.com with ESMTPSA id jp2sm45708270wjc.16.2016.06.01.07.03.07 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 01 Jun 2016 07:03:08 -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 16:03:07 +0200 Message-ID: <7474094.KBPFc4pl5y@xps13> User-Agent: KMail/4.14.10 (Linux/4.5.4-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <20160601131929.GM10038@yliu-dev.sh.intel.com> References: <20160601060454.GJ5641@yliu-dev.sh.intel.com> <1678551.cSLFzQVbpG@xps13> <20160601131929.GM10038@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 14:03:09 -0000 2016-06-01 21:19, Yuanhan Liu: > On Wed, Jun 01, 2016 at 02:39:28PM +0200, Thomas Monjalon wrote: > > I was thinking to implement the library options parsing in DPDK. > > But if the application implements its own options parsing without using > > the DPDK one, yes the option parsing is obviously done in the application. > > > > > 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. > > > > What do you suggest instead of PCI id? > > That might depend on what you need: if you want to configure a specific > device, yes, PCI is needed (or even, a must). In such case, the --pciopt > or the side effect of --pci-whitelist could help. I confess this would > be helpful in some cases. > > I guess there is another need is that we might want to pass an option > to a driver, say ixgbe, that would work for all devices operated by it. > In such case, we could use driver name (see the example below). > > > > - 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. > > > > Applications can leverage the DPDK options parsing (without writing > > any new line of code). > > > > > 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. > > > > I agree. I just want to split your --extra-option proposal in few options > > with a bit more context. > > Firstly, the name "--extra-option" might not be well taken :( > I just want to show the idea first. > > Secondly, splitting it to more options would result to quite many > options introduced; it's also hard to list all of them. User intend > to get lost if so many options provided. It also introduces more > chaos, especially when we are going to add one option for each > library. > > For the context issue, I guess we could address it by adding a prefix. > Such as, > > --extra-options (or --whatever) "vhost.owner=kvm:kvm virtio.force_legacy > mempool.handler=xxx" > > Based on that, we could introduce other sematics, to let it be: > > driver.opt | driver.pci_id.opt > > Where, > > - driver.opt > applies to all devices operated by this driver > > - driver.pci_id.opt > applies only to a specific device with the same pci ID. > > This could save us changing the --pci-whitelist sematic, yet it saves > us introducing a new option (--pciopt). > > What do you think of it? I like the idea :) One important benefit of having only one option is to make easier to rename in applications to e.g. --dpdk-options and pass the string to the DPDK parsing function. I think we must allow several occurences of this new option on the CLI. At the end, the main issue is to find a shiny name for this option ;)