From mboxrd@z Thu Jan 1 00:00:00 1970 From: Neil Horman Subject: Re: [RFC] Yet another option for DPDK options Date: Fri, 3 Jun 2016 07:50:48 -0400 Message-ID: <20160603115048.GA12627@hmsreliant.think-freely.org> References: <20160602104106.GA12923@hmsreliant.think-freely.org> <2363376.b1CWhBpcZG@xps13> <75917C44-9CF7-4A0B-B8D3-CD7DC7425D49@intel.com> <20160602171120.GB12923@hmsreliant.think-freely.org> <7091836E-B9D5-4F99-ADDB-A47B4C7B5F7E@intel.com> <20160602200837.GC12923@hmsreliant.think-freely.org> <20160603102943.GC16616@bricha3-MOBL3> <20160603110129.GB17812@bricha3-MOBL3> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: "Wiles, Keith" , Thomas Monjalon , Yuanhan Liu , "dev@dpdk.org" , "Tan, Jianfeng" , Stephen Hemminger , Christian Ehrhardt , Panu Matilainen , Olivier Matz To: Bruce Richardson Return-path: Received: from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58]) by dpdk.org (Postfix) with ESMTP id 1BE972A66 for ; Fri, 3 Jun 2016 13:51:04 +0200 (CEST) Content-Disposition: inline In-Reply-To: <20160603110129.GB17812@bricha3-MOBL3> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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: > > > >=20 > > > > On 6/2/16, 12:11 PM, "Neil Horman" wrote: > > > >=20 > > > > > > > > > >1) The definition of a config structure that can be passed to rt= e_eal_init, > > > > >defining the configuration for that running process > > > >=20 > > > > Having a configuration structure means we have to have an ABI cha= nge 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. > > >=20 > > > Thats a fair point. A decent starting point is likely a simple str= uct that > > > looks like this: > > >=20 > > > struct key_vals { > > > char *key; > > > union { > > > ulong longval; > > > void *ptrval; > > > } value; > > > }; > > >=20 > > > struct config { > > > size_t count; > > > struct key_vals kvp[0]; > > > }; > > >=20 > > > >=20 > > > > 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= , =E2=80=A6) > > > >=20 > > > 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 a= nd char > > > value, I'd name them "group.intval", and "group.charval", so they a= re > > > independently searchable, but linked from a nomenclature standpoint= . > > >=20 > > > > Would this work better in the long run, does a fixed structure st= ill make sense? > > > >=20 > > > No. I think you're ABI concerns are valid, but the above is likely = a good > > > starting point to address them. > > >=20 > > > Best > > > Neil > >=20 > > I'll throw out one implementation idea here that I looked at previous= ly, for > > the reason that it was simple enough implement with existing code. > >=20 > > 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 wel= l. With > > that done we can then just add a new eal_init api which takes a singl= e > > "struct rte_cfgfile *" as parameter. For those apps that want to just= use > > inifiles for configuration straight, they can then do: > >=20 > > cfg =3D rte_cfgfile_load("my_cfg_file"); > > rte_eal_newinit(cfg); > >=20 > > Those who want a different config can instead do: > >=20 > > cfg =3D rte_cfgfile_new(); > > rte_cfgfile_add_section(cfg, "dpdk"); > > foreach_eal_setting_wanted: > > rte_cfgfile_set(cfg, "dpdk", mysetting, myvalue); > > rte_eal_newinit(cfg); > >=20 > 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 i= s building > up a "config-file" in memory - or rather a config structure which happe= ns to > have the idea of sections and values as an ini file has. There is no ac= tual > 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 shou= ld be=20 > pretty much the same as building up any other set of key-value pairs in > memory to pass to an init function. >=20 > Hope this is a little clearer now. >=20 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, r= ather than a configuration file parser. My primary interest is in separating t= he user configuration mechanism from the internal library configuration lookup mechanism. What I would really like to be able to see is application dev= elopers have the flexibiilty to choose their own configuration method and format,= and programatically build a configuration for the dpdk on a per-instance basi= s prior to calling rte_eal_init It seems like this approach satisfies that requirement Neil > /Bruce >=20