On Tue, Nov 3, 2015 at 5:05 PM, Stephen Hemminger <stephen at networkplumber.org> wrote:
> > IMHO this is a bug. Other drivers don't include the CRC, and the Intel driver > only includes CRC in count for one direction, and depends on value of > stripping flag. > > I sent a patch to fix this because our customers didn't like it when Rx != Tx > bytes > but there was somebody who liked including CRC. > > It really is a Cisco versus the world thing. Juniper/Linux/BSD all do NOT > include > CRC in counters and therefore that is what should be done. > Another option is to make whether or not the NIC counts the CRC in its byte counters configurable, when supported, and also retrievable. I'm concerned about the case where a NIC doesn't even have an option to control whether or not it counts the CRC, and it *does* count it. In that case, any software running on that NIC will behave inconsistently. If it knew that it counted the CRC, it could adjust for it. If we put the option in now, then software written now could deal with it gracefully. Combined with the ability to configure it, this may satisfy use cases where knowing the full frame size is useful (for example when looking at bit rates with small packets. 4 bytes is a big difference for a 64-byte frame). Of course, this may not be a problem worth solving. But, I figure it's worth considering.
