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:53:00 +0300 Message-ID: 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: Bruce Richardson , "Wiles, Keith" , Thomas Monjalon , Yuanhan Liu , "dev@dpdk.org" , "Tan, Jianfeng" , Stephen Hemminger , Christian Ehrhardt , Olivier Matz To: Arnon Warshavsky , Neil Horman Return-path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id C6C72558D for ; Fri, 3 Jun 2016 14:53:04 +0200 (CEST) In-Reply-To: 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 03:01 PM, Arnon Warshavsky wrote: > > > On Fri, Jun 3, 2016 at 2: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 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 th= e > code query the DB to obtain the needed information. The APIs used t= o > 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, =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 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 co= de. > > > > > > 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 t= o > 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 ma= y > 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 abov= e > 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 loo= kup > 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-instanc= e > basis prior > to calling rte_eal_init > > It seems like this approach satisfies that requirement > Neil > > > If the there is no configuration structure , rather an opaque > configuration key/value store , > the user applications can set and get knobs that are not seen by anyone > (library) that does not know them by name > > e.g > > int num_nodes =3D getCfgInt ( cfgObject , "eal" , "num_numa_nodes"); > int delay =3D getCfgInt ( cfgObject , "drivers.ixgbe" , "some_delay"); > setCfgInt (cfgObject , "my_app" , "num_days" , 7); > setCfgString (cfgObject , "my_app" , "best_day" , "Wednesday"); I dont see why it would not be possible to have the libraries export=20 their known config keys in one way or the other. Or more. One aspect is runtime queries which would need an API of some kind.=20 Being able to query default values should work for that purpose and be=20 handy for various other uses as well. Another one is build-time sanity checking which could be doen by=20 auto-generating header(s) from the library known keys, eg #define CFG_NUM_NUMA_NODES "num_numa_nodes" so if you use the macro instead of the actual string, you'll get a=20 compiler error in case of unknown key instead of runtime misbehavior in=20 case of typoed values etc. Whether that's worth it is an entirely=20 different question. - Panu - > /Arnon >