> -----Original Message----- > From: MSR, CHANDRASEKHAR [mailto:chandrasekhar....@intel.com] > Sent: Friday, April 14, 2017 7:48 AM > To: Richard Cochran <richardcoch...@gmail.com> > Cc: linuxptp-users@lists.sourceforge.net > Subject: Re: [Linuxptp-users] ptp4l stack integration via linux OS with least > burden on the Firmware and major PTP offload to the hardware > > > > Hi Richard, > > Thank you a lot for responding to my question though you could have easily > shut > me off, given the 'off topic' nature of the question. I need some basic > clarificaions > from your response. > > You say " IMHO this is only reasonable approach for modern MAC hardware" & " > Nonsense. The driver must read the descriptor in any case, and it will only > handle > the time stamp if the option is enabled.". My confusion here is: You seem to > support timestamping all the packets but driver will handle the timestamp if > the > option is enabled. If the driver knows whether to handle the timestamp or not > through the flags in the DMA descriptor, then the underlying MAC hardware > does take advantage of it so that the timestamping is carried out for the > packets > (any - ptp or nonptp), which has the option enabled. As you might know, the > hardware usually stores the timestamps in a FIFO, which will be read out on > polling the status or a suitable interrupt. With the distinction between > packet > needing timestamps (ptp or nonptp) and packet with no need of timestamps, the > number of timestamps that can be pushed by the MAC hardware into the FIFO is > limited, saving considerable silicon - especially the case with ASICs, where > the > depths are predetermined unlike FPGAs. Further, the driver has to wait for > some > more time after the packet is transmitted, to complete the dma ack with the > timestamp (to be collected from the FIFO and put it back in the descriptor). > However, for the packets not needing timestamps, the driver can give the ack > quickly fetching the next set of descriptors. Thus, timestamping as needed by > the > MAC hardware is really the need of the hour than timestamping every packet. > Please share your opinion. > > You say " It is just eight bytes, after all". Actually, it is not a PTM > (PCIe) timestamp. > In 1588v2, the timestamp is 10 bytes/80b. Further, our hardware provides even > fractional nanoseconds of 16b (giving out 2^-16ns resolution). Understandably, > the proprietary stacks have the capability to handle the complete 12B of > timestamps than the public-domain stacks. Just FYI. Do share your opinion. > > Thank you again for sharing your expertise with us - it is very helpful.
It's certainly easier in software if all packets have a timestamp. Additionally, I imagine it's easier in hardware if there is no special casing since you wouldn't need any circuitry to build out how to decide which frames get timestamped and which do not. This should be simpler. It seems to be that yes you do pay the 8 or 16 bytes per frame if you have timestamps always, but that cost is smaller than the huge complexity required to have the hardware pre-determine which packet gets timestamped if it only supports a subset of "all packets" while also forcing software to now be aware of what the hardware will or will not timestamp. It may be that specific hardware has limitations on how it timestamps for other reasons, but obviously we can't comment on how the hardware is designed, since we didn't design it. I dont think a FIFO for pushing timestamps by the MAC is necessarily the only way to do it, and certainly lots of hardware already suports "timestamp all packets" already today. This is a valuable feature to software already, so if you wanted to support it then you don't need support for any subset of all packets. Thanks, Jake ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
