From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f42.google.com (mail-wm0-f42.google.com [74.125.82.42]) by dpdk.org (Postfix) with ESMTP id 2E71E3989 for ; Wed, 1 Jun 2016 14:39:31 +0200 (CEST) Received: by mail-wm0-f42.google.com with SMTP id a136so180129335wme.0 for ; Wed, 01 Jun 2016 05:39:31 -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=velpz9gVRGsEin9G+WgiMVaPSeJtzRlZy4C7bkNzLL4=; b=YVu2h4oFsBfmUXbNk1RHgFylRWwfpF8KqImwm64/H2WUkw2eMJuDQT9pzTLwC6LHlD 5p7ayU+GT/T5Dr4hDlNr+Cp/MD4bwVpkXro3WZSAULtPsu++FNl5Ib20D18tiiAYHy92 vyKjtNkP4cTAWabijbN9A1ABkAtAjoSAWr00WcGcU3udY+ijojvKtsxe3xW7pBKQ4Hi8 u6MNnE+k05xzgPzCmxBz+lMQvYI4nuhcwJM/Ed25MKKlPKQlPIJijyqNXnZqYZMwjI4e kzUazn5nj89wdtVRSY16rbm4PECtHNR/9BxN3uR5kcCUAu2YvKBbEGvmNGn5uaDq1+EC H84w== 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=velpz9gVRGsEin9G+WgiMVaPSeJtzRlZy4C7bkNzLL4=; b=NEJ3Wtu/OdRIna/HZvKec2haSWTH4T5A6D9FiAKGx51VpRdhDS5TuoeP4STGAlW6F/ igbjgIrrd4BqCBI5iPEN0nAVcUq36K92g09tqLu6KqhSHr8V5vGUGRJXNcU6xaaVgR8t GNNaOWFymtHaGCi3Oeco060f5Q0wLLTJh38dzOac6gLoEVEbiEtMZtCWfs+XbPyARtXV +1JNAMJqMpceyJVjRarCHADjM3c88rIz9KHhG960KukpyWQ+1dfS1BQtrlRDYUilUoDc ITNBIJjssNrNKcW2pKJJcGIEvJF5YgTzmgSF91FtivbFbIZH0W9DzPL/cMi37n+Wesw/ BnCw== X-Gm-Message-State: ALyK8tLiwMsOn2rIBMlGFulfyp/F+qayorRSS3X6MFRXmHBvdUMUbgcWduqIHYSTckKgx8+5 X-Received: by 10.28.217.72 with SMTP id q69mr20673272wmg.81.1464784770830; Wed, 01 Jun 2016 05:39:30 -0700 (PDT) Received: from xps13.localnet ([2001:660:330f:38:7e7a:91ff:fe14:f0d2]) by smtp.gmail.com with ESMTPSA id i1sm45476277wjm.12.2016.06.01.05.39.29 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 01 Jun 2016 05:39:29 -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 14:39:28 +0200 Message-ID: <1678551.cSLFzQVbpG@xps13> User-Agent: KMail/4.14.10 (Linux/4.5.4-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <20160601114054.GK10038@yliu-dev.sh.intel.com> References: <20160601060454.GJ5641@yliu-dev.sh.intel.com> <2257651.YBvHY4sFXa@xps13> <20160601114054.GK10038@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 12:39:31 -0000 2016-06-01 19:40, Yuanhan Liu: > On Wed, Jun 01, 2016 at 12:17:50PM +0200, Thomas Monjalon wrote: > > 2016-06-01 14:04, Yuanhan Liu: > > > 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. Sorry I was just talking about per-device options, not libraries. We may also talk about driver options. So we end up with 4 kind of options: - device options - driver options - other EAL options - library options It is not clear what the scope of the --extra-options would be. We already have EAL options (without specific name or prefix) and vdev options. I suggest to add - PCI options - driver options (if it makes sense) - library options > > Currently we can pass devargs > > - to PCI device via --pci-whitelist > > Isn't it just for whitelisting a specific PCI device? Yes it is. As a side effect, it allows to pass some devargs. > > - to virtual device via --vdev > > Yes, --vdev works great here. However, as its name states, it's > just for virtual devices. Say, it will not work for virtio PMD, > the force-legacy option mentioned above. > > > 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. > > --pciopt should be able to allow us pass more options to a specific > driver. But what about a library, say vhost? For libraries we can have some specific options. Should it be prefixed like --mempool:handler=fifo or without prefix (like EAL options): --mempool-handler=fifo. This first choice makes easier to parse every mempool options inside the library. > > 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). > > I would agree with that. But that basically works for library; it does > not quite make sense to me to introduce a new API for some a driver > option, such as the force-legacy option for virtio PMD. For drivers, the API must be something like: devargs_set(port_id, char*) or devargs_add(port_id, char*) So it is generic for every driver-specific options. There is already rte_eal_devargs_add() but it probably needs to be reworked. > So, let me make a summary from reading your email, to make sure I get > you right: for drivers (virtual or physical), we could use --vdev or > --pciopt for passing args, respectively. For the libraries, we should > add a new API, and let the application to introduce some options to > invoke it, to pass the options. 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? > - 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.