DPDK patches and discussions
 help / color / mirror / Atom feed
From: Bruce Richardson <bruce.richardson@intel.com>
To: Jay Rolette <rolette@infinite.io>
Cc: "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>,
	Stephen Hemminger <stephen@networkplumber.org>,
	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 17:18:26 +0100	[thread overview]
Message-ID: <20160601161826.GA9760@bricha3-MOBL3> (raw)
In-Reply-To: <CADNuJVp8oF9f4b6RpY8s3noCpt+hjF3ZZQkdcSjuEjvV7YNS_A@mail.gmail.com>

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!

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

  reply	other threads:[~2016-06-01 16:18 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 [this message]
2016-06-01 16:21     ` Arnon Warshavsky
2016-06-01 18:13     ` Wiles, Keith
2016-06-01 18:31     ` Stephen Hemminger
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=20160601161826.GA9760@bricha3-MOBL3 \
    --to=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=stephen@networkplumber.org \
    --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).