From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id 73EF3C42E for ; Thu, 28 Jan 2016 10:37:22 +0100 (CET) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga103.fm.intel.com with ESMTP; 28 Jan 2016 01:37:21 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.22,357,1449561600"; d="scan'208";a="870548295" Received: from irsmsx110.ger.corp.intel.com ([163.33.3.25]) by orsmga001.jf.intel.com with ESMTP; 28 Jan 2016 01:37:20 -0800 Received: from irsmsx102.ger.corp.intel.com ([169.254.2.97]) by irsmsx110.ger.corp.intel.com ([169.254.15.31]) with mapi id 14.03.0248.002; Thu, 28 Jan 2016 09:37:19 +0000 From: "Van Haaren, Harry" To: "David Harton (dharton)" , Thomas Monjalon Thread-Topic: [dpdk-dev] Future Direction for rte_eth_stats_get() Thread-Index: AdFToifrMKxGpVsMS/qKv8msWpPa2wABEBgwAFcuL6AAA/u1IAACHmaQAAF2QyAAAKFzAAAAQq/QAAJljoAAACWe0AAG6SYAARid6VA= Date: Thu, 28 Jan 2016 09:37:18 +0000 Message-ID: References: <1A27633A6DA49C4A92FCD5D4312DBF536B09F7A4@IRSMSX106.ger.corp.intel.com> <1670837.tJHuUIkoht@xps13> <78791945dbf442b291adb72df8ec09f3@XCH-RCD-016.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiZDMwOTEyZGQtODFkZS00OGY4LWI2ODMtMDQ3Y2UxNjk5NzBlIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX1BVQkxJQyJ9XX1dfSwiU3ViamVjdExhYmVscyI6W10sIlRNQ1ZlcnNpb24iOiIxNS40LjEwLjE5IiwiVHJ1c3RlZExhYmVsSGFzaCI6IkRyVUJBODN5S3M1NDN4NnJwOStyOHZcL3BxeHVcLzZxVWhOMHlUR3l3eVRJRT0ifQ== x-ctpclassification: CTP_PUBLIC 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" 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: Thu, 28 Jan 2016 09:37:23 -0000 > From: David Harton >=20 > enum rte_eth_stat_e { > /* accurate desc #1 */ > RTE_ETH_STAT_1, > /* accurate desc #2 */ > RTE_ETH_STAT_2, > ... > } > struct rte_eth_id_stat { > rte_eth_stat_e id; > uin64_t value; > } >=20 > int rte_eth_id_stats_num(uint8_t port_id, uint32_t *num_stats); > /* returns < 0 on error or the number of stats that could have been read = (i.e. if userd > */ > int rte_eth_id_stats_get(uint8_t port_id, uint32_t num_stats, rte_eth_id_= stat *id_stats); > const char* rte_eth_id_stat_str(rte_eth_stat_e id); >=20 > This allows a driver to return whatever stats that it supports in a consi= stent manner and > also in a performance friendly way. In fact, the driver side would be id= entical to what > they have today but instead of having arrays with "string stat name" they= will have the > rte_eth_stat_e. Thanks for the code and explanation. > > RE: Thomas asking about performance numbers: > > I can scrape together some raw tsc data on Monday and post to list, and= we > > can discuss it more then. >=20 > I can do the same if desired. But, just to make sure we are discussing t= he same issue: >=20 > 1) call rte_eth_xtats_get() > This will result in many string copies and depending on the driver *many*= copies I don't > want or care about. > 2) "tokenize"/parse/hash the string returned to identify what the stat ac= tually is > I'm guessing you are stating that this step could be mitigated at startup= . But, again, I > don't think the API provides a guarantee which usually leads to bugs over= time. > 3) Copy the value of the stat into the driver agnostic container the appl= ication uses > 4) Repeat steps 1-3 for every interface being serviced every 5 or 10 secs >=20 > Contrast that to my suggestion which has no string copies and a compile t= ime mapping > between "stat_id" and "app stat" can be created for step 2. I think the = performance > differences are obvious even without generating cycle times. Indeed using integers will reduce overhead compared to strings, and the helper function to convert the integer to string provides the same possibilities as the current API (in a different way). I haven't collected performance data yet, apologies for the delay. Perhaps continuing this conversation after the V1 patch deadline at the end of the week is a good idea? I'll have more time to dedicate to thinking about this. -Harry