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 D7E4F5A9F for ; Thu, 2 Jun 2016 19:11:40 +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 1b8W9X-0007E6-Br; Thu, 02 Jun 2016 13:11:31 -0400 Date: Thu, 2 Jun 2016 13:11:20 -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: <20160602171120.GB12923@hmsreliant.think-freely.org> References: <20160602104106.GA12923@hmsreliant.think-freely.org> <2363376.b1CWhBpcZG@xps13> <75917C44-9CF7-4A0B-B8D3-CD7DC7425D49@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <75917C44-9CF7-4A0B-B8D3-CD7DC7425D49@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 17:11:41 -0000 On Thu, Jun 02, 2016 at 01:53:32PM +0000, Wiles, Keith wrote: > > On 6/2/16, 8:19 AM, "Thomas Monjalon" wrote: > > >2016-06-02 06:41, Neil Horman: > >> I'm not sure why you're focusing no selecting a config file format at all. Why > > The reason is I am on now looking at formats is because I have been thinking about this issue for some time and already understand your comments. I agree with you and Thomas, which to me would be the details needing to be done as part of the project. I guess I found the config file format a lot more fun to define. ☺ > Sure, it is more fun to define, but I think its likely the wrong problem to solve (or perhaps not even the wrong problem, but rather the less pressing problem). > >> not just focus on removing the argument parsing from the core rte_eal_init code, > >> instead passing in a configuration struct that is stored and queried per > >> application. Leave the parsing of a config file and population of that config > >> struct as an exercize to the application developer. That way a given > >> application can use command line options, config files, or whatever method they > >> choose, which would be in keeping with traditional application design. > > Moving the code out of DPDK into multiple different libraries one for converting command line to config structure (support the current options) and possibly some config file format library to config structure would give options for the developers. DPDK just needs to be driven by a configuration structure or set of APIs and not use args/argv directly. Yes. So we agree? > > Moving the current args/argv code out of DPDK into a library should be easy (I guess) and I am willing to do that work if we think it is needed today. > Yes, I think thats the more pressing problem. To ennumerate, I think whats really called for is: 1) The definition of a config structure that can be passed to rte_eal_init, defining the configuration for that running process 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 > >