On Thu, Oct 29, 2020 at 02:40:55PM +1100, Matthew P. Grosvenor wrote: > I think you’re missing the point here. You made two assertions: > The NIC MAC should either strip the CRC, or should drop a packet with a bad > CRC.
No, that is not what I meant. The job of the MAC is to check the CRC and drop frames which fail the check. This fundamental to the correct operation of Ethernet. > It may be that some NICs strip the CRC before sending a packet to > the host, but there’s no standard requiring it to do so (that I know > of?), and many NICs optionally allow users to turn this stripping > off. Where in 802.3 can I read about disabling the CRC or putting other things (like time stamps) in there? > It is not completely useless to forward the CRC to software. I gave > some examples of cases where software may want to see the CRC for > various reasons, for example, switches doing (completely utterly > ridiculously) silly things with CRCs, And why on Earth do I want to support that? > or software that is doing capture/analysis of raw frames. Okay, so that is a valid use case. If you would like to implement it, then the proper way is adding a configuration option, say "raw.fcs", that enables stripping the extra bytes. > Any correct software should be able to handle both cases (with and > without a CRC) and indeed all software that I’ve come across so far > that parses Ethernet frames directly does so (with the exception of > this project it would seem). Moreover, if I understand it correctly, > the argument made by Matt Sanders (for this patch) is that 1558 > standard does not require systems to rely on the length of a > frame/packet to determine if a TLV is present (as this project > does). Instead the standard provides a mechanism, which is the > messageLength value in the header, for figuring this out. It seems > that you don’t want to make use of this mechanism, but the > justification eludes me. The messageLength field is nice to have, but it is redundant for all of the implemented transports. The code carefully verifies the lengths of PDUs for each transport. This practice is called error checking. Thanks, Richard _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
