Re: [RFC] Yet another option for DPDK options

[Neil Horman <nhorman@tuxdriver.com>]

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.
> 
I still don't understand how you are likening a typed variable length array to
an ioctl that uses unsigned long a single all encompasing argument, or how you
see a difference between the ASN.1 style naming that sysctl uses and the ASN.1
style naming that  I proposed.  But I suppose thats neither here nor there, we
can agree to disagree on those points.

> > > 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.
> 
I take issue with that, I fail to see anything hostile about variable length
arrays of unioned types.  And if it iss to much, wrap a get/set api around it,
which I would expect anyway to ease lookup tasks.

> > > 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().
> 

soo, you want to borrow a parsing api for the sole purpose of using it as an
in-memory configuration mechanism?  I suppose thats fine, but as Bruce points
out in his note, the dpdk already has an api that can be repurposed for that
use.

> 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
> 

That seems....500% more complicated than what dpdk really needs.  All it really
needs is key/value storage, with some minor semblance of a grouping mechanism,
and the abiilty to store some basic types (void * at
a minimum).  The caller should know implicitly based on the key lookup/set what
the type of the value is.  The API could be as simple as:

int setkey(char *key, void *value);
void *getkey(char *key);
void delkey(char *key);


It could be more complex of course, but at a minuimum, thats really enough, if
you didn't just want to expose a data structure to directly alter.

Neil

> Matthew
>