From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id C3EF8919B for ; Fri, 22 Jan 2016 17:41:36 +0100 (CET) Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga102.fm.intel.com with ESMTP; 22 Jan 2016 08:41:36 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.22,332,1449561600"; d="scan'208";a="732416196" Received: from irsmsx105.ger.corp.intel.com ([163.33.3.28]) by orsmga003.jf.intel.com with ESMTP; 22 Jan 2016 08:41:34 -0800 Received: from irsmsx111.ger.corp.intel.com (10.108.20.4) by irsmsx105.ger.corp.intel.com (163.33.3.28) with Microsoft SMTP Server (TLS) id 14.3.248.2; Fri, 22 Jan 2016 16:41:33 +0000 Received: from irsmsx102.ger.corp.intel.com ([169.254.2.97]) by irsmsx111.ger.corp.intel.com ([169.254.2.198]) with mapi id 14.03.0248.002; Fri, 22 Jan 2016 16:41:33 +0000 From: "Van Haaren, Harry" To: "David Harton (dharton)" , Thomas Monjalon Thread-Topic: [dpdk-dev] Future Direction for rte_eth_stats_get() Thread-Index: AdFToifrMKxGpVsMS/qKv8msWpPa2wABEBgwAFcuL6AAA/u1IAACHmaQAAF2QyAAAKFzAAAAQq/QAAJljoAAACWe0A== Date: Fri, 22 Jan 2016 16:41:32 +0000 Message-ID: References: <1A27633A6DA49C4A92FCD5D4312DBF536B09F7A4@IRSMSX106.ger.corp.intel.com> <1670837.tJHuUIkoht@xps13> <78791945dbf442b291adb72df8ec09f3@XCH-RCD-016.cisco.com> In-Reply-To: <78791945dbf442b291adb72df8ec09f3@XCH-RCD-016.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiZjYzZTE3ZDctYTE1Zi00ZDdhLWFkNTctYzUzNDQ1NTk5MjAxIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjQuMTAuMTkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiTk9YdEJpd2VTdHBQOHNGbjFVWG9EOWZWU0JRUXhKcHJkOXcrbFdpbDZocz0ifQ== x-ctpclassification: CTP_IC x-originating-ip: [163.33.239.182] 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:41:37 -0000 +Jay, (@all, please keep everybody in the CCs :) > From: David Harton (dharton) [mailto:dharton@cisco.com] > To: Van Haaren, Harry ; Thomas Monjalon > > > xstats are driver agnostic and have a well-defined naming scheme. > > > > Indeed, described here: > > http://dpdk.org/doc/guides/prog_guide/poll_mode_drv.html#extended- > > statistics-api >=20 > Thanks for sharing. I do think what is in the link is well thought out b= ut it also may > not match how the application would choose to represent that stat (capita= lization, > abbreviation, etc). Welcome. Sure, an application can match any xstats string to its "Display" = counterpart, or a few simple translations actually make (almost) all of them human reada= ble. Translating an _ to space, capitalize first letter of description items, and remove the= unit at the end). This use-case was considered when detailing the naming scheme. > > The "rules" of encoding a statistic as an xstats string are pretty simp= le, > > and if any PMD breaks the rules, it should be considered broken and fix= ed. >=20 > I understand it may be broken, but that doesn't help finding them and ens= uring they aren't > broken to begin with. What regression/automation is in place to ensure d= rivers aren't > broken? Currently nothing automated - patch review on the mailing list. I'm open to= ideas on this, if you have suggestions. > > Do you see a fundamental problem with parsing the strings to retrieve > > values? >=20 > I think parsing strings is expensive CPU wise Parsing the strings can be done once at startup, and the index of the stati= stics in the array cached. When actually reading statistics, access of the array of stat= istics at the previously cached index will return the same statistic. It is not needed to= do strcmp() per statistic per read. > That's why I was wondering if a binary id could be generated instead. I've worked with such a system before, it dynamically registered string->in= t mappings at runtime, and allowed "reverse" mapping them too. Its workable, and I'm not = opposed to it if the conclusion is that it really is necessary, but I'm not sure about th= at. > The API > would be very similar to the current xstats API except it would pass id/v= alue pairs > instead of string/value pairs. This avoids string comparisons to figure = out while still > allowing flexibility between drivers. Apart from a once-off scan at startup, xstats achieves this.=20 > It would also 100% guarantee that any strings > returned by "const char* rte_eth_xstats_str_get(uint32_t stat_id)" are co= nsistent across > devices. Yes - that is a nice feature that xstats (in its current form) doesn't have= . But what price is there to pay for this? We need to map an ID for each stat that exists. How and where will this mapping happen? Perhaps would you expand a little o= n how you see this working?=20 > I also think there is less chance for error if drivers assign their stats= to ID versus > constructing a string.=20 Have a look in how the mapping is done in the xstats implementation for ixg= be for example: http://dpdk.org/browse/dpdk/tree/drivers/net/ixgbe/ixgbe_ethdev.c#n540 It's a pretty simple {"string stat name" -> offsetof( stuct hw, register_v= ar_name )} > I haven't checked my application, but I wonder if the binary size > would actually be smaller if all the stats strings were centrally located= versus > distributed across binaries (highly dependent on the linker and optimizat= ion level). Sounds like optimizing the wrong thing to me. > > If you like I could code up a minimal sample-app that only pulls > > statistics, and you can show "interest" in various statistics for print= ing > > / monitoring? >=20 > Appreciate the offer. I actually understand what's is available. And, B= TW, I apologize > for being late to the game (looks like this was discussed last summer) bu= t I'm just now > getting looped in and following the mailer but I'm just wondering if some= thing that is > performance friendly for the user/application and flexible for the driver= s is possible. We're all looking for the same thing - just different approaches that's all= :) RE: Thomas asking about performance numbers: I can scrape together some raw tsc data on Monday and post to list, and we = can discuss it more then. Regards, -Harry