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

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

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.