Minor snabb top UI improvements

[dpino]

Several UI improvements in snabb top:

• Mbytes should be Mbits, as bits are more generally used networking stats.
• RX Packet drops should be accumulative, or at least there's should an accumulative rx packet drop counter.

[dpino]

About show values in bits instead of bytes, it mostly refers to values such as rx/tx bytes per queue. Snabb top basically what it does is to print out the counters it finds for a shared memory container. I think this change should be at counter level. Maybe we can have both values.

Related to https://github.com/Igalia/snabb/pull/1148

[takikawa]

Is there a good way to reproduce the issue with rxdrops? I wonder if the issue is due to setting rxcounter. The function that keeps track of drops is this one:

function Intel82599:rxdrop   () return self.r.QPRDC[0]() end 

The QPRDC register is the per-queue packet drop register array, which is indexed by queue counter number. Queue counter 0 tracks all queues when no app sets rxcounter. When apps set rxcounter, queue 0 tracks all queues except the ones that set rxcounter. So the global drops isn't very global when separate counters are used.

[dpino]

Deterministically not, but the best approach to reproduce it is to run the lwAFTR on a different NUMA node and push traffic at full-speed. That will likely generated packet-drops.

$ sudo ./snabb lwaftr run --cpu 2 --name lwaftr --conf lwaftr.conf --on-a-stick 82:00.0

Sends traffic starting from 10Gb during 10 seconds.

$ sudo ./snabb loadtest transient --program ramp_down -D 10 -b 10e9 -s 0.2e9 \
   from-inet-and-b4-0550.pcap "NIC 0" "NIC 0" 02:00.0

[takikawa]

I looked into this a bit, and maybe I am missing something. Is it possible for snabb top to show cumulative counters in general? The design, as far as I understand, is to only show historical rates rather than a cumulative value for counters right? The rxdrops counter for the actual NIC driver is cumulative as far as I understand.

Separately, I think rxdrops might be counting a bit strangely due to using QPRDC. There's a separate set of counters RXMPC that I think works no matter how the queue counters are assigned, but I'm not totally sure.

[dpino]

You're right. The way snabb top works is by showing current stats values. However, as stats values are collected they're also accumulated in an additional aggregated counter. These aggregated counters are used, as far as I know, for time-travel stats only. To switch to time-travel stats, snabb top must be paused and then is possible to move in time by strides of 1 second of 1 minute.

That said, I gave that a try and when moving back in time all stats counters were zeroed, but this is another issue. I think we should not change the behavior of any specific counter to make it accumulative.

About whether to use QPRDC or RXMPC, I honestly do not know. I think we would need to collect more feedback from real world uses to make up our minds.

[dpino]

We agree accumulated statistics are handled by time-travel stats, so we won't change the behavior of any field in the standard interface and tree views. In the end, this issue only handles the case of changing rx/tx bytes reporting to bits.

I created a new issue for the case of time-travel stats showing zeroed values https://github.com/Igalia/snabb/issues/1161