[dpdk-dev] [RFC] kernel paramters like DPDK CLI options

[Yuanhan Liu]

On Wed, Jun 01, 2016 at 12:17:50PM +0200, Thomas Monjalon wrote:
> 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

Isn't it just for whitelisting a specific PCI device?

> 	- 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?

> 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.

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'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.

- 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.

  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.

> > 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.

Thanks for making comments :)

	--yliu