DPDK patches and discussions
 help / color / mirror / Atom feed
From: Bruce Richardson <bruce.richardson@intel.com>
To: Matthew Hall <mhall@mhcomputing.net>
Cc: Neil Horman <nhorman@tuxdriver.com>,
	"Wiles, Keith" <keith.wiles@intel.com>,
	Thomas Monjalon <thomas.monjalon@6wind.com>,
	Yuanhan Liu <yuanhan.liu@linux.intel.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: Fri, 3 Jun 2016 11:06:49 +0100	[thread overview]
Message-ID: <20160603100648.GB16616@bricha3-MOBL3> (raw)
In-Reply-To: <20160603095722.GA16616@bricha3-MOBL3>

On Fri, Jun 03, 2016 at 10:57:22AM +0100, Bruce Richardson wrote:
> On Thu, Jun 02, 2016 at 07:17:05PM -0700, Matthew Hall wrote:
> > On Thu, Jun 02, 2016 at 06:34:58PM -0400, Neil Horman wrote:
> > > > This sort of code is very 1970s / ioctl / messy binary. And doesn't buy any 
> > > > performance advantage because it's just for config.
> > > > 
> > > What!?  I can't even parse that sentence.
> > 
> > I would not want to have to use the structure you proposed in user-readable 
> > code. It looked a lot like ugly ioctl stuff and I found the sysctl style 
> > interface easier to read. I don't see why that would be hard for anyone to 
> > parse but nevertheless.
> > 
> > > > https://www.freebsd.org/cgi/man.cgi?sysctl(3)
> > > > 
> > > I can't even begin to understand what you're after here.  sysctl provides a
> > > heirarchy in _exactly_ the same way that I just proposed, by texual consistency
> > > in naming.
> > 
> > I didn't object to the hierarchy part, but the user hostility of the example 
> > proposed.
> > 
> > > > http://json-c.github.io/json-c/json-c-0.12/doc/html/json__object_8h.html
> > > > 
> > > So, this is a fine interface to convert text config to a code format, but thats
> > > a decision that application should be making, not something dpdk should mandate
> > 
> > You're thinking way too narrowly here for what I am working to convey. I 
> > wasn't meaning to say JSON had to be used. I was saying, the kind of 
> > lightweight object-based API they used for modeling JSON has worked very well 
> > for modeling config data inside of my app. IE, simple functions for working 
> > with the following sort of entities (which are used in many file / interchange 
> > systems like JSON, MsgPack, YAML, etc.):
> > 
> > Objects:
> > * hashes, arbitrarily nested
> > * arrays, arbitrarily nested
> > 
> > Atoms:
> > * strings - textual
> > * strings - binary (something we should add for DPDK)
> > * integers
> > * floats / doubles
> > * booleans
> > 
> > In general I am seeing two good approaches for nesting:
> > 
> > 1. name nesting like MIB variable "x.y.z.a.b.c" - this is how sysctl works
> > 2. object nesting- this is how JSON, YAML, MsgPack, INI (implicitly w/ section 
> > names), XML etc. work...
> > 
> > to express this in the Python / Ruby / JS style syntax it would be:
> > 
> > config['x']['y']['z']['a']['b']['c']
> > using json-c it would be like
> > 
> > json_object_object_get()... until a json_object_TYPE_get().
> > 
> > What I've done for these in the past, is to make something that can parse the 
> > sysctl-style name x.y.z.0.a.b.c, detect if each dotted-item is a string, in 
> > which case reach inside the dict for the string or return NULL if not found, 
> > and if it's a number reach inside the array for that index and return NULL if 
> > not found. Here is a Python example how to take the sysctl style and look it 
> > up inside some objects. The same thing could be done using anything with at 
> > least as rich of features as what json-c provides...
> > 
> > RE_IS_INT = re.compile('^[0-9]+$')
> > def retrieve_path(data, path):
> >     if isinstance(path, basestring):
> >         path = path.split('.')
> > 
> >     if isinstance(data, Mapping):
> >         result = data.get(path[0])
> >     else:
> >         if not RE_IS_INT.match(str(path[0])):
> >             return None
> >         i = int(path[0])
> >         result = data[i] if len(data) > i else None
> > 
> >     if len(path) == 1:
> >         return result
> >     else:
> >         if result:
> >             return fetch(result, path[1:])
> >         else:
> >             return None
> > 
> > > Neil
> > 
> > Matthew
> 
> I'm afraid I don't see the need to expand out to such a large range of types, or
> to add object-type nesting. I'm a big fan of simplicity, and I think Neils
> original suggestion of basic name-value pairs is a good one to start with. The
> dot notation should work fine for any hierarchies we want to have. If we get
> beyond having 2 levels in a hierarchy of config, I think we may have gone
> overboard in making things too fine-grained configurable!
> 
Minor correction: re-reading my mail afterwards, I realise I actually meant 
2 dots in the name, ie. 2 sublevels, or 3 levels, rather than 2 levels! Must
proofread more.

However, I expect most folks still got my point despite the typo! :-)

/Bruce

  reply	other threads:[~2016-06-03 10:06 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
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 [this message]
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=20160603100648.GB16616@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=mhall@mhcomputing.net \
    --cc=nhorman@tuxdriver.com \
    --cc=olivier.matz@6wind.com \
    --cc=pmatilai@redhat.com \
    --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).