From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <nhorman@tuxdriver.com>
Received: from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58])
 by dpdk.org (Postfix) with ESMTP id 991C41DB1
 for <dev@dpdk.org>; Fri,  3 Jun 2016 00:35:15 +0200 (CEST)
Received: from [107.14.49.0] (helo=localhost)
 by smtp.tuxdriver.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63)
 (envelope-from <nhorman@tuxdriver.com>)
 id 1b8bCj-0000nr-CU; Thu, 02 Jun 2016 18:35:07 -0400
Date: Thu, 2 Jun 2016 18:34:58 -0400
From: Neil Horman <nhorman@tuxdriver.com>
To: Matthew Hall <mhall@mhcomputing.net>
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>
Message-ID: <20160602223458.GA24257@neilslaptop.think-freely.org>
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>
 <20160602205355.GB24543@mhcomputing.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20160602205355.GB24543@mhcomputing.net>
User-Agent: Mutt/1.6.1 (2016-04-27)
X-Spam-Score: -1.0 (-)
X-Spam-Status: No
Subject: Re: [dpdk-dev] [RFC] Yet another option for DPDK options
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
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>
X-List-Received-Date: Thu, 02 Jun 2016 22:35:15 -0000

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