On Fri, Jun 03, 2016 at 12:01:30PM +0100, Bruce Richardson wrote:
> On Fri, Jun 03, 2016 at 11:29:43AM +0100, Bruce Richardson wrote:
> > On Thu, Jun 02, 2016 at 04:08:37PM -0400, Neil Horman wrote:
> > > 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
> >
> > I'll throw out one implementation idea here that I looked at previously, for
> > the reason that it was simple enough implement with existing code.
> >
> > We already have the cfgfile library which works with name/value pairs read
> > from
> > ini files on disk. However, it would be easy enough to add couple of APIs to
> > that to allow the user to "set" values inside an ini structure as well. With
> > that done we can then just add a new eal_init api which takes a single
> > "struct rte_cfgfile *" as parameter. For those apps that want to just use
> > inifiles for configuration straight, they can then do:
> >
> > cfg = rte_cfgfile_load("my_cfg_file");
> > rte_eal_newinit(cfg);
> >
> > Those who want a different config can instead do:
> >
> > cfg = rte_cfgfile_new();
> > rte_cfgfile_add_section(cfg, "dpdk");
> > foreach_eal_setting_wanted:
> > rte_cfgfile_set(cfg, "dpdk", mysetting, myvalue);
> > rte_eal_newinit(cfg);
> >
> From chatting to a couple of other DPDK dev's here I suspect I may not have
> been entirely clear here with this example. What is being shown above is
> building
> up a "config-file" in memory - or rather a config structure which happens to
> have the idea of sections and values as an ini file has. There is no actual
> file ever being written to disk, and for those using any non-ini config file
> structure for their app, the code overhead of using the APIs above should be
> pretty much the same as building up any other set of key-value pairs in
> memory to pass to an init function.
>
> Hope this is a little clearer now.
>
I'm fine with the idea of reusing the config file library that currently exists,
or more to the point, modifying it to be usable as a configuration API, rather
than a configuration file parser. My primary interest is in separating the user
configuration mechanism from the internal library configuration lookup
mechanism. What I would really like to be able to see is application developers
have the flexibiilty to choose their own configuration method and format, and
programatically build a configuration for the dpdk on a per-instance basis prior
to calling rte_eal_init
It seems like this approach satisfies that requirement
Neil
> /Bruce
>
