[dpdk-dev] [RFC] Yet another option for DPDK options
Neil Horman
nhorman at tuxdriver.com
Fri Jun 3 00:34:58 CEST 2016
On Thu, Jun 02, 2016 at 01:53:55PM -0700, Matthew Hall wrote:
> On Thu, Jun 02, 2016 at 04:08:37PM -0400, Neil Horman wrote:
> > struct key_vals {
> > char *key;
> > union {
> > ulong longval;
> > void *ptrval;
> > } value;
> > };
> >
> > struct config {
> > size_t count;
> > struct key_vals kvp[0];
> > };
>
> 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. Of course its just for config, we're
talking about a configuration structure. If you want to make it more
complex/heirarchical/whatever, fine, propose a way to do that that isnt ABI
variant in response to config additions. Its just a starting point.
> Something that looks more like sysctl MIBs with hierarchical names or like
> JSON w/ a hierarchy of hash tables and arrays is much less user-hostile.
>
> 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.
> 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
Neil
> Matthew.
>
More information about the dev
mailing list