On 6/2/16, 12:11 PM, "Neil Horman" <nhorman at tuxdriver.com> wrote:
> >1) The definition of a config structure that can be passed to rte_eal_init, >defining the configuration for that running process Having a configuration structure means we have to have an ABI change to that structure anytime we add or remove an option. I was thinking a very simple DB of some kind would be better. Have the code query the DB to obtain the needed information. The APIs used to query and set the DB needs to be very easy to use as well. Maybe each option can define its own structure if needed or just a simple variable type can be used for the basic types (int, string, bool, ?) Would this work better in the long run, does a fixed structure still make sense? > >2) The creation and use of an API that various DPDK libraries can use to >retrieve that structure (or elements thereof), based on some explicit or >imlicit >id, so that the configuration can be used (I'm thinking here specifically of >multiple dpdk applications using a dpdk shared library) > >3) The removal of the eal_parse_args code from the core dpdk library entirely, >packaging it instead as its own library that interprets command line arguments >as currently defined, and populates an instance of the structure defined in (1) > >4) Altering the Makefiles, so that the example apps link against the new >library >in (3), altering the app source code to work with the config structure defined >in (1) > >With those steps, I think we will remove the command line bits from the dpdk >core, and do so without altering the user experience for any of the sample apps >(which will demonstrate to other developers that the same can be done with >their >applications). From there we will be free to create alternate methods of >populating the config struct defined in (1) (via JSON file, YAML, XML, or >whatever). > >Neil > >> >> >> >> 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 >> >> >
