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 77B995A32 for ; Thu, 2 Jun 2016 22:08:53 +0200 (CEST) Received: from hmsreliant.think-freely.org ([2001:470:8:a08:7aac:c0ff:fec2:933b] helo=localhost) by smtp.tuxdriver.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1b8Yv5-0008Lw-6Y; Thu, 02 Jun 2016 16:08:44 -0400 Date: Thu, 2 Jun 2016 16:08:37 -0400 From: Neil Horman To: "Wiles, Keith" Cc: Thomas Monjalon , Yuanhan Liu , "dev@dpdk.org" , "Richardson, Bruce" , "Tan, Jianfeng" , Stephen Hemminger , Christian Ehrhardt , Panu Matilainen , Olivier Matz Message-ID: <20160602200837.GC12923@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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <7091836E-B9D5-4F99-ADDB-A47B4C7B5F7E@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: Thu, 02 Jun 2016 20:08:53 -0000 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 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, …) > 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 > > > >2) The creation and use of an API that various DPDK libraries can use to > >retrieve that structure (or elements thereof), based on some explicit or imlicit > >id, so that the configuration can be used (I'm thinking here specifically of > >multiple dpdk applications using a dpdk shared library) > > > >3) The removal of the eal_parse_args code from the core dpdk library entirely, > >packaging it instead as its own library that interprets command line arguments > >as currently defined, and populates an instance of the structure defined in (1) > > > >4) Altering the Makefiles, so that the example apps link against the new library > >in (3), altering the app source code to work with the config structure defined > >in (1) > > > >With those steps, I think we will remove the command line bits from the dpdk > >core, and do so without altering the user experience for any of the sample apps > >(which will demonstrate to other developers that the same can be done with their > >applications). From there we will be free to create alternate methods of > >populating the config struct defined in (1) (via JSON file, YAML, XML, or > >whatever). > > > >Neil > > > >> >> > >> >> For the purposes of the example apps, it would seem that either JSON, YAML, or > >> >> the above Lua format would work just fine. > >> > > >> >+1 > >> > > >> > >> Regards, > >> ++Keith > >> > >> > > > > >