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 631FE8DB3 for ; Fri, 22 Jan 2016 14:40:46 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3604; q=dns/txt; s=iport; t=1453470046; x=1454679646; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=9kIeM4amj55FjIDZMPsBPe/w0989sz5alBtemrrXc5I=; b=ZzD6v+/g97US1jnnc0F/oSO+njUXd9iTj5sDryjqsNuWaMZAbq9FGjKp ZRpOmtvh6UaAg8W3umTDS1dWneQST5YyM/Z6oPnMqLPyiS82XwDxWIbeO wYuXNI6QfymyxOdp0h6McqvkKRRS3NC7lhpmYzTMGhWBLJmdYVz8rjHZ1 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ABAgA9MKJW/51dJa1egzpSbQaIUbIGA?= =?us-ascii?q?Q2BYiKFbQKBOzgUAQEBAQEBAYEKhEEBAQEEOksEAgEIEQQBAR8JBzIUCQgBAQQ?= =?us-ascii?q?BEgiIEw6+KgEBAQEBAQEBAQEBAQEBAQEBAQEXhjKEbYR9hAkFkl+EFwGFRYgJg?= =?us-ascii?q?i+IGIQ5RI16AR4BAUKDZmqGJ3wBAQE?= X-IronPort-AV: E=Sophos;i="5.22,331,1449532800"; d="scan'208";a="64202643" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Jan 2016 13:40:44 +0000 Received: from XCH-RCD-016.cisco.com (xch-rcd-016.cisco.com [173.37.102.26]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u0MDejZL027132 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 22 Jan 2016 13:40:45 GMT Received: from xch-rcd-016.cisco.com (173.37.102.26) by XCH-RCD-016.cisco.com (173.37.102.26) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 22 Jan 2016 07:40:44 -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 07:40:44 -0600 From: "David Harton (dharton)" To: "Tahhan, Maryam" , "dev@dpdk.org" Thread-Topic: Future Direction for rte_eth_stats_get() Thread-Index: AdFToifrMKxGpVsMS/qKv8msWpPa2wABEBgwAFcuL6AAA/u1IA== Date: Fri, 22 Jan 2016 13:40:44 +0000 Message-ID: <74583418c4374c349bfdea0c59b84118@XCH-RCD-016.cisco.com> References: <1A27633A6DA49C4A92FCD5D4312DBF536B09F44B@IRSMSX106.ger.corp.intel.com> In-Reply-To: <1A27633A6DA49C4A92FCD5D4312DBF536B09F44B@IRSMSX106.ger.corp.intel.com> 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 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 13:40:46 -0000 Hi Maryam, Thanks for the pointer. I'll review the convo's. Consider I have an application that uses many(all?) of the DPDK drivers and= their netmap counterparts depending on configuration. The user interface = provides a set of I/O stats to help debug I/O issues and that set is the sa= me regardless of driver type. The set of stats provided matches what linux= provides today since netmap existed before dpdk. What I want to avoid is having an application that is driver independent ha= ving to become driver dependent interpreting a bunch of strings (from xstat= s) or worse the layer running at the data plane core that is advertising th= e API needed by the application parsing those strings because the applicati= on cannot change the upper layer. What if instead of passing strings and values a set of stat ids and value a= re returned. At least this way the application can remain driver agnostic = versus having to parse a free form string that likely isn't the same across= driver types. Also, why wouldn't rte_eth_stats_get() align with linux which is the defact= o standard? I understand that not every driver may not support every stat = but that's ok. Just return 0 (pause frames, crc errors, etc). It's not li= ke the list of linux stats is ever growing or advertising an absurd number = of stats that aren't applicable to all drivers. Thanks again, Dave > -----Original Message----- > From: Tahhan, Maryam [mailto:maryam.tahhan@intel.com] > Sent: Friday, January 22, 2016 6:08 AM > To: David Harton (dharton) ; dev@dpdk.org > Subject: RE: Future Direction for rte_eth_stats_get() >=20 > Hi David > Some of the stats were HW specific rather than generic stats that should > be exposed through rte_eth_stats and were migrated to the xstats API. > http://dpdk.org/ml/archives/dev/2015-June/019915.html. The naming was als= o > not generic enough to cover some of the drivers and in some cases what wa= s > exposed was only a partial view of the relevant stats. >=20 > They were marked as deprecated to deter people from using them in the > future, but haven't been removed from all the driver implementations yet. > The Registers that remain undeprecated are those considered to be generic= . >=20 > Which registers are you particularly interested in that have been > deprecated? Can you elaborate on what you mean by " scenarios where a > static view is expected " >=20 > Thanks in advance. >=20 > Best Regards, > Maryam >=20 >=20 > > -----Original Message----- > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of David Harton > > (dharton) > > Sent: Wednesday, January 20, 2016 5:19 PM > > To: dev@dpdk.org > > Subject: [dpdk-dev] Future Direction for rte_eth_stats_get() > > > > I see that some of the rte_eth_stats have been marked deprecated in 2.2 > > that are returned by rte_eth_stats_get(). Applications that utilize an= y > > number of device types rely on functions like this one to debug I/O > > issues. > > > > Is there a reason the stats have been deprecated? Why not keep the > > stats in line with the standard linux practices such as > rtnl_link_stats64? > > > > Note, using rte_eth_xstats_get() does not help for this particular > scenario > > because a common binary API is needed to communicate through > > various layers and also provide a consistent view/meaning to users. Th= e > > xstats is excellent for debugging device specific scenarios but can't > help > > in scenarios where a static view is expected. > > > > Thanks, > > Dave