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

[Yuanhan Liu]

On Wed, Jun 01, 2016 at 02:39:28PM +0200, Thomas Monjalon wrote:
> 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?

That might depend on what you need: if you want to configure a specific
device, yes, PCI is needed (or even, a must). In such case, the --pciopt
or the side effect of --pci-whitelist could help. I confess this would
be helpful in some cases.

I guess there is another need is that we might want to pass an option
to a driver, say ixgbe, that would work for all devices operated by it.
In such case, we could use driver name (see the example below).

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

Firstly, the name "--extra-option" might not be well taken :(
I just want to show the idea first.

Secondly, splitting it to more options would result to quite many
options introduced; it's also hard to list all of them. User intend
to get lost if so many options provided. It also introduces more
chaos, especially when we are going to add one option for each
library.

For the context issue, I guess we could address it by adding a prefix.
Such as,

    --extra-options (or --whatever) "vhost.owner=kvm:kvm virtio.force_legacy
                                     mempool.handler=xxx"

Based on that, we could introduce other sematics, to let it be:

    driver.opt | driver.pci_id.opt

Where,

- driver.opt
  applies to all devices operated by this driver

- driver.pci_id.opt
  applies only to a specific device with the same pci ID.

This could save us changing the --pci-whitelist sematic, yet it saves
us introducing a new option (--pciopt).

What do you think of it?

	--yliu