Re: [RFC] Yet another option for DPDK options

From: Stephen Hemminger <stephen@networkplumber.org>
To: Bruce Richardson <bruce.richardson@intel.com>
Cc: Jay Rolette <rolette@infinite.io>,
	"Wiles, Keith" <keith.wiles@intel.com>,
	Yuanhan Liu <yuanhan.liu@linux.intel.com>,
	Thomas Monjalon <thomas.monjalon@6wind.com>,
	"dev@dpdk.org" <dev@dpdk.org>,
	"Tan, Jianfeng" <jianfeng.tan@intel.com>,
	Christian Ehrhardt <christian.ehrhardt@canonical.com>,
	Panu Matilainen <pmatilai@redhat.com>,
	Olivier Matz <olivier.matz@6wind.com>
Subject: Re: [RFC] Yet another option for DPDK options
Date: Wed, 1 Jun 2016 11:31:56 -0700	[thread overview]
Message-ID: <20160601113156.119dd3fe@xeon-e3> (raw)
In-Reply-To: <20160601161826.GA9760@bricha3-MOBL3>

On Wed, 1 Jun 2016 17:18:26 +0100
Bruce Richardson <bruce.richardson@intel.com> wrote:

> On Wed, Jun 01, 2016 at 10:58:41AM -0500, Jay Rolette wrote:
> > On Wed, Jun 1, 2016 at 10:00 AM, Wiles, Keith <keith.wiles@intel.com> 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!

Agreed, INI is much easier to deal with than JSON.

Also, lets still keep the configuration options to a minimum. And the defaults
must still work.