From mboxrd@z Thu Jan  1 00:00:00 1970
From: Matthew Hall <mhall@mhcomputing.net>
Subject: Re: [RFC] Yet another option for DPDK options
Date: Thu, 2 Jun 2016 13:53:55 -0700
Message-ID: <20160602205355.GB24543@mhcomputing.net>
References: <C508AAA8-E813-4F2D-A2A4-1E2D5E34BF66@intel.com>
 <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>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
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>
To: Neil Horman <nhorman@tuxdriver.com>
Return-path: <dev-bounces@dpdk.org>
Received: from mail.mhcomputing.net (master.mhcomputing.net [74.208.228.170])
 by dpdk.org (Postfix) with ESMTP id 78BFD5A93
 for <dev@dpdk.org>; Thu,  2 Jun 2016 22:53:56 +0200 (CEST)
Content-Disposition: inline
In-Reply-To: <20160602200837.GC12923@hmsreliant.think-freely.org>
List-Id: patches and discussions about DPDK <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.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.