Re: [dpdk-dev] [RFC] Yet another option for DPDK options

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

Hi Keith,

I'll try to bring more context to this discussion below.

2016-06-01 15:00, Wiles, Keith:
> Started from the link below, but did not want to highjack the thread.
> http://dpdk.org/ml/archives/dev/2016-June/040021.html
> 
> I was thinking about this problem from a user perspective and command
> line options are very difficult to manage specifically when you have
> a large number of options as we have in dpdk.

The user uses an application.
It is up to the application to let users do some configuration.

> I see all of these options as a type of database of information for
> the DPDK and the application, because the application command line
> options are also getting very complex as well.

DPDK is a collection of libraries.
There is no command line options in a library.
So we should not be talking about such issue. But...

... configuration of the DPDK libraries must be improved.
We need some clean API to let the application configure a lot of things
at runtime (during initialization or after).
Ideally the API should not use an argc/argv format.

We also have a lot of applications for tests or examples which use a
common configuration scheme based on command line options.
It is only for test and demonstration purpose. So it is not so important
and must not be complex to maintain.
I also think that we should avoid having to modify a configuration file
for test applications. I like launching a freshly built testpmd with a
copy-pasted command line without having to create a temporary
configuration file.

Instead of wrapping a messy configuration interface, we should proceed
with this steps (in this order):
- implement clean configuration API
- move command line options parsing in a separate library
- implement an alternative to the options parsing library, as an example
- remove the options parsing library if the alternative is better