From: Kyle Larose <eomereadig@gmail.com>
To: Maryam Tahhan <maryam.tahhan@intel.com>
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH v3 4/7] ethdev: remove HW specific stats in stats structs
Date: Fri, 26 Jun 2015 10:03:49 -0400 [thread overview]
Message-ID: <CAMFWN9niCGwX7Z2qDmi3J4-egyGtK464Q6YZrPeSoXN5OQEM4g@mail.gmail.com> (raw)
In-Reply-To: <1435323558-169985-5-git-send-email-maryam.tahhan@intel.com>
On Fri, Jun 26, 2015 at 8:59 AM, Maryam Tahhan <maryam.tahhan@intel.com>
wrote:
> Remove non generic stats in rte_stats_strings and mark the relevant
> fields in struct rte_eth_stats as deprecated.
>
> Signed-off-by: Maryam Tahhan <maryam.tahhan@intel.com>
> ---
> doc/guides/rel_notes/abi.rst | 11 +++++++++++
> lib/librte_ether/rte_ethdev.c | 9 ---------
> lib/librte_ether/rte_ethdev.h | 30 ++++++++++++++++++++----------
> 3 files changed, 31 insertions(+), 19 deletions(-)
>
> diff --git a/doc/guides/rel_notes/abi.rst b/doc/guides/rel_notes/abi.rst
> index f00a6ee..957b13f 100644
> --- a/doc/guides/rel_notes/abi.rst
> +++ b/doc/guides/rel_notes/abi.rst
> @@ -38,3 +38,14 @@ Examples of Deprecation Notices
>
> Deprecation Notices
> -------------------
> +* The following fields have been deprecated in rte_eth_stats:
> + * uint64_t imissed
> + * uint64_t ibadcrc
> + * uint64_t ibadlen
> + * uint64_t imcasts
> + * uint64_t fdirmatch
> + * uint64_t fdirmiss
> + * uint64_t tx_pause_xon
> + * uint64_t rx_pause_xon
> + * uint64_t tx_pause_xoff
> + * uint64_t rx_pause_xoff
>
>
Are CRC errors (ibadcrc) truly hardware specific? Which NIC (aside from
purely virtual ones) does not have a MAC which does frame checksumming?
Likewise, which NIC doesn't drop because the PCI bus/cpu/etc is too busy to
pull packets off of it (imissed)?
Debugging interactions with NICs is hard enough with only CRC errors and
missed packets to go on. Without those it is close to impossible. CRC
errors are almost guaranteed any time a bare-metal application is deployed:
dirty fiber, bad SFPs, etc. How will users of the application be able to
determine why their packets are dropping if they can only see "in errors"?
I understand that we want to avoid placing too much useless information
into these statistics structures. However, without a hardware-independent
way of accessing fairly standard networking-equipment diagnostics, I feel
like any real-world application using DPDK will be terribly cumbersome to
build: every single one will need to develop an abstraction layer which
detects the attached NICs, and loads an appropriate driver to integrate
with the xstats api.
Is there any plan for such an API? If not, is it really a good idea to
deprecate these stats?
Thanks,
Kyle
next prev parent reply other threads:[~2015-06-26 14:03 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-26 12:59 [dpdk-dev] [PATCH v3 0/7] Expose IXGBE extended stats to DPDK apps Maryam Tahhan
2015-06-26 12:59 ` [dpdk-dev] [PATCH v3 1/7] ixgbe: move stats register reads to a new function Maryam Tahhan
2015-06-26 12:59 ` [dpdk-dev] [PATCH v3 2/7] ixgbe: add functions to get and reset xstats Maryam Tahhan
2015-07-03 13:16 ` Olivier MATZ
2015-07-03 13:19 ` Olivier MATZ
2015-07-05 9:34 ` Tahhan, Maryam
2015-07-05 10:02 ` Tahhan, Maryam
2015-07-05 9:27 ` Tahhan, Maryam
2015-06-26 12:59 ` [dpdk-dev] [PATCH v3 3/7] ethdev: expose extended error stats Maryam Tahhan
2015-07-03 13:27 ` Olivier MATZ
2015-06-26 12:59 ` [dpdk-dev] [PATCH v3 4/7] ethdev: remove HW specific stats in stats structs Maryam Tahhan
2015-06-26 14:03 ` Kyle Larose [this message]
2015-06-26 14:30 ` Tahhan, Maryam
2015-06-26 14:37 ` Kyle Larose
2015-06-26 14:47 ` Tahhan, Maryam
2015-06-26 12:59 ` [dpdk-dev] [PATCH v3 5/7] ixgbe: add NIC specific stats removed from ethdev Maryam Tahhan
2015-06-26 12:59 ` [dpdk-dev] [PATCH v3 6/7] app: remove dump_cfg Maryam Tahhan
2015-06-26 12:59 ` [dpdk-dev] [PATCH v3 7/7] app: add a new app proc_info Maryam Tahhan
2015-07-01 14:27 ` [dpdk-dev] [PATCH v3 0/7] Expose IXGBE extended stats to DPDK apps Tahhan, Maryam
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=CAMFWN9niCGwX7Z2qDmi3J4-egyGtK464Q6YZrPeSoXN5OQEM4g@mail.gmail.com \
--to=eomereadig@gmail.com \
--cc=dev@dpdk.org \
--cc=maryam.tahhan@intel.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).