Re: [RFC] kernel paramters like DPDK CLI options

[Yuanhan Liu <yuanhan.liu@linux.intel.com>]

On Wed, Jun 01, 2016 at 04:03:07PM +0200, Thomas Monjalon wrote:
> 2016-06-01 21:19, 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?
> 
> I like the idea :)

Superb!

> One important benefit of having only one option is to make easier to rename
> in applications to e.g. --dpdk-options and pass the string to the DPDK
> parsing function.
> I think we must allow several occurences of this new option on the CLI.

No idea so far; I'm thinking one should be enough. But I also see no
issue when allowing several occurences. Let's recheck it later.

> 
> At the end, the main issue is to find a shiny name for this option ;)

You know what, I'm really not good at naming, so might need your
help :-)

	--yliu