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. *** Having said that, I cannot resist offering an opinion... > A simple solution is timestamping all the packets and making the dma > flow uniform to all the packets - ptp and non-ptp regular packets, > where each packet's timestamp whether needed or not for the ptp4l > stack will be stored in the hardware fifo. IMHO this is only reasonable approach for modern MAC hardware. Just write the time stamp into the packet descriptor and be done with it. It is just eight bytes, after all. No two threads, no packet parsing or alternate paths. KISS. Also, precise time stamps are useful to other applications beyond PTP, and so making PTP frames into a special case is artificially limiting the usefulness of your HW. > It can lead to overflow due to slower turnaround from the driver or Nonsense. The driver must read the descriptor in any case, and it will only handle the time stamp if the option is enabled. > in the worst case slow down the link losing the throughput. again, you can have a descriptor bit that tells whether to copy the time stamp back or not. Just my 2 cents, *** Thanking you in anticipation, Regards, Chandra (c) : +60.175508142 (O): +60.4.636.6412 "Knowledge speaks, Wisdom listens" -----Original Message----- From: Richard Cochran [mailto:richardcoch...@gmail.com] Sent: Thursday, April 13, 2017 3:41 AM To: MSR, CHANDRASEKHAR <chandrasekhar....@intel.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 Chandra, Your question has nothing to do with linuxptp (user space stack) or even with the Linux kernel, and as such it is off topic for this list. Having said that, I cannot resist offering an opinion... > A simple solution is timestamping all the packets and making the dma > flow uniform to all the packets - ptp and non-ptp regular packets, > where each packet's timestamp whether needed or not for the ptp4l > stack will be stored in the hardware fifo. IMHO this is only reasonable approach for modern MAC hardware. Just write the time stamp into the packet descriptor and be done with it. It is just eight bytes, after all. No two threads, no packet parsing or alternate paths. KISS. Also, precise time stamps are useful to other applications beyond PTP, and so making PTP frames into a special case is artificially limiting the usefulness of your HW. > It can lead to overflow due to slower turnaround from the driver or Nonsense. The driver must read the descriptor in any case, and it will only handle the time stamp if the option is enabled. > in the worst case slow down the link losing the throughput. again, you can have a descriptor bit that tells whether to copy the time stamp back or not. Just my 2 cents, Richard ------------------------------------------------------------------------------ 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
