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 ;)
