From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <mhall@mhcomputing.net>
Received: from mail.mhcomputing.net (master.mhcomputing.net [74.208.228.170])
 by dpdk.org (Postfix) with ESMTP id 696648D94
 for <dev@dpdk.org>; Mon,  1 Feb 2016 22:23:49 +0100 (CET)
Received: by mail.mhcomputing.net (Postfix, from userid 1000)
 id E4918411; Mon,  1 Feb 2016 16:23:48 -0500 (EST)
Date: Mon, 1 Feb 2016 13:23:48 -0800
From: Matthew Hall <mhall@mhcomputing.net>
To: "David Harton (dharton)" <dharton@cisco.com>
Message-ID: <20160201212348.GB17493@mhcomputing.net>
References: <d381e4b1efe049cebcedc7107a3aa479@XCH-RCD-016.cisco.com>
 <1A27633A6DA49C4A92FCD5D4312DBF536B09F7A4@IRSMSX106.ger.corp.intel.com>
 <ce025b0121ff465a9abcc604c437ff59@XCH-RCD-016.cisco.com>
 <1670837.tJHuUIkoht@xps13>
 <E923DB57A917B54B9182A2E928D00FA6128617BE@IRSMSX102.ger.corp.intel.com>
 <78791945dbf442b291adb72df8ec09f3@XCH-RCD-016.cisco.com>
 <E923DB57A917B54B9182A2E928D00FA612861846@IRSMSX102.ger.corp.intel.com>
 <d517cdf33b6d4144ba5bf1d7a83dde85@XCH-RCD-016.cisco.com>
 <3b3f956b6f7c490181b3db81b2c8d99a@XCH-RCD-016.cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3b3f956b6f7c490181b3db81b2c8d99a@XCH-RCD-016.cisco.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] Future Direction for rte_eth_stats_get()
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: Mon, 01 Feb 2016 21:23:49 -0000

On Mon, Feb 01, 2016 at 04:47:56PM +0000, David Harton (dharton) wrote:
> Hi folks,
> 
> I didn't see any follow up to this response.
> 
> My original concern was rte_eth_stats_get() moving away from a more 
> conventional based definition (note, I believe Matthew Hall made an 
> interesting suggestion to follow a MIB based definition elsewhere).  
> However, if modifying that API is not desired then I'd really like to have 
> some feedback about extending the current xstats model.
> 
> Again, it is desired not to have to copy and/or parse strings for 
> scalability reasons but still maintain the "ABI flexibility" for which the 
> xstats model was geared towards.
> 
> Thanks,
> Dave

For me, I'd like to be able to get the core common stats in single memory 
blocks which are as self-consistent and atomic as possible.

I'd prefer to only resort to stuff like xstats using some kind of 
string-to-number lookup at the beginning, and only for weird stuff not the 
common MIB-like items.

>>From past experience this would be very valuable.

Matthew.