27/03/2019 15:41, Stephen Hemminger: > On Wed, 27 Mar 2019 07:19:32 +0100 > Tom Barbette <barbe...@kth.se> wrote: > > > Some NICs allow to timestamp packets, but do not support the full > > PTP synchronization process. Hence, the value set in the mbuf > > timestamp field is only the raw value of an internal clock. > > > > To make sense of this value, one at least needs to be able to query > > the current hardware clock value. As with the TSC, from there > > a frequency can be derieved by querying multiple time the current value of > > the > > internal clock with some known delay between the queries (example > > provided in the API doc). > > > > This patch series adds support for MLX5. > > > > An example app is provided in the rxtx_callback application. > > It has been updated to display, on top of the software latency > > in cycles, the total latency since the packet was received in hardware. > > The API is used to compute a delta in the TX callback. The raw amount of > > ticks is converted to cycles using a variation of the technique describe > > above. > > > > Aside from offloading timestamping, which relieve the > > software from a few operations, this allows to get much more precision > > when studying the source of the latency in a system. > > Eg. in our 100G, CX5 setup the rxtx callback application shows > > SW latency is around 74 cycles (TSC is 3.2Ghz), but the latency > > including NIC processing, PCIe, and queuing is around 196 cycles. > > > > One may think at first this API is overlapping with > > te_eth_timesync_read_time. > > rte_eth_timesync_read_time is clearly identified as part of a set of > > functions > > to use PTP synchronization. > > The device raw clock is not "sync" in any way. More importantly, the > > returned > > value is not a timeval, but an amount of ticks. We could have a cast-based > > solution, but on top of being an ugly solution, some people seeing the > > timeval > > type of rte_eth_timesync_read_time could use it blindly. > > > > Change in v2: > > - Rebase on current master > > > > Tom Barbette (3): > > rte_ethdev: Add API function to read dev clock > > mlx5: Implement support for read_clock > > rxtx_callbacks: Add support for HW timestamp > > I like this approach but would like to see the same API supported > on multiple devices. > > The current timestamp API is a mess because not all devices behave the > same way. Trying to write an application that uses timestamping is therefore > very difficult.
So what do you suggest?
