Traffic outage

[QQ2017]

When using sar to monitor network traffic, an issue involving intermittent periods of zero reported traffic was observed. An analysis using Codex revealed that this anomaly stems from the driver's statistics-gathering path itself, rather than indicating an actual "traffic outage."

1. The logic for updating netdev statistics in this specific driver version contains a significant flaw. Tools such as sar -n DEV 1 ultimately invoke the ndo_get_stats64 handler, which maps to ice_get_stats64(); see /ethernet-linux-ice-main/ethernet-linux-ice-main/src/ice_main.c:9752. The intended design here was to first call ice_update_vsi_ring_stats(vsi) during the read operation—thereby calculating the current ring statistics—and then return the resulting values.

2. However, the implementation of ice_update_vsi_ring_stats() is defective: it accumulates the statistics into a temporary vsi_stats buffer but subsequently calls kfree(vsi_stats) directly without writing the accumulated TX/RX packet and byte counts back to the persistent vsi->net_stats structure. See lines /ethernet-linux-ice-main/ethernet-linux-ice-main/src/ice_main.c:9462 through /ethernet-linux-ice-main/ethernet-linux-ice-main/src/ice_main.c:9515. This implies that the values ​​read by ice_get_stats64() are frequently not the "ring counts freshly aggregated during the current request," but rather stale cached data.

3. This stale cached data is primarily derived from periodic updates performed by the watchdog mechanism; specifically, the ice_watchdog_subtask() function updates these statistics once every pf->serv_tmr_period (defined as HZ) intervals. See /ethernet-linux-ice-main/ethernet-linux-ice-main/src/ice_main.c:2245 and /ethernet-linux-ice-main/ethernet-linux-ice-main/src/ice_main.c:5583. If a sampling tool happens to perform a read precisely between two such watchdog updates, it will observe that the "current value remains unchanged." When converted into a traffic rate, this translates to a value of zero. Conversely, during the next sampling cycle—when the tool reads the value that now includes all the counts accumulated since the previous update—it captures a significantly larger figure. This results in the observed alternating pattern of "0 / very large value / 0 / very large value." The pattern shown in your screenshot aligns very closely with this scenario.

4. There is also a secondary implementation issue: ice_fetch_u64_stats_per_ring() passes the struct ice_q_stats by value; consequently, u64_stats_fetch_begin/retry do not actually provide protection for the reading of the raw ring counters. (See:
   ethernet-linux-ice-main/ethernet-linux-ice-main/src/ice_main.c:9392). This is more of a consistency flaw—it typically won't reliably cause the "reset-to-zero-every-other-second" behavior—but it does indicate that the quality of the current statistics-handling code is indeed problematic.

Conclusion: What you are observing appears to be an "anomaly/lag in driver statistics updates," rather than the actual business traffic intermittently dropping to zero. The primary cause is highly likely that ice_update_vsi_ring_stats() fails to write the aggregated ring statistics back to vsi->net_stats; as a result, sar can only intermittently read the stale values ​​that were last refreshed by the watchdog timer.

If you intend to fix this, I recommend prioritizing the following two points:

1. After the aggregation process within ice_update_vsi_ring_stats() is complete, write the values ​​from vsi_stats->{tx_packets, tx_bytes, rx_packets, rx_bytes} back to vsi->net_stats.
2. Modify ice_fetch_u64_stats_per_ring() to accept a pointer—struct ice_q_stats *stats—and perform the dereferenced reads directly within the u64_stats_fetch_begin/retry loop.