From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by dpdk.org (Postfix) with ESMTP id 2839268E8 for ; Wed, 1 Jun 2016 18:18:32 +0200 (CEST) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga104.fm.intel.com with ESMTP; 01 Jun 2016 09:18:33 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.26,401,1459839600"; d="scan'208";a="966790455" Received: from bricha3-mobl3.ger.corp.intel.com ([10.237.220.117]) by orsmga001.jf.intel.com with SMTP; 01 Jun 2016 09:18:27 -0700 Received: by (sSMTP sendmail emulation); Wed, 01 Jun 2016 17:18:27 +0025 Date: Wed, 1 Jun 2016 17:18:26 +0100 From: Bruce Richardson To: Jay Rolette Cc: "Wiles, Keith" , Yuanhan Liu , Thomas Monjalon , "dev@dpdk.org" , "Tan, Jianfeng" , Stephen Hemminger , Christian Ehrhardt , Panu Matilainen , Olivier Matz Message-ID: <20160601161826.GA9760@bricha3-MOBL3> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: Intel Research and =?iso-8859-1?Q?De=ACvel?= =?iso-8859-1?Q?opment?= Ireland Ltd. User-Agent: Mutt/1.5.23 (2014-03-12) 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: Wed, 01 Jun 2016 16:18:32 -0000 On Wed, Jun 01, 2016 at 10:58:41AM -0500, Jay Rolette wrote: > On Wed, Jun 1, 2016 at 10:00 AM, Wiles, Keith wrote: > > > Started from the link below, but did not want to highjack the thread. > > http://dpdk.org/ml/archives/dev/2016-June/040021.html > > > > I was thinking about this problem from a user perspective and command line > > options are very difficult to manage specifically when you have a large > > number of options as we have in dpdk. I see all of these options as a type > > of database of information for the DPDK and the application, because the > > application command line options are also getting very complex as well. > > > > I have been looking at a number of different options here and the > > direction I was thinking was using a file for the options and > > configurations with the data in a clean format. It could have been a INI > > file or JSON or XML, but they all seem to have some problems I do not like. > > The INI file is too flat and I wanted a hierarchy in the data, the JSON > > data is similar and XML is just hard to read. I wanted to be able to manage > > multiple applications and possible system the DPDK/app runs. The problem > > with the above formats is they are just data and not easy to make decisions > > about the system and applications at runtime. > > > > INI format is simplest for users to read, but if you really need hierarchy, > JSON will do that just fine. Not sure what you mean by "JSON data is > similar"... > > I'd be quite concerned if we start needing lots of hierarchies for configuration. I'd really just like to see ini file format used for this because: * it's a well understood, simple format * very easily human readable and editable * lots of support for it in lots of languages * hierarchies are possible in it too - just not as easy as in other formats though. [In a previous life I worked with ini files which had address hierarchies 6-levels deep in them. It wasn't hard to work with] * it works well with grep since you must have one value per-line * it allows comments * we already have a DPDK library for parsing them However, for me the biggest advantage of using something like ini is that it would force us to keep things simple! I'd stay away from formats like json or XML that are designed for serializing entire objects or structures, and look for something that allows us to just specify configuration values. Regards, /Bruce