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
