From mboxrd@z Thu Jan 1 00:00:00 1970 From: Neil Horman Subject: Re: [RFC] Yet another option for DPDK options Date: Fri, 3 Jun 2016 13:44:37 -0400 Message-ID: <20160603174437.GC12627@hmsreliant.think-freely.org> References: <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> <8CE01283-1E89-4302-BE7D-486975B43EF6@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Arnon Warshavsky , Panu Matilainen , "Richardson, Bruce" , Thomas Monjalon , Yuanhan Liu , "dev@dpdk.org" , "Tan, Jianfeng" , Stephen Hemminger , Christian Ehrhardt , Olivier Matz To: "Wiles, Keith" Return-path: Received: from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58]) by dpdk.org (Postfix) with ESMTP id 6F33B5A45 for ; Fri, 3 Jun 2016 19:44:50 +0200 (CEST) Content-Disposition: inline In-Reply-To: <8CE01283-1E89-4302-BE7D-486975B43EF6@intel.com> 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 04:04:14PM +0000, Wiles, Keith wrote: > Sorry, I deleted all of the text as it was getting a bit long. >=20 > Here are my thoughts as of now, which is a combination of many suggesti= ons I read from everyone=E2=80=99s emails. I hope this is not too hard to= understand. >=20 > - Break out the current command line options out of the DPDK common cod= e and move into a new lib. > - At this point I was thinking of keeping the rte_eal_init(args, argv= ) API and just have it pass the args/argv to the new lib to create the da= ta storage. > - Maybe move the rte_eal_init() API to the new lib or keep it in t= he common eal code. Do not want to go hog wild. > - The rte_eal_init(args, argv) would then call to the new API rte_eal= _initialize(void), which in turn queries the data storage. (still thinkin= g here) These three items seem to be the exact opposite of my suggestion. The po= int of this change was to segregate the parsing of configuration away from the initalization dpdk using that configurtion. By keeping rte_eal_init in s= uch a way that the command line is directly passed into it, you've not changed = that implicit binding to command line options. I can understand if you want to keep rte_eal_init as is for ABI purposes,= but then you should create an rte_eal_init2(foo), where foo is some handle to= in memory parsed configuration, so that applications can preform that separa= tion. Neil > - The example apps args needs to be passed to the examples as is for = now, then we can convert them one at a time if needed. >=20 > - I would like to keep the storage of the data separate from the file p= arser as they can use the =E2=80=98set=E2=80=99 routines to build the dat= a storage up. > - Keeping them split allows for new parsers to be created, while keep= ing the data storage from changing. > - The rte_cfg code could be modified to use the new configuration if so= meone wants to take on that task =E2=98=BA >=20 > - Next is the data storage and how we can access the data in a clean si= mple way. > - I want to have some simple level of hierarchy in the data. > - Having a string containing at least two levels =E2=80=9Cprimary:sec= ondary=E2=80=9D. > - Primary string is something like =E2=80=9CEAL=E2=80=9D or =E2=80= =9CPktgen=E2=80=9D or =E2=80=9Ctestpmd=E2=80=9D to divide the data storag= e into logical major groups. > - The primary allows us to have groups and then we can have com= mon secondary strings in different groups if needed. > - Secondary string can be whatever the developer of that group wou= ld like e.g. simple =E2=80=9CEAL:foobar=E2=80=9D, two levels =E2=80=9Ctes= tpmd:foo.bar=E2=80=9D >=20 > - The secondary string is treated as a single string if it has a hier= archy or not, but referencing a single value in the data storage. > - Key value pairs (KVP) or a hashmap data store. > - The key here is the whole string =E2=80=9CEAL:foobar=E2=80=9D= not just =E2=80=9Cfoobar=E2=80=9D secondary string. > - If we want to have the two split I am ok with that as well= meaning the API would be: > rte_map_get(mapObj, =E2=80=9CEAL=E2=80=9D, =E2=80=9Cfoo.ba= r=E2=80=9D); > rte_map_set(mapObj, =E2=80=9CEAL=E2=80=9D, =E2=80=9Cfoo.ba= r=E2=80=9D, value); > - Have the primary as a different section in the data store,= would allow for dumping that section maybe easier, not sure. > - I am leaning toward > - Not going to try splitting up the string or parse it as it is up= to the developer to make it unique in the data store. > - Use a code design to make the strings simple to use without having ty= pos be a problem. > - Not sure what the design is yet, but I do not want to have to conc= at two string or split strings in the code. >=20 > This is as far as I have gotten and got tired of typing =E2=98=BA >=20 > I hope this will satisfy most everyone=E2=80=99s needs for now. >=20 >=20 > Regards, > Keith >=20 >=20 >=20