From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id 6B4D3C34A for ; Fri, 19 Feb 2016 10:09:29 +0100 (CET) Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga102.jf.intel.com with ESMTP; 19 Feb 2016 00:59:49 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.22,469,1449561600"; d="scan'208";a="749252033" Received: from irsmsx154.ger.corp.intel.com ([163.33.192.96]) by orsmga003.jf.intel.com with ESMTP; 19 Feb 2016 00:59:48 -0800 Received: from irsmsx106.ger.corp.intel.com ([169.254.8.197]) by IRSMSX154.ger.corp.intel.com ([169.254.12.208]) with mapi id 14.03.0248.002; Fri, 19 Feb 2016 08:59:45 +0000 From: "Tahhan, Maryam" To: "David Harton (dharton)" , "Van Haaren, Harry" , Thomas Monjalon Thread-Topic: [dpdk-dev] Future Direction for rte_eth_stats_get() Thread-Index: AdFToifrMKxGpVsMS/qKv8msWpPa2wABEBgwAFcuL6AAA/u1IAACHmaQAAF2QyAAAKFzAAAAQq/QAAJljoAAACWe0AAG6SYAAfFiIAAAABXT8ADSc2AAAqZS5AA= Date: Fri, 19 Feb 2016 08:59:44 +0000 Message-ID: <1A27633A6DA49C4A92FCD5D4312DBF536B0BF9B4@IRSMSX106.ger.corp.intel.com> References: <1A27633A6DA49C4A92FCD5D4312DBF536B09F7A4@IRSMSX106.ger.corp.intel.com> <1670837.tJHuUIkoht@xps13> <78791945dbf442b291adb72df8ec09f3@XCH-RCD-016.cisco.com> <3b3f956b6f7c490181b3db81b2c8d99a@XCH-RCD-016.cisco.com> In-Reply-To: Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiYTcxMmUxYjUtYWJhZS00YTMzLWFiNWQtNjU4YzNmYzA1ZTdhIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6ImlmSHd5THoyclp1MlFLVlRoQnYySFp5ZVNrVHlmVUI4UENWOGl0NVNmblE9In0= x-ctpclassification: CTP_IC x-originating-ip: [163.33.239.182] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2016 09:09:30 -0000 > From: David Harton (dharton) [mailto:dharton@cisco.com] > Sent: Friday, February 5, 2016 9:16 PM > To: Van Haaren, Harry ; Thomas > Monjalon > Cc: dev@dpdk.org; Tahhan, Maryam ; > Mcnamara, John > Subject: RE: [dpdk-dev] Future Direction for rte_eth_stats_get() >=20 >=20 > > From: Van Haaren, Harry [mailto:harry.van.haaren@intel.com] > > > > > From: David Harton > > > Subject: RE: [dpdk-dev] Future Direction for rte_eth_stats_get() > > > > > > Hi folks, > > > > > > I didn't see any follow up to this response. > > > > I think you may have missed one: > > http://dpdk.org/ml/archives/dev/2016-January/032211.html >=20 > Apologies Harry! I didn't see your original post because the IT gods had > decided your response was "Junk" mail and it didn't make it to my > dev_dpdk.org mail folder. :( >=20 > A colleague actually pointed me to this post separately today. I've made > the Junk mailer a little smarter now...hopefully. >=20 > > > > > I'm looking at the enum thinking it will grow out of control. > > Have you thought about adding metadata for RX / TX, PF / VF? >=20 > Yes, after thinking about it more I think it could get crazy. >=20 > > > > If metadata info is added, it would make retrieving a set of > > statistics based on a certain mask much easier. Do you think this may > be of use? >=20 > Actually, I put a fair bit of thought into things and then realized, why = re- > invent the wheel? > Why not follow the ethtool stats model? >=20 > struct rte_eth_xstats_name { > char name[RTE_ETH_XSTATS_NAME_SIZE]; }; >=20 > extern int rte_eth_xtats_count(uint8_t port_id, unsigned *count); extern > int rte_eth_xtats_strings(uint8_t port_id, unsigned count, struct > rte_eth_xtats_name *names); extern int rte_eth_xtats_values(uint8_t > port_id, unsigned count, uint64_t *values); >=20 > The existing API could be left in-place and these could be added for folk= s > that don't want to grab the strings all the time. >=20 > The cons compared to providing an enum or extending struct > rte_eth_stats are: > - you have to perform a query immediately after the device is attached > - doesn't require conformity...which has pros and cons >=20 > I'm actually testing the changes above if folks think this would be a > reasonable compromise I can patch them up. >=20 I think this is a reasonable compromise.=20 > I still feel the feedback myself and others gave about rte_eth_stats_get(= ) > being closer to a standard MIB should get some consideration. +1 > Applications that run with a number of different drivers/device types > likely want to avoid having to create "xstats mapping tables" every time > a new device pops out just so they can debug problems. >=20 > Thanks, > Dave