From mboxrd@z Thu Jan 1 00:00:00 1970 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) Received: from [107.15.76.160] (helo=localhost) by smtp.tuxdriver.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1b8t9B-0000q8-Uq; Fri, 03 Jun 2016 13:44:42 -0400 Date: Fri, 3 Jun 2016 13:44:37 -0400 From: Neil Horman To: "Wiles, Keith" Cc: Arnon Warshavsky , Panu Matilainen , "Richardson, Bruce" , Thomas Monjalon , Yuanhan Liu , "dev@dpdk.org" , "Tan, Jianfeng" , Stephen Hemminger , Christian Ehrhardt , Olivier Matz 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-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <8CE01283-1E89-4302-BE7D-486975B43EF6@intel.com> User-Agent: Mutt/1.6.1 (2016-04-27) X-Spam-Score: -1.0 (-) X-Spam-Status: No 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 17:44:50 -0000 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. > > Here are my thoughts as of now, which is a combination of many suggestions I read from everyone’s emails. I hope this is not too hard to understand. > > - Break out the current command line options out of the DPDK common code 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 data storage. > - Maybe move the rte_eal_init() API to the new lib or keep it in the 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 thinking here) These three items seem to be the exact opposite of my suggestion. The point of this change was to segregate the parsing of configuration away from the initalization dpdk using that configurtion. By keeping rte_eal_init in such 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 separation. 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. > > - I would like to keep the storage of the data separate from the file parser as they can use the ‘set’ routines to build the data storage up. > - Keeping them split allows for new parsers to be created, while keeping the data storage from changing. > - The rte_cfg code could be modified to use the new configuration if someone wants to take on that task ☺ > > - Next is the data storage and how we can access the data in a clean simple way. > - I want to have some simple level of hierarchy in the data. > - Having a string containing at least two levels “primary:secondary”. > - Primary string is something like “EAL” or “Pktgen” or “testpmd” to divide the data storage into logical major groups. > - The primary allows us to have groups and then we can have common secondary strings in different groups if needed. > - Secondary string can be whatever the developer of that group would like e.g. simple “EAL:foobar”, two levels “testpmd:foo.bar” > > - The secondary string is treated as a single string if it has a hierarchy 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 “EAL:foobar” not just “foobar” 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, “EAL”, “foo.bar”); > rte_map_set(mapObj, “EAL”, “foo.bar”, 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 typos be a problem. > - Not sure what the design is yet, but I do not want to have to concat two string or split strings in the code. > > This is as far as I have gotten and got tired of typing ☺ > > I hope this will satisfy most everyone’s needs for now. > > > Regards, > Keith > > >