Hi Richard, 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. It is completely useless for a NIC to forward the CRC to the host. I am saying that I disagree with you on both of those assertions. 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. 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, or software that is doing capture/analysis of raw frames. These may not be the only cases, but they are cases nevertheless, and both of these cases are situations where the user may also want high quality time synchronisation at the same time as doing that work. 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.
> On 29 Oct 2020, at 04:22, Richard Cochran <richardcoch...@gmail.com> wrote: > > On Wed, Oct 28, 2020 at 06:27:42AM +1100, mgrosve...@gmail.com wrote: > >> Furthermore, some switches (Eg Arista and and Cisco) use the CRC to convey >> timestamps in packets. > > If that is true, then their device drivers should strip off the time > stamp and provide it via the SO_TIMESTAMPING mechanism. This make no sense at all. I think you’re confusing what the switch is doing to what the NIC is doing. The switch doesn’t have a device driver in the path here. The NIC device driver is ignorant of what the switch is doing. The only way to achieve what you want here is to make every switch vendor make patches to every NIC vendor’s drivers to parse every ethernet packet and look for magic timestamps and then use SO-TIMESTAMPING to push those values through. > >> It would be absolutely necessary to be able to see the “CRC” for this this >> use case, on the same interface that PTP traffic traverses, even if PTP >> traffic itself is unaffected. > > No, that is not correct. No user software ever expects to see time > stamps bolted on randomly. There is a proper time stamping API for > that. As above. - M
_______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
