From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vk0-f53.google.com (mail-vk0-f53.google.com [209.85.213.53]) by dpdk.org (Postfix) with ESMTP id F1C448EA1 for ; Fri, 22 Jan 2016 16:53:25 +0100 (CET) Received: by mail-vk0-f53.google.com with SMTP id n1so43221376vkb.3 for ; Fri, 22 Jan 2016 07:53:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=infiniteio-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=YiqkMOAOFqj16KLfHPMWWKYjkXoETS84EVimBnMPSuU=; b=oqIW1Q1+M02XRsqAzOPpBkwmttCN/1vv2nPNogNw7XYOvmLTZ5G7eiiDWVpZGpXVsi ojoh4iqHihnSX6Yh8ZEbDfYMtXFpDBJhab0tQ3+rE9aJbvgvChtd+i3RGU3GzHswpWwV iCq/2p5LY3kUK7Hgk3mFYAOGoFc6Hp8S1FhMqrCHx81/T44ie+sZwqaMFlAkFE75WgiU SAMrq3sVH2tbuQE0kxvtSE7YVDPJwddpCbd1ymuJ0Ev71i3euTk8+BUc22uQMaMlQ8FT FGZ/fJpRQI7Cb7v8lTt9guL2EVUsp7ZdBLLJmW4w+zIBodq7V44KEAd312iegfavQP1w Mgag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=YiqkMOAOFqj16KLfHPMWWKYjkXoETS84EVimBnMPSuU=; b=I4+TC8tJaBaKj15QMGr6v8LwXoQHkKTjGC1uH+qRZ0EFi5PKnqDbQj51deOf0uGX7X weheh/S9YpQpah8oz02/LZ6oDirZ/QmBofO42fFHETC8835cZFh4p1NGFFEu9TmsjS9+ SuiR1H/3n9bBfHe1P0rLyrvGfyPWo6ZB1i038l1BcOyTiLHCGKhnvURWaXjj7sJ4+G+5 VDK3CNOJqCPxZYx/+IU2uhWR3LyolFZG5Olr+x1A13dgkMg+Vvx8rcpyvfo1aRK+q/Pn 5VzFKGmu8JvUufbm7S2AEuEej6qfr0f/LHBbmgPOecuWcflJKzHXEXFSfIZHcnj6SAXI s3Cw== X-Gm-Message-State: AG10YOTn37fEEZbiYbnG69ywnb4p5r81idl8ynjagmyYA4JmvDga5WhHEfa6xw7E4842ZvxMiMGPwwD49Tl/Tg== MIME-Version: 1.0 X-Received: by 10.31.173.8 with SMTP id w8mr2351524vke.42.1453478005469; Fri, 22 Jan 2016 07:53:25 -0800 (PST) Received: by 10.103.96.3 with HTTP; Fri, 22 Jan 2016 07:53:25 -0800 (PST) In-Reply-To: References: <1A27633A6DA49C4A92FCD5D4312DBF536B09F7A4@IRSMSX106.ger.corp.intel.com> <1670837.tJHuUIkoht@xps13> Date: Fri, 22 Jan 2016 09:53:25 -0600 Message-ID: From: Jay Rolette To: "Van Haaren, Harry" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.15 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 15:53:26 -0000 On Fri, Jan 22, 2016 at 9:22 AM, Van Haaren, Harry < harry.van.haaren@intel.com> wrote: > > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > > Subject: Re: [dpdk-dev] Future Direction for rte_eth_stats_get() > > > + Harry > > Hey all, > > > 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 > > All of the rte_eth_stats statistics are presented in xstats consistently > (independent of which PMD is running), as they are implemented in > rte_ethdev.c: > http://dpdk.org/browse/dpdk/tree/lib/librte_ether/rte_ethdev.c#n1500 > > > From: David Harton: > > For example, what if there was a kind of "stats registry" composed of ID > and name. It > > would work similar to xtats except instead of advertising strings only > the "get" API would > > return ID/count pairs. If the application wishes to use the DPDK > provided string they can > > call another API to get the stat string via the ID. These IDs would be > well-defined > > clearly explaining what the count represent. This way the strings for > counts will be > > uniform across drivers and also make it clear to the users what the > counts truly represent > > and the application could obtain stats from any driver in a driver > agnostic manner. > > What you (David Harton) describe about a well-defined name, and clearly > explaining the value > it is representing is what the goal was for xstats: a human readable > string, which can be > easily parsed and a value retrieved. > > The "rules" of encoding a statistic as an xstats string are pretty simple, > and if any PMD > breaks the rules, it should be considered broken and fixed. > > Consistency is key, in this case consistency in the PMD xstats > implementations to make it > useful for clients of the API. > > The big advantage xstats has over adding items to rte_eth_stats is that it > won't break ABI. > > Do you see a fundamental problem with parsing the strings to retrieve > values? > When you have an appliance with a large number of ports and a large number of stats that you need to collect, having to parse those strings constantly is very slow compared to having fixed struct members or at least known ID values. Strings are also error prone. While they may be consistent at this point, it is remarkably easy for them to get out of sync along the way. Using an ID instead avoids that neatly. Jay