On Thu, Jun 02, 2016 at 07:41:10PM +0000, Wiles, Keith wrote:
>
> 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.
Thats a fair point. A decent starting point is likely a simple struct that
looks like this:
struct key_vals {
char *key;
union {
ulong longval;
void *ptrval;
} value;
};
struct config {
size_t count;
struct key_vals kvp[0];
};
>
> 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, ?)
>
Well, if you have config sections that require mulitiple elements, I'd handle
that with naming, i.e. if you have a config group that has an int and char
value, I'd name them "group.intval", and "group.charval", so they are
independently searchable, but linked from a nomenclature standpoint.
> Would this work better in the long run, does a fixed structure still make
> sense?
>
No. I think you're ABI concerns are valid, but the above is likely a good
starting point to address them.
Best
Neil
> >
> >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
> >>
> >>
> >
>
>
>
