DPDK patches and discussions
 help / color / mirror / Atom feed
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: [dpdk-dev] [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.

  parent reply	other threads:[~2016-06-01 18:31 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-01 15:00 Wiles, Keith
2016-06-01 15:46 ` Matthew Hall
2016-06-01 16:08   ` Wiles, Keith
2016-06-01 15:58 ` Jay Rolette
2016-06-01 16:18   ` Bruce Richardson
2016-06-01 16:21     ` Arnon Warshavsky
2016-06-01 18:13     ` Wiles, Keith
2016-06-01 18:31     ` Stephen Hemminger [this message]
2016-06-03 10:07     ` Yerden Zhumabekov
2016-06-01 18:51 ` Thomas Monjalon
2016-06-02  9:19   ` Marc
2016-06-02  7:56 ` Yuanhan Liu
2016-06-02 10:41 ` Neil Horman
2016-06-02 13:19   ` Thomas Monjalon
2016-06-02 13:53     ` Wiles, Keith
2016-06-02 17:11       ` Neil Horman
2016-06-02 19:33         ` Wiles, Keith
2016-06-02 19:41         ` Wiles, Keith
2016-06-02 20:08           ` Neil Horman
2016-06-02 20:53             ` Matthew Hall
2016-06-02 22:34               ` Neil Horman
2016-06-03  2:17                 ` Matthew Hall
2016-06-03  9:57                   ` Bruce Richardson
2016-06-03 10:06                     ` Bruce Richardson
2016-06-03 12:03                   ` Neil Horman
2016-06-03 10:29             ` Bruce Richardson
2016-06-03 11:01               ` Bruce Richardson
2016-06-03 11:50                 ` Neil Horman
2016-06-03 12:01                   ` Arnon Warshavsky
2016-06-03 12:53                     ` Panu Matilainen
2016-06-03 14:31                       ` Arnon Warshavsky
2016-06-03 16:04                         ` Wiles, Keith
2016-06-03 16:10                           ` Wiles, Keith
2016-06-03 17:44                           ` Neil Horman
2016-06-03 18:29                             ` Wiles, Keith
2016-06-03 18:38                               ` Neil Horman
2016-06-03 18:52                                 ` Arnon Warshavsky
2016-06-03 19:00                                   ` Wiles, Keith
2016-06-03 19:07                                     ` Wiles, Keith
2016-06-03 19:18                                       ` Neil Horman
2016-06-03 19:23                                         ` Wiles, Keith
2016-06-03 19:28                                           ` Arnon Warshavsky
2016-06-03 21:42                                           ` Matthew Hall
2016-06-03 21:41                                         ` Matthew Hall
2016-06-05  0:19                                           ` Neil Horman
2016-06-03 21:40                                       ` Matthew Hall
2016-06-03 21:38                                   ` Matthew Hall
2016-06-03 12:14                   ` Panu Matilainen
2016-06-02 20:51           ` Matthew Hall

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160601113156.119dd3fe@xeon-e3 \
    --to=stephen@networkplumber.org \
    --cc=bruce.richardson@intel.com \
    --cc=christian.ehrhardt@canonical.com \
    --cc=dev@dpdk.org \
    --cc=jianfeng.tan@intel.com \
    --cc=keith.wiles@intel.com \
    --cc=olivier.matz@6wind.com \
    --cc=pmatilai@redhat.com \
    --cc=rolette@infinite.io \
    --cc=thomas.monjalon@6wind.com \
    --cc=yuanhan.liu@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).