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 11:29:43 +0100 Message-ID: <20160603102943.GC16616@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> 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 mga04.intel.com (mga04.intel.com [192.55.52.120]) by dpdk.org (Postfix) with ESMTP id 92BDD5960 for ; Fri, 3 Jun 2016 12:29:48 +0200 (CEST) Content-Disposition: inline In-Reply-To: <20160602200837.GC12923@hmsreliant.think-freely.org> 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 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_ea= l_init, > > >defining the configuration for that running process > >=20 > > 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 ve= ry 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 need= s to be very easy to use as well. >=20 > Thats a fair point. A decent starting point is likely a simple struct = 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 si= mple 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 c= har > 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 still = make sense? > >=20 > No. I think you're ABI concerns are valid, but the above is likely a go= od > starting point to address them. >=20 > 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 rea= d 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. W= ith 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 =3D rte_cfgfile_load("my_cfg_file"); rte_eal_newinit(cfg); Those who want a different config can instead do: 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); We can standardize on a sectionname, or a couple of standard section name= s that are used by DPDK, so that the rest of the config file can contain other d= ata for the app itself. What do people think. I mainly like it because it gives us good reuse of = what is already there, and enhances our existing library. As well as this it m= akes it trivially easy for apps to use ini files - which seem to be very popul= ar here - while still giving flexibility for others to use whatever other config = format their app prefers. /Bruce