From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <bruce.richardson@intel.com>
Received: from mga09.intel.com (mga09.intel.com [134.134.136.24])
by dpdk.org (Postfix) with ESMTP id 99248592F
for <dev@dpdk.org>; Fri, 3 Jun 2016 11:57:27 +0200 (CEST)
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
by orsmga102.jf.intel.com with ESMTP; 03 Jun 2016 02:57:26 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.26,411,1459839600"; d="scan'208";a="994457963"
Received: from bricha3-mobl3.ger.corp.intel.com ([10.237.221.81])
by fmsmga002.fm.intel.com with SMTP; 03 Jun 2016 02:57:23 -0700
Received: by (sSMTP sendmail emulation); Fri, 03 Jun 2016 10:57:22 +0025
Date: Fri, 3 Jun 2016 10:57:22 +0100
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>
Message-ID: <20160603095722.GA16616@bricha3-MOBL3>
References: <C508AAA8-E813-4F2D-A2A4-1E2D5E34BF66@intel.com>
<20160602104106.GA12923@hmsreliant.think-freely.org>
<2363376.b1CWhBpcZG@xps13>
<75917C44-9CF7-4A0B-B8D3-CD7DC7425D49@intel.com>
<20160602171120.GB12923@hmsreliant.think-freely.org>
<7091836E-B9D5-4F99-ADDB-A47B4C7B5F7E@intel.com>
<20160602200837.GC12923@hmsreliant.think-freely.org>
<20160602205355.GB24543@mhcomputing.net>
<20160602223458.GA24257@neilslaptop.think-freely.org>
<20160603021705.GA26580@mhcomputing.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20160603021705.GA26580@mhcomputing.net>
Organization: Intel Research and =?iso-8859-1?Q?De=ACvel?=
=?iso-8859-1?Q?opment?= Ireland Ltd.
User-Agent: Mutt/1.5.23 (2014-03-12)
Subject: Re: [dpdk-dev] [RFC] Yet another option for DPDK options
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: patches and discussions about DPDK <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Jun 2016 09:57:28 -0000
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!
/Bruce