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 EB0F45A44 for ; Fri, 22 Jan 2016 15:40:48 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10444; q=dns/txt; s=iport; t=1453473648; x=1454683248; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=4BADHg6zNEIq6VwrNg4x3m333SDKIcT9Z+wHJl7NH+A=; b=I4fXc+9ceyUzTvEmnQgbRDMV4STQJrSLNA//wpmRfwfZYBJmGiEawnfu hJ9YkbghwFod/T4eN0G2+2RMW7C2EBgfkbnFkRDb4vU0xxjrHc3xaQ2W0 3ZcefJF+wAZqe8F96ZzYxFih76pDQPT+o+pENvxmw8qy71T03d5IqNyVN w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CLAgAfPqJW/5JdJa1egzpSbQaEJYQss?= =?us-ascii?q?gYBDYFiIoVtAoE7OBQBAQEBAQEBgQqEQQEBAQQ6PwwEAgEIEQQBAR8JBzIUCQg?= =?us-ascii?q?BAQQBDQUIiBMOvjwBAQEBAQEBAQEBAQEBAQEBAQEBAQEVhjKEbYRRLIQJBY0qh?= =?us-ascii?q?TWEFwGFRYVWgjOBezSIGIQ5RI16AR4BAUKBexuBUGoBhiZ8AQEB?= X-IronPort-AV: E=Sophos;i="5.22,331,1449532800"; d="scan'208";a="64219453" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Jan 2016 14:40:47 +0000 Received: from XCH-ALN-017.cisco.com (xch-aln-017.cisco.com [173.36.7.27]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u0MEelRL011278 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 22 Jan 2016 14:40:47 GMT Received: from xch-rcd-016.cisco.com (173.37.102.26) by XCH-ALN-017.cisco.com (173.36.7.27) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 22 Jan 2016 08:40:46 -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 08:40:46 -0600 From: "David Harton (dharton)" To: "Tahhan, Maryam" , "dev@dpdk.org" Thread-Topic: Future Direction for rte_eth_stats_get() Thread-Index: AdFToifrMKxGpVsMS/qKv8msWpPa2wABEBgwAFcuL6AAA/u1IAACHmaQAAF2QyA= Date: Fri, 22 Jan 2016 14:40:46 +0000 Message-ID: References: <1A27633A6DA49C4A92FCD5D4312DBF536B09F44B@IRSMSX106.ger.corp.intel.com> <74583418c4374c349bfdea0c59b84118@XCH-RCD-016.cisco.com> <1A27633A6DA49C4A92FCD5D4312DBF536B09F7A4@IRSMSX106.ger.corp.intel.com> In-Reply-To: <1A27633A6DA49C4A92FCD5D4312DBF536B09F7A4@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 14:40:49 -0000 Hi Maryam, I'm not dictating they be re-added (although adding would be nice) but more= important I'm trying to express an application view point rather than a dr= iver view point. =20 I completely understand how a driver wants to be able to advertise all the = stats they want to advertise to help them debug their issues (i.e. xstats).= Yet, I'm very interested in DPDK providing a driver agnostic method of a= dvertising well-defined stats. For example, what if there was a kind of "stats registry" composed of ID an= d name. It would work similar to xtats except instead of advertising strin= gs only the "get" API would return ID/count pairs. If the application wish= es to use the DPDK provided string they can call another API to get the sta= t string via the ID. These IDs would be well-defined clearly explaining wh= at the count represent. This way the strings for counts will be uniform ac= ross drivers and also make it clear to the users what the counts truly repr= esent and the application could obtain stats from any driver in a driver ag= nostic manner. Just an idea, Dave > -----Original Message----- > From: Tahhan, Maryam [mailto:maryam.tahhan@intel.com] > Sent: Friday, January 22, 2016 9:18 AM > To: David Harton (dharton) ; dev@dpdk.org > Cc: Olivier MATZ ; Van Haaren, Harry > > Subject: RE: Future Direction for rte_eth_stats_get() >=20 > Hi David >=20 > + Olivier and Harry as contributors and advisors in the past on the stats > and stats API. >=20 > So I pulled the rtnl_link_stats64 from http://lxr.free- > electrons.com/source/include/uapi/linux/if_link.h#L41 and crossed them > with http://dpdk.org/dev/patchwork/patch/5842/ and > http://dpdk.org/browse/dpdk/tree/lib/librte_ether/rte_ethdev.h >=20 > 40 /* The main device statistics structure */ > 41 struct rtnl_link_stats64 { > 42 __u64 rx_packets; /* total packets received > */ is in struct rte_eth_stats > 43 __u64 tx_packets; /* total packets transmitted > */ is in struct rte_eth_stats > 44 __u64 rx_bytes; /* total bytes received > */ is in struct rte_eth_stats > 45 __u64 tx_bytes; /* total bytes transmitted > */ is in struct rte_eth_stats > 46 __u64 rx_errors; /* bad packets received > */ I'm working on a patch to distinguish between erro= r > and drops for struct rte_eth_stats at the moment only drops are reported > through ierrors and oerrors and we are tied to those field name for > backward compatibility. > 47 __u64 tx_errors; /* packet transmit problems > */ Same comment as rx_errors. > 48 __u64 rx_dropped; /* no space in linux buffers > */ is in struct rte_eth_stats > 49 __u64 tx_dropped; /* no space available in linu= x > */ is in struct rte_eth_stats > 50 __u64 multicast; /* multicast packets received > */ was deprecated in struct rte_eth_stats - but we can > remove the notice and expose again from drivers we modified > 51 __u64 collisions; Not in struct rte_eth_stats - not > sure it's in xstats either... > 52 > 53 /* detailed rx_errors: */ > 54 __u64 rx_length_errors; > was deprecated in struct rte_eth_stats, is in xstats - but we can > remove the notice and expose again from drivers we modified > 55 __u64 rx_over_errors; /* receiver ring buff overflo= w > */ was never exposed to struct rte_eth_stats - but is in xstats. > 56 __u64 rx_crc_errors; /* recved pkt with crc error > */ was deprecated in struct rte_eth_stats, is in xstats - bu= t > we can remove the notice and expose again from drivers we modified > 57 __u64 rx_frame_errors; /* recv'd frame alignment > error */ was never exposed to struct rte_eth_stats - but is in > xstats. > 58 __u64 rx_fifo_errors; /* recv'r fifo overrun > */ was never in struct rte_eth_stats. Not exposed by > all drivers > 59 __u64 rx_missed_errors; /* receiver missed packet > */ was deprecated in struct rte_eth_stats, is in xstats - but we > can remove the notice > 60 > 61 /* detailed tx_errors */ > 62 __u64 tx_aborted_errors; > was never in struct rte_eth_stats. Not exposed by all drivers > 63 __u64 tx_carrier_errors; > was never in struct rte_eth_stats. Not exposed by all drivers > 64 __u64 tx_fifo_errors; > was never in struct rte_eth_stats. Not exposed by all drivers > 65 __u64 tx_heartbeat_errors; > was never in struct rte_eth_stats. Not exposed by all drivers > 66 __u64 tx_window_errors; > was never in struct rte_eth_stats. Not exposed by all drivers > 67 > 68 /* for cslip etc */ > 69 __u64 rx_compressed; > was never in struct rte_eth_stats. Not exposed by all drivers > 70 __u64 tx_compressed; > was never in struct rte_eth_stats. Not exposed by all drivers > 71 }; >=20 > So what can be enabled again in struct rte_eth_stats from what was > already there is the equivalent of: > * rx_length_errors > * rx_crc_errors > * rx_missed_errors - the deprecation notice was removed for this field. > * multicast >=20 > What should be added in to distinguish between errors and drops. struct > rte_eth_stats : > * rx_errors > * tx_errors >=20 > As for the detailed rx errors and tx errors I'm open to feedback from you > folks as to what should go in and what is too detailed. These weren't in > struct rte_eth_stats previously, they are available through xstats and ar= e > uniformly named across the drivers. Oliver + Harry any thoughts? >=20 > David I assume you are looking for all the missing fields to be added? >=20 > Best Regards, > Maryam >=20 >=20 > > -----Original Message----- > > From: David Harton (dharton) [mailto:dharton@cisco.com] > > Sent: Friday, January 22, 2016 1:41 PM > > To: Tahhan, Maryam ; dev@dpdk.org > > Subject: RE: Future Direction for rte_eth_stats_get() > > > > 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 same 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 independen= t > > having to become driver dependent interpreting a bunch of strings > > (from xstats) or worse the layer running at the data plane core that is > > advertising the API needed by the application parsing those strings > > because the application cannot change the upper layer. > > > > What if instead of passing strings and values a set of stat ids and > value > > are returned. At least this way the application can remain driver > > agnostic versus having to parse a free form string that likely isn't th= e > > same across driver types. > > > > Also, why wouldn't rte_eth_stats_get() align with linux which is the > > defacto 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 like 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() > > > > > > 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 > > > also not generic enough to cover some of the drivers and in some > > cases > > > what was exposed was only a partial view of the relevant stats. > > > > > > 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. > > > > > > 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 " > > > > > > Thanks in advance. > > > > > > Best Regards, > > > Maryam > > > > > > > > > > -----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 any 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. The > > > > xstats is excellent for debugging device specific scenarios but > > > > can't > > > help > > > > in scenarios where a static view is expected. > > > > > > > > Thanks, > > > > Dave