Re: [RFC] Yet another option for DPDK options

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: [RFC] Yet another option for DPDK options
Date: Thu, 2 Jun 2016 13:53:55 -0700	[thread overview]
Message-ID: <20160602205355.GB24543@mhcomputing.net> (raw)
In-Reply-To: <20160602200837.GC12923@hmsreliant.think-freely.org>

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.

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)

http://json-c.github.io/json-c/json-c-0.12/doc/html/json__object_8h.html

Matthew.