DPDK usage discussions
 help / color / mirror / Atom feed
From: Stephen Hemminger <stephen@networkplumber.org>
To: "Tomáš Jánský" <tomas.jansky@flowmon.com>
Cc: users@dpdk.org
Subject: Re: [dpdk-users] Mellanox MLX5 - RX Missed Errors Counter Overflow
Date: Tue, 14 Jul 2020 07:40:36 -0700	[thread overview]
Message-ID: <20200714074036.231dc2c6@hermes.lan> (raw)
In-Reply-To: <CAPP7y6xF929pYLbpgt48j378QXQF3Q+hxY5-5TXuUACBu6nDXg@mail.gmail.com>

On Tue, 14 Jul 2020 10:35:25 +0200
Tomáš Jánský <tomas.jansky@flowmon.com> wrote:

> Hi,
> 
> I am using the Mellanox MLX5 driver and I noticed nonsense values in
> *rx_missed_errors* counter.
> 
> Configuration:
> 
>    - DPDK version 20.02
>    - CentOS Linux release 7.7.1908 (Core)
>    - Mellanox OFED version: MLNX_OFED_LINUX-4.7-3.2.9.0-rhel7.7-x86_64
> 
> 
> I have a function which periodically retrieves xstats counters.
> 
> char *field_names[7] = {"rx_packets_phy", "rx_discards_phy",
> "rx_missed_errors", "rx_errors", "rx_bytes_phy", "tx_packets_phy",
> "tx_bytes_phy"};
> uint64_t ids[7], values[7];
> int i;
> 
> for (i = 0; i < 7; i++) {
>     rte_eth_xstats_get_id_by_name(port_id, field_names[i], &ids[i]);
> }
> rte_eth_xstats_get_by_id(port_id, ids, values, 7);
> 
> It works perfectly fine until the value in *rx_missed_errors* counter
> reaches around 3721692877 (maximum observed value, but probably not the
> actual maximum value) which is 0xDDD486CD hex.
> After that, the next measurement reports the value 18446744073150886746
> which is obviously wrong.
> Then, after some time, the value starts again from zero.
> 
> The documentation says that the counter is supposed to be 64-byte
> unsigned integer: https://doc.dpdk.org/api/structrte__eth__xstat.html
> 
> Is anybody else experiencing this issue? It might not be related only to
> the MLX5 driver because we had a similar issue with Intel X710 cards.
> 
> Thanks.
> 
> Tomas

Xstats are often created by the driver from hardware registers.
Investigate which hardware register that counter is coming from and see
what the width of the register is.

You may have to use the 32 bit counter detection logic (like snmpd)
to workaround.

      reply	other threads:[~2020-07-14 14:58 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-14  8:35 Tomáš Jánský
2020-07-14 14:40 ` Stephen Hemminger [this message]

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=20200714074036.231dc2c6@hermes.lan \
    --to=stephen@networkplumber.org \
    --cc=tomas.jansky@flowmon.com \
    --cc=users@dpdk.org \
    /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).