From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <maryam.tahhan@intel.com>
Received: from mga02.intel.com (mga02.intel.com [134.134.136.20])
 by dpdk.org (Postfix) with ESMTP id 8100A95C8
 for <dev@dpdk.org>; Tue,  2 Feb 2016 13:44:35 +0100 (CET)
Received: from orsmga003.jf.intel.com ([10.7.209.27])
 by orsmga101.jf.intel.com with ESMTP; 02 Feb 2016 04:44:34 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.22,384,1449561600"; d="scan'208";a="739062294"
Received: from irsmsx104.ger.corp.intel.com ([163.33.3.159])
 by orsmga003.jf.intel.com with ESMTP; 02 Feb 2016 04:44:32 -0800
Received: from irsmsx106.ger.corp.intel.com ([169.254.8.197]) by
 IRSMSX104.ger.corp.intel.com ([163.33.3.159]) with mapi id 14.03.0248.002;
 Tue, 2 Feb 2016 12:44:32 +0000
From: "Tahhan, Maryam" <maryam.tahhan@intel.com>
To: Matthew Hall <mhall@mhcomputing.net>, Igor Ryzhov <iryzhov@nfware.com>
Thread-Topic: [dpdk-dev] Future Direction for rte_eth_stats_get()
Thread-Index: AdFToifrMKxGpVsMS/qKv8msWpPa2wABEBgwAFcuL6AAA/u1IAACHmaQAAHzDgAAAKQ2AAAMGYGAAhduSIA=
Date: Tue, 2 Feb 2016 12:44:32 +0000
Message-ID: <1A27633A6DA49C4A92FCD5D4312DBF536B0AC8DC@IRSMSX106.ger.corp.intel.com>
References: <d381e4b1efe049cebcedc7107a3aa479@XCH-RCD-016.cisco.com>
 <74583418c4374c349bfdea0c59b84118@XCH-RCD-016.cisco.com>
 <1A27633A6DA49C4A92FCD5D4312DBF536B09F7A4@IRSMSX106.ger.corp.intel.com>
 <27428043.8pduO1a1Qt@xps13>
 <B62D4F9D-6272-4B99-A6E2-5F77A5B62FFC@nfware.com>
 <20160122204851.GC22985@mhcomputing.net>
In-Reply-To: <20160122204851.GC22985@mhcomputing.net>
Accept-Language: en-IE, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiN2NmNTE1ZjktY2Y1MS00OGE4LTkwZGYtYTcyMjIxMTVjOThhIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjQuMTAuMTkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiMklxQ2VTdUxNWEEwUFlseThSVDc4VE4zVWVlWHUxbzhTYW1pN29rWnZPWT0ifQ==
x-ctpclassification: CTP_IC
x-originating-ip: [163.33.239.181]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "dev@dpdk.org" <dev@dpdk.org>, Jonas Bjurel <jonas.bjurel@ericsson.com>
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: Tue, 02 Feb 2016 12:44:35 -0000

> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Matthew Hall
> Sent: Friday, January 22, 2016 8:49 PM
> To: Igor Ryzhov <iryzhov@nfware.com>
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] Future Direction for rte_eth_stats_get()
>=20
> On Fri, Jan 22, 2016 at 06:02:24PM +0300, Igor Ryzhov wrote:
> > How about exposing stats according to IF-MIB?
> >
> > Statistics to be exposed are - octets, unicast packets, multicast
> > packets, broadcast packets, errors and discards for both TX and RX.
> >
> > These counters are basic and implemented by most of drivers.
>=20
> To be a bit more specific it would be good to have IF-MIB ifTable with
> the items from ifXTable as well:
>=20

I think the MIBs ifTable would be good for the high level stats across all =
the drivers for sure, we would need to take backward compatibility for the =
current stats into account.=20

> ifIndex
> ifMtu
> ifHighSpeed
> ifPromiscuousMode
> ifPhysAddress
> ifConnectorPresent
>=20
> ifHCInOctets
> ifHCInUcastPkts
> ifHCInMulticastPkts
> ifHCInBroadcastPkts
> ifInDiscards
> ifInErrors
> ifInUnknownProtos
>=20
> ifHCOutOctets
> ifHCOutUcastPkts
> ifHCOutMulticastPkts
> ifHCOutBroadcastPkts
> ifOutDiscards
> ifOutErrors
>=20
> A number of things are missing or weird in the DPDK stats interface.
> Then I get stuck trying to maintain them in my app instead and it's
> annoying.
>=20
> Also, it is nice to get the struct populated atomically so the values are=
 as
> self-consistent as possible. If you have to call a function separately on
> each stat it makes them self-inconsistent because it is less atomically
> populated.

+1
>=20
> From long experience, this inconsistency is quite annoying when trying to
> make very accurate traffic measurements in network management
> software.
>=20
> Matthew.