From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bruce Richardson Subject: Re: [RFC] Yet another option for DPDK options Date: Fri, 3 Jun 2016 12:01:30 +0100 Message-ID: <20160603110129.GB17812@bricha3-MOBL3> 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> 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: Neil Horman Return-path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id 64A282C67 for ; Fri, 3 Jun 2016 13:01:35 +0200 (CEST) Content-Disposition: inline In-Reply-To: <20160603102943.GC16616@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 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 rte_= eal_init, > > > >defining the configuration for that running process > > >=20 > > > Having a configuration structure means we have to have an ABI chang= e 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 t= o obtain the needed information. The APIs used to query and set the DB ne= eds to be very easy to use as well. > >=20 > > Thats a fair point. A decent starting point is likely a simple struc= t 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 and= char > > value, I'd name them "group.intval", and "group.charval", so they are > > independently searchable, but linked from a nomenclature standpoint. > >=20 > > > Would this work better in the long run, does a fixed structure stil= l 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 previously= , 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 r= ead from > ini files on disk. However, it would be easy enough to add couple of AP= Is 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 u= se > 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 ha= ve 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 actu= al file ever being written to disk, and for those using any non-ini config f= ile structure for their app, the code overhead of using the APIs above should= be=20 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. /Bruce