From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-f50.google.com (mail-oi0-f50.google.com [209.85.218.50]) by dpdk.org (Postfix) with ESMTP id DBAEF2B96 for ; Fri, 3 Jun 2016 14:01:25 +0200 (CEST) Received: by mail-oi0-f50.google.com with SMTP id k23so123200909oih.0 for ; Fri, 03 Jun 2016 05:01:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qwilt-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=OUV4QPhlL8XPDuqgWgM6lHjrC4fYjyXjZtUqvasOu9U=; b=yK9p+dYB3kqQAqERfFASRs/IOG1Y0ymztolhv5M4I5o8dywX6mHOTs+bGpz0/pZkG5 DidrvihhJVYPeek3Sh1OXInIWTo/9mwQjsmgW16Q1OuCaHDD2ZXleixF/ah4mUQgi4Dn nQp8eVLtvwROjL44rA/jSD6N4uuo4gWvVwsxUFqwPkIAGVKmZLJsf5RuoOL0yDehV3VJ xe+tOZDcC+WQC/GAnzqUe/OLO3VgST0g9C2v8yWSMYJIeiNQndu8L9tcILTJbJQrVewM iGlSh6bCUOrnU6OY/YiLtrOUvS37Cp80DN1gNyXSCLqnOw+Wn9jmubJNIIkqe93XzaXC JJOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=OUV4QPhlL8XPDuqgWgM6lHjrC4fYjyXjZtUqvasOu9U=; b=KbI16oO80HJ3VunuOc+OEgNDc1Zxi/uKIcc0J56e/WBy4M1R+OLyrAZ28as0QhLeNX +iraYO/IK+PZQJsjItMLtHf08YBkm5/27ASiB2dqUr8FIsPKIA/i6isd73zZQQJ+QUGQ vYXvnFRDI1r/JzAaugnVP8ZyVs7YqZApFL/dvVVyHIC+9wSdL8UCN6MFETK2uotuHrSA dBbCdmiczFJb9s/4oHEk2Vf6Hq0ihxPJGooIWIt0BgnltZdl3y40XPSwHbWueC6enhBm cmqnek7ggLQEm3nKX/2KUeuufp+zdXhbl/oyShXYKRooVOKxywuKdFlqeKWGa4jY4ToC 498w== X-Gm-Message-State: ALyK8tL9x+A7d+M0fUmsN/fwxrmDi0tg7AYIcv6jmI7Bdp2mKr1uNUvTfr29djZGbK5IUkKaVV1+0nSidU8Qdw== X-Received: by 10.157.39.54 with SMTP id r51mr1706408ota.98.1464955285151; Fri, 03 Jun 2016 05:01:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.108.37 with HTTP; Fri, 3 Jun 2016 05:01:24 -0700 (PDT) In-Reply-To: <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> <20160603115048.GA12627@hmsreliant.think-freely.org> From: Arnon Warshavsky Date: Fri, 3 Jun 2016 15:01:24 +0300 Message-ID: To: Neil Horman Cc: Bruce Richardson , "Wiles, Keith" , Thomas Monjalon , Yuanhan Liu , "dev@dpdk.org" , "Tan, Jianfeng" , Stephen Hemminger , Christian Ehrhardt , Panu Matilainen , Olivier Matz Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] [RFC] Yet another option for DPDK options X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 12:01:26 -0000 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 thinki= ng > 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. > > > > > > > > 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 a= re > > > > 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 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 > well. 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 i= s > 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 above > 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 lookup > 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-instance basi= s > 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"); /Arnon