Hi Patrick, On Mon, Jul 06, 2020 at 02:36:30PM -0400, PATRICK KEROULAS wrote: > On Fri, Jun 26, 2020 at 2:48 AM Olivier Matz <olivier.m...@6wind.com> wrote: > > I don't get why you expect that timestamp to be in nanoseconds. > > The conversion is done in librte_pdump (in the previous patch), > > but it won't work if the library is not used, right? > > > > You're right Olivier. I took advantage of the definition of mbuf->timestamp > as being "not normalized". The proposed conversion needs NIC clock info > which can't be accessed from the secondary process. Do you have a better > suggestion? Should I set a user flag in mbuf for nanoseconds? > > > Out of curiosity, can you explain your motivation for using the hardware > > timestamp? Is it faster? More accurate? (knowing it timestamps the Rx > > operation, not the Tx) > > Accuracy is our requirement in the broadcast industry (and probably > in finance as well) where core systems are very time sensitive. Our > application uses the NIC mostly as a receiver for UDP stream monitoring > in order to measure the network propagation delay and jitter. Using SW Rx > timestamps completely breaks this requirement.
OK, your main motivation for hardware timestamping is the accuracy, and your application logs the Rx timestamp into the pcap when using the PMD. For the pmd pcap part, the dynamic Tx timestamp flag that is being introduced by Slava [1] may fit your needs: ie. when the flag is set, it uses the provided timestamp which should be in nanosecs. [1] https://patchwork.dpdk.org/patch/73427/ For the conversion from hardware Rx timestamp into Tx timestamp (in nanosec), could it be done by your application? Early in the Rx path, if a packet has a Rx timestamp flag, do the conversion to nsecs, and set the timestamp field and the Tx timestamp flag. Regards, Olivier
