From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by dpdk.org (Postfix) with ESMTP id 895BF8EA1 for ; Fri, 22 Jan 2016 17:04:21 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3642; q=dns/txt; s=iport; t=1453478661; x=1454688261; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=GikeDiKaJEDAnusUOzccp16z9vFdzlUtJB+6qzlHk8g=; b=VI7H7T/EPAoqFOBpcOZb6b45CYz5+OFT1d0OPZXrNpa5LWfcoREFBEuB i9S4PfDVA0VIaZI9vF31xQZ4ot+KnYgXX/WVL9JfnU+bcEDesULznWClA IWqYwpw7i0MXFBIbqiLlQeFYZVQBwzfLOHNyNpdyw3Zi82C/Kgoa8txeY w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A1BQAUUqJW/5FdJa1egzpSbQEFiFGzd?= =?us-ascii?q?iKFbQKBPTsRAQEBAQEBAYEKhEEBAQEDATo/BQsCAQgVIRAyJQIEAQ0NiAsIDr5?= =?us-ascii?q?OAQEBAQEBAQEBAQEBAQEBAQEBAReGMoRtiQYFjSqJTAGFRYgJgi+MUUSNegE2L?= =?us-ascii?q?INmaoYnfAEBAQ?= X-IronPort-AV: E=Sophos;i="5.22,331,1449532800"; d="scan'208";a="64244153" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Jan 2016 16:04:15 +0000 Received: from XCH-RCD-020.cisco.com (xch-rcd-020.cisco.com [173.37.102.30]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u0MG4EGm016504 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 22 Jan 2016 16:04:14 GMT Received: from xch-rcd-016.cisco.com (173.37.102.26) by XCH-RCD-020.cisco.com (173.37.102.30) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 22 Jan 2016 10:04:13 -0600 Received: from xch-rcd-016.cisco.com ([173.37.102.26]) by XCH-RCD-016.cisco.com ([173.37.102.26]) with mapi id 15.00.1104.009; Fri, 22 Jan 2016 10:04:13 -0600 From: "David Harton (dharton)" To: "Van Haaren, Harry" , Thomas Monjalon Thread-Topic: [dpdk-dev] Future Direction for rte_eth_stats_get() Thread-Index: AdFToifrMKxGpVsMS/qKv8msWpPa2wABEBgwAFcuL6AAA/u1IAACHmaQAAF2QyAADTQZAAABMeyAAAvZZbA= Date: Fri, 22 Jan 2016 16:04:13 +0000 Message-ID: <78791945dbf442b291adb72df8ec09f3@XCH-RCD-016.cisco.com> References: <1A27633A6DA49C4A92FCD5D4312DBF536B09F7A4@IRSMSX106.ger.corp.intel.com> <1670837.tJHuUIkoht@xps13> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.234.158] 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, 22 Jan 2016 16:04:22 -0000 > > xstats are driver agnostic and have a well-defined naming scheme. >=20 > Indeed, described here: > http://dpdk.org/doc/guides/prog_guide/poll_mode_drv.html#extended- > statistics-api Thanks for sharing. I do think what is in the link is well thought out but= it also may not match how the application would choose to represent that s= tat (capitalization, abbreviation, etc). > From: David Harton: > > For example, what if there was a kind of "stats registry" composed of > > ID and name. It would work similar to xtats except instead of > > advertising strings only the "get" API would return ID/count pairs. > > If the application wishes to use the DPDK provided string they can > > call another API to get the stat string via the ID. These IDs would > > be well-defined clearly explaining what the count represent. This way > > the strings for counts will be uniform across drivers and also make it > clear to the users what the counts truly represent and the application > could obtain stats from any driver in a driver agnostic manner. >=20 > What you (David Harton) describe about a well-defined name, and clearly > explaining the value it is representing is what the goal was for xstats: = a > human readable string, which can be easily parsed and a value retrieved. >=20 > The "rules" of encoding a statistic as an xstats string are pretty simple= , > and if any PMD breaks the rules, it should be considered broken and fixed= . I understand it may be broken, but that doesn't help finding them and ensur= ing they aren't broken to begin with. What regression/automation is in pla= ce to ensure drivers aren't broken? >=20 > Consistency is key, in this case consistency in the PMD xstats > implementations to make it useful for clients of the API. >=20 > The big advantage xstats has over adding items to rte_eth_stats is that i= t > won't break ABI. 100% agree. I can see the intent. >=20 > Do you see a fundamental problem with parsing the strings to retrieve > values? I think parsing strings is expensive CPU wise and again subject to error as= devices are added. That's why I was wondering if a binary id could be gen= erated instead. The binary id could also be used to look up the string nam= e if the application wants it. The API would be very similar to the curren= t xstats API except it would pass id/value pairs instead of string/value pa= irs. This avoids string comparisons to figure out while still allowing fle= xibility between drivers. It would also 100% guarantee that any strings re= turned by "const char* rte_eth_xstats_str_get(uint32_t stat_id)" are consis= tent across devices. I also think there is less chance for error if drivers assign their stats t= o ID versus constructing a string. I haven't checked my application, but I= wonder if the binary size would actually be smaller if all the stats strin= gs were centrally located versus distributed across binaries (highly depend= ent on the linker and optimization level). >=20 > If you like I could code up a minimal sample-app that only pulls > statistics, and you can show "interest" in various statistics for printin= g > / monitoring? Appreciate the offer. I actually understand what's is available. And, BTW= , I apologize for being late to the game (looks like this was discussed las= t summer) but I'm just now getting looped in and following the mailer but I= 'm just wondering if something that is performance friendly for the user/ap= plication and flexible for the drivers is possible. Thanks, Dave >=20 >=20 > Regards, -Harry