From mboxrd@z Thu Jan 1 00:00:00 1970 From: Neil Horman Subject: Re: [RFC] Yet another option for DPDK options Date: Thu, 2 Jun 2016 13:11:20 -0400 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-Transfer-Encoding: quoted-printable Cc: Thomas Monjalon , Yuanhan Liu , "dev@dpdk.org" , "Richardson, Bruce" , "Tan, Jianfeng" , Stephen Hemminger , Christian Ehrhardt , Panu Matilainen , 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 D7E4F5A9F for ; Thu, 2 Jun 2016 19:11:40 +0200 (CEST) Content-Disposition: inline In-Reply-To: <75917C44-9CF7-4A0B-B8D3-CD7DC7425D49@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 Thu, Jun 02, 2016 at 01:53:32PM +0000, Wiles, Keith wrote: >=20 > On 6/2/16, 8:19 AM, "Thomas Monjalon" wrote= : >=20 > >2016-06-02 06:41, Neil Horman: > >> I'm not sure why you're focusing no selecting a config file format a= t all. Why >=20 > The reason is I am on now looking at formats is because I have been thi= nking 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 t= o be done as part of the project. I guess I found the config file format = a lot more fun to define. =E2=98=BA >=20 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 pressin= g problem). > >> not just focus on removing the argument parsing from the core rte_ea= l_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 t= hat config > >> struct as an exercize to the application developer. That way a give= n > >> application can use command line options, config files, or whatever = method they > >> choose, which would be in keeping with traditional application desig= n. >=20 > Moving the code out of DPDK into multiple different libraries one for c= onverting command line to config structure (support the current options) = and possibly some config file format library to config structure would gi= ve options for the developers. DPDK just needs to be driven by a configur= ation structure or set of APIs and not use args/argv directly. Yes. So we agree? >=20 > 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. >=20 Yes, I think thats the more pressing problem. To ennumerate, I think wha= ts really called for is: 1) The definition of a config structure that can be passed to rte_eal_ini= t, 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 enti= rely, packaging it instead as its own library that interprets command line argu= ments 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 de= fined in (1) With those steps, I think we will remove the command line bits from the d= pdk core, and do so without altering the user experience for any of the sampl= e apps (which will demonstrate to other developers that the same can be done wit= h 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 > >>=20 > >> For the purposes of the example apps, it would seem that either JSON= , YAML, or > >> the above Lua format would work just fine. > > > >+1 > > >=20 > Regards, > ++Keith >=20 >=20