All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnon Warshavsky <arnon@qwilt.com>
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>,
	Stephen Hemminger <stephen@networkplumber.org>,
	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 19:21:13 +0300	[thread overview]
Message-ID: <CAKy9EB35K6DYWQspR-=ytcQSj672FEik1eRAvdrcdjsV1=roNg@mail.gmail.com> (raw)
In-Reply-To: <20160601161826.GA9760@bricha3-MOBL3>

On Wed, Jun 1, 2016 at 7:18 PM, 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!
>
> 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
>
>

 +1 for a single cfg file parameter
 +1 for ini simplicity
/Arnon

  reply	other threads:[~2016-06-01 16:21 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-01 15:00 [RFC] Yet another option for DPDK options 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 [this message]
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='CAKy9EB35K6DYWQspR-=ytcQSj672FEik1eRAvdrcdjsV1=roNg@mail.gmail.com' \
    --to=arnon@qwilt.com \
    --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=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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.