From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id 490C4592F for ; Fri, 3 Jun 2016 12:06:54 +0200 (CEST) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga103.fm.intel.com with ESMTP; 03 Jun 2016 03:06:54 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.26,411,1459839600"; d="scan'208";a="994462998" Received: from bricha3-mobl3.ger.corp.intel.com ([10.237.221.81]) by fmsmga002.fm.intel.com with SMTP; 03 Jun 2016 03:06:50 -0700 Received: by (sSMTP sendmail emulation); Fri, 03 Jun 2016 11:06:49 +0025 Date: Fri, 3 Jun 2016 11:06:49 +0100 From: Bruce Richardson To: Matthew Hall Cc: Neil Horman , "Wiles, Keith" , Thomas Monjalon , Yuanhan Liu , "dev@dpdk.org" , "Tan, Jianfeng" , Stephen Hemminger , Christian Ehrhardt , Panu Matilainen , Olivier Matz Message-ID: <20160603100648.GB16616@bricha3-MOBL3> References: <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> <20160603095722.GA16616@bricha3-MOBL3> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160603095722.GA16616@bricha3-MOBL3> 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 10:06:54 -0000 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