From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by dpdk.org (Postfix) with ESMTP id 1A2F5918F for ; Fri, 22 Jan 2016 15:18:46 +0100 (CET) Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga104.fm.intel.com with ESMTP; 22 Jan 2016 06:18:45 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.22,331,1449561600"; d="scan'208";a="732337958" Received: from irsmsx105.ger.corp.intel.com ([163.33.3.28]) by orsmga003.jf.intel.com with ESMTP; 22 Jan 2016 06:18:45 -0800 Received: from irsmsx106.ger.corp.intel.com ([169.254.8.197]) by irsmsx105.ger.corp.intel.com ([169.254.7.237]) with mapi id 14.03.0248.002; Fri, 22 Jan 2016 14:18:08 +0000 From: "Tahhan, Maryam" To: "David Harton (dharton)" , "dev@dpdk.org" Thread-Topic: Future Direction for rte_eth_stats_get() Thread-Index: AdFToifrMKxGpVsMS/qKv8msWpPa2wABEBgwAFcuL6AAA/u1IAACHmaQ Date: Fri, 22 Jan 2016 14:18:07 +0000 Message-ID: <1A27633A6DA49C4A92FCD5D4312DBF536B09F7A4@IRSMSX106.ger.corp.intel.com> References: <1A27633A6DA49C4A92FCD5D4312DBF536B09F44B@IRSMSX106.ger.corp.intel.com> <74583418c4374c349bfdea0c59b84118@XCH-RCD-016.cisco.com> In-Reply-To: <74583418c4374c349bfdea0c59b84118@XCH-RCD-016.cisco.com> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMzJjMmNmNWItMmZjNS00ODZmLThjODAtNmQ5N2YxYWI5N2U2IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX1BVQkxJQyJ9XX1dfSwiU3ViamVjdExhYmVscyI6W10sIlRNQ1ZlcnNpb24iOiIxNS40LjEwLjE5IiwiVHJ1c3RlZExhYmVsSGFzaCI6Ilc5ZHQzeWlab01JUHNjMFhyZHlqa1VTRFwveVJWTzdGN0RsTTRIUDdBY1wvbz0ifQ== 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 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:18:47 -0000 Hi David + Olivier and Harry as contributors and advisors in the past on the stats a= nd stats API. 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_ethe= r/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 error= and drops for struct rte_eth_stats at the moment only drops are reported t= hrough 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 linux = */ is in struct rte_eth_stats 50 __u64 multicast; /* multicast packets received = */ was deprecated in struct rte_eth_stats - but we can remo= ve 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...=20 52=20 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 d= rivers we modified 55 __u64 rx_over_errors; /* receiver ring buff overflow = */ 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 - but= 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 al= l drivers 59 __u64 rx_missed_errors; /* receiver missed packet = */ was deprecated in struct rte_eth_stats, is in xstats - but we ca= n remove the notice 60=20 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_sta= ts. 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. N= ot exposed by all drivers 66 __u64 tx_window_errors; = was never in struct rte_eth_stats. = Not exposed by all drivers 67=20 68 /* for cslip etc */ 69 __u64 rx_compressed; = was never in struct rte_eth_stat= s. Not exposed by all drivers 70 __u64 tx_compressed; = was never in struct rte_eth_stat= s. Not exposed by all drivers 71 }; So what can be enabled again in struct rte_eth_stats from what was already= there is the equivalent of:=20 * rx_length_errors * rx_crc_errors * rx_missed_errors - the deprecation notice was removed for this field. * multicast What should be added in to distinguish between errors and drops. struct rte= _eth_stats : * rx_errors * tx_errors As for the detailed rx errors and tx errors I'm open to feedback from you f= olks as to what should go in and what is too detailed. These weren't in str= uct rte_eth_stats previously, they are available through xstats and are uni= formly named across the drivers. Oliver + Harry any thoughts? David I assume you are looking for all the missing fields to be added? Best Regards,=20 Maryam > -----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() >=20 > Hi Maryam, >=20 > Thanks for the pointer. I'll review the convo's. >=20 > 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. >=20 > What I want to avoid is having an application that is driver independent > 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. >=20 > 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 the > same across driver types. >=20 > 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. >=20 > Thanks again, > Dave >=20 > > -----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