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

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

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

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