From mboxrd@z Thu Jan 1 00:00:00 1970 From: Panu Matilainen Subject: Re: [RFC] Yet another option for DPDK options Date: Fri, 3 Jun 2016 15:14:32 +0300 Message-ID: <245b3fad-8238-936e-5f79-ab09a543e3c7@redhat.com> 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> <20160603115048.GA12627@hmsreliant.think-freely.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Cc: "Wiles, Keith" , Thomas Monjalon , Yuanhan Liu , "dev@dpdk.org" , "Tan, Jianfeng" , Stephen Hemminger , Christian Ehrhardt , Olivier Matz To: Neil Horman , Bruce Richardson Return-path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id 1F5212C72 for ; Fri, 3 Jun 2016 14:14:37 +0200 (CEST) In-Reply-To: <20160603115048.GA12627@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 06/03/2016 02:50 PM, Neil Horman wrote: > 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" 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 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. >>>> >>>> Thats a fair point. A decent starting point is likely a simple stru= ct 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, = =E2=80=A6) >>>>> >>>> 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 an= d char >>>> value, I'd name them "group.intval", and "group.charval", so they ar= e >>>> independently searchable, but linked from a nomenclature standpoint. >>>> >>>>> Would this work better in the long run, does a fixed structure stil= l 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 previous= ly, 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 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: >>> >>> 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); >>> >> 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 happ= ens to >> have the idea of sections and values as an ini file has. There is no a= ctual >> file ever being written to disk, and for those using any non-ini confi= g file >> structure for their app, the code overhead of using the APIs above sho= uld be >> pretty much the same as building up any other set of key-value pairs i= n >> memory to pass to an init function. /me nods. This is pretty much exactly what I suggested (only in much less detail)=20 last year :) http://dpdk.org/ml/archives/dev/2015-October/024803.html >> Hope this is a little clearer now. > I'm fine with the idea of reusing the config file library that currentl= y 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 d= evelopers > have the flexibiilty to choose their own configuration method and forma= t, and > programatically build a configuration for the dpdk on a per-instance ba= sis prior > to calling rte_eal_init > > It seems like this approach satisfies that requirement /me nods some more. What the key-value config also can buy us is a direct mapping to cli=20 options (which is something Keith has been looking into IIRC), at which=20 point I think all the bases are quite nicely covered. - Panu -