On 6/2/16, 8:19 AM, "Thomas Monjalon" <thomas.monjalon at 6wind.com> wrote:
>2016-06-02 06:41, Neil Horman: >> I'm not sure why you're focusing no selecting a config file format at all. >> Why The reason is I am on now looking at formats is because I have been thinking about this issue for some time and already understand your comments. I agree with you and Thomas, which to me would be the details needing to be done as part of the project. I guess I found the config file format a lot more fun to define. ? >> not just focus on removing the argument parsing from the core rte_eal_init >> code, >> instead passing in a configuration struct that is stored and queried per >> application. Leave the parsing of a config file and population of that >> config >> struct as an exercize to the application developer. That way a given >> application can use command line options, config files, or whatever method >> they >> choose, which would be in keeping with traditional application design. Moving the code out of DPDK into multiple different libraries one for converting command line to config structure (support the current options) and possibly some config file format library to config structure would give options for the developers. DPDK just needs to be driven by a configuration structure or set of APIs and not use args/argv directly. Moving the current args/argv code out of DPDK into a library should be easy (I guess) and I am willing to do that work if we think it is needed today. >> >> For the purposes of the example apps, it would seem that either JSON, YAML, >> or >> the above Lua format would work just fine. > >+1 > Regards, ++Keith
