[dpdk-dev] [Bug 641] bnxt: rte_eth_stats_get() returning zeros between valid counts

[bugzilla at dpdk.org]

https://bugs.dpdk.org/show_bug.cgi?id=641

            Bug ID: 641
           Summary: bnxt: rte_eth_stats_get() returning zeros between
                    valid counts
           Product: DPDK
           Version: 20.11
          Hardware: x86
                OS: All
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: ethdev
          Assignee: dev at dpdk.org
          Reporter: brian90013 at gmail.com
  Target Milestone: ---

Created attachment 145
  --> https://bugs.dpdk.org/attachment.cgi?id=145&action=edit
testpmd log showing issue

Hello,

I am testing with DPDK-20.11 and a Broadcom P2100G NIC. I observed this problem
on FreeBSD-12.2 and Ubuntu 20. My application occasionally reports invalid
packet and byte counts. These statistics are obtained from the
rte_eth_stats_get() function and my code is checking the return value.

When I added some debugging, I observed that occasionally the ipackets and
ibytes fields would be set to zero even though the function call returned zero
(success). The calls before and after would have increasing values so it is
clear the internal registers weren't reset, just invalid values on this one
call. I have also seen this same behavior for the opackets and obytes fields.

The attached testpmd run shows the problem. I show several seconds of stats,
then snip to several seconds before the problem occurred. Port 0 showed:

  RX-packets: 435792933  RX-missed: 0          RX-bytes:  27890747712

the next second it reported:

  RX-packets: 0          RX-missed: 0          RX-bytes:  0

and the following:

  RX-packets: 450562244  RX-missed: 0          RX-bytes:  28835983616

The test was running at 7.3Mpps while the difference between the first and last
stats output is 14.7Mpps (7.3*2) for a duration of 2s. So I believe the
hardware is properly incrementing the counters. It seems like the returned
values aren't being set properly under certain conditions. I have reviewed the
code but was unable to determine how this could happen.

-- 
You are receiving this mail because:
You are the assignee for the bug.