On 30/07/2025 02:51, Jakub Kicinski wrote:
On Tue, 29 Jul 2025 19:07:59 +0100 Vadim Fedorenko wrote:
On 29/07/2025 18:31, Andrew Lunn wrote:
The only one bin will have negative value is the one to signal the end
of the list of the bins, which is not actually put into netlink message.
It actually better to change spec to have unsigned values, I believe.
Can any of these NICs send runt packets? Can any send packets without
an ethernet header and FCS?
Seems to me, the bin (0,0) is meaningless, so can could be considered
the end marker. You then have unsigned everywhere, keeping it KISS.
I had to revisit the 802.3df-2024, and it looks like you are right:
"FEC_codeword_error_bin_i, where i=1 to 15, are optional 32-bit
counters. While align_status is true, for each codeword received with
exactly i correctable 10-bit symbols"
That means bin (0,0) doesn't exist according to standard, so we can use
it as a marker even though some vendors provide this bin as part of
histogram.
IDK, 0,0 means all symbols were completely correct.
It may be useful for calculating bit error rate?
The standard doesn't have this bin, its value can be potentially
deducted from all packets counter.
A workaround for having the {-1, -1} sentinel could also be to skip
the first entry:
if (i && !ranges[i].low && !ranges[i].high)
break;
I was thinking of this way, the problem is that in the core we rely on
the driver to provide at least 2 bins and we cannot add any compile-time
checks because it's all dynamic.