DPDK patches and discussions
 help / color / mirror / Atom feed
From: Matthew Hall <mhall@mhcomputing.net>
To: Neil Horman <nhorman@tuxdriver.com>
Cc: "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>,
	"Richardson, Bruce" <bruce.richardson@intel.com>,
	"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: Thu, 2 Jun 2016 19:17:05 -0700	[thread overview]
Message-ID: <20160603021705.GA26580@mhcomputing.net> (raw)
In-Reply-To: <20160602223458.GA24257@neilslaptop.think-freely.org>

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

  reply	other threads:[~2016-06-03  2:17 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 [this message]
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=20160603021705.GA26580@mhcomputing.net \
    --to=mhall@mhcomputing.net \
    --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=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).