[DPDK/ethdev Bug 1947] bnxt: rte_eth_stats_get returns invalid counter values on BCM57608

[DPDK/ethdev Bug 1947] bnxt: rte_eth_stats_get returns invalid counter values on BCM57608

[bugzilla]

http://bugs.dpdk.org/show_bug.cgi?id=1947

            Bug ID: 1947
           Summary: bnxt: rte_eth_stats_get returns invalid counter values
                    on BCM57608
           Product: DPDK
           Version: 26.03
          Hardware: All
                OS: All
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: ethdev
          Assignee: dev@dpdk.org
          Reporter: oleksandrn@interfacemasters.com
  Target Milestone: ---

On BCM57608 rte_eth_stats_get occasionally returns a single statistic counter
with a value that doesn't make sense given the actual traffic sent. Only one
counter is bad per call; I have never seen two simultaneously, which maybe
suggests some sort of timing issue, and I don't think I even saw like 2 ports
of 6 have bad values, always one port one counter. (but maybe I need to do more
runs to see this, so maybe it doesn't mean anything)

  Observed 2 cases:

  1. A counter returns an exact power of 2 that is far beyond what the traffic
could produce in a short timeframe. For example, after 60 seconds of 6×100 Gbps
   traffic, we observe ierrors = 70368744177664 = 2^46 or 140737488355328 =
2^47 on single port.   
  2. ipackets is much larger than ibytes, which doesn't make sense, and should
be impossible.

  Example for case 1:
  ipackets   1423589410
  opackets   1423588386
  ibytes     1452060153720
  obytes     1469240022904
  imissed    229789201
  ierrors    70368744177664 <<<<< 2^46
  oerrors    0
  rx_nombuf  0

  Additionally, rte_eth_stats_reset / rte_eth_xstats_reset do not prevent
recurrence. 
  There is also a suspected issue with stats reset itself: running a second
60-second traffic burst after reset shows more packets reported by the NIC than
the traffic generator actually sent, suggesting the hardware counters are not
actually cleared, but I haven't investigated this enough to give more details.


 Rough reproduction steps (we did this testing with our application, but
haven't seen anything similar for other NICs we use, so it shouldn't matter
much):

  1. Initialize port with BCM57608 NIC (we have 10rx queues per port)
  2. Optionally call rte_eth_stats_reset after port init
  3. Send 6×100 Gbps traffic for 60 seconds (1024bytes per packet in this case,
but I don't think it should matter)
  4. Call rte_eth_stats_get -> observe inconsistent values sometimes

Seems to be the same with 25.11 and 26.03


  NIC :
  Part Number                         : BCM957608-P2100GQF20
  Chip Number                         : BCM57608
  Chip Name                           : THOR2
  Firmware Version                    : 236.1.153.0
  RoCE Firmware Version               : 236.1.153.0
  HWRM Interface Spec                 : 1.10.3
  Active Package Version              : 236.1.155.0
  Package Version on NVM              : 236.1.155.0
  Active NVM config version           : 236.0.2

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