On 30/07/2025 15:59, Andrew Lunn wrote: > On Wed, Jul 30, 2025 at 08:39:25AM +0300, Gal Pressman wrote: >> On 30/07/2025 4: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? >> >> Exactly. mlx5 will use (0, 0) for sure. > > Sorry, i did not spend time to read the standard and issued this was > related to frame length somehow, like the RMON statistics which have > bins for packet length counts.
I'm not sure I'm using the right terminology, but the ranges are # of symbols that had FEC errors. So (0, 0) means zero symbol errors.
