DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Van Haaren, Harry" <harry.van.haaren@intel.com>
To: Thomas Monjalon <thomas.monjalon@6wind.com>,
	"David Harton (dharton)" <dharton@cisco.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] Future Direction for rte_eth_stats_get()
Date: Fri, 22 Jan 2016 15:22:21 +0000	[thread overview]
Message-ID: <E923DB57A917B54B9182A2E928D00FA6128617BE@IRSMSX102.ger.corp.intel.com> (raw)
In-Reply-To: <1670837.tJHuUIkoht@xps13>

> 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?

If you like I could code up a minimal sample-app that only pulls statistics,
and you can show "interest" in various statistics for printing / monitoring?


Regards, -Harry

  reply	other threads:[~2016-01-22 15:22 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-20 17:18 David Harton (dharton)
2016-01-22 11:07 ` Tahhan, Maryam
2016-01-22 13:40   ` David Harton (dharton)
2016-01-22 14:18     ` Tahhan, Maryam
2016-01-22 14:40       ` David Harton (dharton)
2016-01-22 14:48         ` Thomas Monjalon
2016-01-22 15:22           ` Van Haaren, Harry [this message]
2016-01-22 15:53             ` Jay Rolette
2016-01-22 16:04             ` David Harton (dharton)
2016-01-22 16:37               ` Thomas Monjalon
2016-01-22 16:41               ` Van Haaren, Harry
2016-01-22 19:26                 ` David Harton (dharton)
2016-01-28  9:37                   ` Van Haaren, Harry
2016-02-01 16:47                   ` David Harton (dharton)
2016-02-01 21:23                     ` Matthew Hall
2016-02-02 11:40                     ` Van Haaren, Harry
2016-02-05 21:16                       ` David Harton (dharton)
2016-02-19  8:59                         ` Tahhan, Maryam
2016-01-22 14:44       ` Thomas Monjalon
2016-01-22 14:48         ` Tahhan, Maryam
2016-01-22 15:02         ` Igor Ryzhov
2016-01-22 20:48           ` Matthew Hall
2016-02-02 12:44             ` Tahhan, Maryam
2016-02-02 13:47               ` Kyle Larose

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=E923DB57A917B54B9182A2E928D00FA6128617BE@IRSMSX102.ger.corp.intel.com \
    --to=harry.van.haaren@intel.com \
    --cc=dev@dpdk.org \
    --cc=dharton@cisco.com \
    --cc=thomas.monjalon@6wind.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).