[dpdk-dev] [PATCH v3 4/7] ethdev: remove HW specific stats in stats structs

[Kyle Larose]

On Fri, Jun 26, 2015 at 8:59 AM, Maryam Tahhan <maryam.tahhan at 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 at 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