From: Kyle Larose <eomereadig@gmail.com>
To: Thomas Monjalon <thomas.monjalon@6wind.com>
Cc: dev@dpdk.org
Subject: Re: [PATCH 2/4] ethdev: expose extended error stats
Date: Wed, 17 Jun 2015 10:47:01 -0400 [thread overview]
Message-ID: <CAMFWN9nuMrCiPSWDPxfiOH+=11q-UUc2F3=KwqZ6svxDTODvcg@mail.gmail.com> (raw)
In-Reply-To: <6388992.ny7qEppTdV@xps13>
On Wed, Jun 17, 2015 at 9:58 AM, Thomas Monjalon
<thomas.monjalon@6wind.com> wrote:
[...]
>
> You are extending the generic stats. This is not the idea behind xstats.
> The xstats are specific to the driver.
> Furthermore we should migrate some "not really generic stats" to xstats
> in order to keep only the really basic and common stats in rte_eth_stats.
> By the way, in order to avoid duplicated code when getting generic stats
> through xstats API, we need to change the implementation of
> rte_eth_xstats_get() to add generic stats automatically, even if the
> driver provide some xstats.
This may be the wrong thread for this, and perhaps this question has
been answered (I couldn't find anything relating to it), but I have a
related question regarding exposing stats that are not captured in the
current device independent api (rte_eth_stats_get).
Is there a recommended strategy for displaying MIB interface stats for
applications using DPDK? For example, consider the IF-MIB
(http://www.ietf.org/rfc/rfc2233.txt). It provides three "normal" in
packet counters:
ifHCInUcastPkts
ifHCInMulticastPkts
ifHCInBroadcastPkts
Looking at rte_eth_stats, the structure returned by rte_eth_stats_get,
we can only retrieve the total number of in packets, and the total
number of in multicast packets. We can't retrieve the number of in
broadcast packets. This means that we neither display ifHCInUcastPkts
(which needs us to subtract mulicast and broadcast from the total),
nor ifHCInBroadcastPkts.
While I understand that some devices may not support classifying
packets into such categories, I would think that most NICs would try
to allow applications to conform the fairly established standards such
as the IF-MIB. One would think that maybe xstats would allow this:
these nics have low level stats that provide this information.
However, consumers of the API would need to understand each NIC's
implementation of the xstats API to use it, making it somewhat
cumbersome to use. I'd think that it makes sense for the MIB
information to live in a device-independent, well-defined API.
Does it make sense to provide sufficient information in the
eth_stats_get function to provide support for the various interface
stats mibs? Alternatively, does it make sense to make a new function
or API tailored to providing this support? It could be device
independent (unlike xstats), while allowing each driver to choose
whether or not it supports it.
I'm using a fairly old version of DPDK (1.7.1), but from looking at
the master branch
(http://dpdk.org/browse/dpdk/tree/lib/librte_ether/rte_ethdev.h), it
looks like the structure hasn't really changed.
I've been struggling to figure out the right away to approach this, so
any thoughts/insights would be much appreciated.
Thanks,
Kyle
next prev parent reply other threads:[~2015-06-17 14:47 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-05 17:35 [PATCH 0/4] expose ixgbe extended stats to dpdk apps Maryam Tahhan
2015-06-05 17:35 ` [PATCH 1/4] ixgbe: expose extended error statistics Maryam Tahhan
2015-06-08 13:26 ` Tahhan, Maryam
2015-06-10 0:51 ` Stephen Hemminger
2015-06-10 14:24 ` Tahhan, Maryam
2015-06-17 12:52 ` Thomas Monjalon
2015-06-05 17:35 ` [PATCH 2/4] ethdev: expose extended error stats Maryam Tahhan
2015-06-17 13:58 ` Thomas Monjalon
2015-06-17 14:47 ` Kyle Larose [this message]
2015-06-22 14:12 ` Tahhan, Maryam
2015-06-22 15:12 ` Olivier MATZ
2015-06-22 15:35 ` Tahhan, Maryam
2015-06-05 17:35 ` [PATCH 3/4] testpmd: extend testpmd to show all extended stats Maryam Tahhan
2015-06-05 17:35 ` [PATCH 4/4] app: replace dump_cfg with proc_info Maryam Tahhan
2015-06-05 21:08 ` Thomas Monjalon
2015-06-08 13:45 ` Tahhan, Maryam
2015-06-08 14:22 ` Thomas Monjalon
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='CAMFWN9nuMrCiPSWDPxfiOH+=11q-UUc2F3=KwqZ6svxDTODvcg@mail.gmail.com' \
--to=eomereadig@gmail.com \
--cc=dev@dpdk.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.