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

[Thomas Monjalon <thomas.monjalon@6wind.com>]

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.