From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) by dpdk.org (Postfix) with ESMTP id 8CCD5C362 for ; Fri, 5 Feb 2016 22:16:16 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2328; q=dns/txt; s=iport; t=1454706976; x=1455916576; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=D5lpQIscD/wG7L3He7HPtEywVLqOR+cwTF9kL+Mqmd4=; b=mTn5cg0aXjtWMIWhBBYqmH/CdSLB5ePMTsfmrBZMerOZghUc9kOn4gW0 JjMVLXRLKi+7V6tgGKOe+XCWjxeMd54z/DP3Ckoh/H1hEc93YOjefpJIi 2adYaSdT+cn7/rLXTF1HHcfgJCPzdsABLnvkvL/JSIzS1+4ePxc5ZvaQF w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AQAgBmELVW/5NdJa1egzpSbQaIVbELA?= =?us-ascii?q?Q2BZiGFbAKBNTgUAQEBAQEBAYEKhEEBAQEDATo/BQsCAQgVAh8JBzIUCQgCBAE?= =?us-ascii?q?NBQiICwgOvzABAQEBAQEBAQEBAQEBAQEBAQEBARaGEoQ3hBMBAU+ECAWNJ4lOA?= =?us-ascii?q?YVLh32BYkqMTkSKKINRAR4BAUKDZGoBiEs0fAEBAQ?= X-IronPort-AV: E=Sophos;i="5.22,402,1449532800"; d="scan'208";a="233642112" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Feb 2016 21:16:15 +0000 Received: from XCH-ALN-018.cisco.com (xch-aln-018.cisco.com [173.36.7.28]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u15LGFjm002902 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 5 Feb 2016 21:16:15 GMT Received: from xch-rcd-016.cisco.com (173.37.102.26) by XCH-ALN-018.cisco.com (173.36.7.28) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 5 Feb 2016 15:16:14 -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, 5 Feb 2016 15:16:14 -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/u1IAACHmaQAAF2QyAADTQZAAABMeyAAAvZZbD//7dUAIAAYwVg//EX76CAH3p7AP/7EJUA Date: Fri, 5 Feb 2016 21:16:14 +0000 Message-ID: References: <1A27633A6DA49C4A92FCD5D4312DBF536B09F7A4@IRSMSX106.ger.corp.intel.com> <1670837.tJHuUIkoht@xps13> <78791945dbf442b291adb72df8ec09f3@XCH-RCD-016.cisco.com> <3b3f956b6f7c490181b3db81b2c8d99a@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-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.229.227] 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, 05 Feb 2016 21:16:17 -0000 > From: Van Haaren, Harry [mailto:harry.van.haaren@intel.com] >=20 > > From: David Harton > > Subject: RE: [dpdk-dev] Future Direction for rte_eth_stats_get() > > > > Hi folks, > > > > I didn't see any follow up to this response. >=20 > I think you may have missed one: > http://dpdk.org/ml/archives/dev/2016-January/032211.html Apologies Harry! I didn't see your original post because the IT gods had d= ecided your response was "Junk" mail and it didn't make it to my dev_dpdk.o= rg mail folder. :( A colleague actually pointed me to this post separately today. I've made t= he Junk mailer a little smarter now...hopefully. >=20 > I'm looking at the enum thinking it will grow out of control. > Have you thought about adding metadata for RX / TX, PF / VF? Yes, after thinking about it more I think it could get crazy. >=20 > If metadata info is added, it would make retrieving a set of statistics > based on a certain mask much easier. Do you think this may be of use? Actually, I put a fair bit of thought into things and then realized, why re= -invent the wheel? Why not follow the ethtool stats model? struct rte_eth_xstats_name { char name[RTE_ETH_XSTATS_NAME_SIZE]; }; extern int rte_eth_xtats_count(uint8_t port_id, unsigned *count); extern int rte_eth_xtats_strings(uint8_t port_id, unsigned count, struct rt= e_eth_xtats_name *names); extern int rte_eth_xtats_values(uint8_t port_id, unsigned count, uint64_t *= values); The existing API could be left in-place and these could be added for folks = that don't want to grab the strings all the time. The cons compared to providing an enum or extending struct rte_eth_stats ar= e: - you have to perform a query immediately after the device is attached - doesn't require conformity...which has pros and cons I'm actually testing the changes above if folks think this would be a reaso= nable compromise I can patch them up. I still feel the feedback myself and others gave about rte_eth_stats_get() = being closer to a standard MIB should get some consideration. Applications= that run with a number of different drivers/device types likely want to av= oid having to create "xstats mapping tables" every time a new device pops o= ut just so they can debug problems. Thanks, Dave