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 > > doc/guides/nics/features.rst | 1 + > doc/guides/sample_app_ug/rxtx_callbacks.rst | 9 ++- > drivers/net/mlx5/mlx5.c | 1 + > drivers/net/mlx5/mlx5.h | 1 + > drivers/net/mlx5/mlx5_ethdev.c | 29 +++++++ > drivers/net/mlx5/mlx5_glue.c | 8 ++ > drivers/net/mlx5/mlx5_glue.h | 2 + > examples/rxtx_callbacks/Makefile | 2 + > examples/rxtx_callbacks/main.c | 86 ++++++++++++++++++++- > examples/rxtx_callbacks/meson.build | 1 + > lib/librte_ethdev/rte_ethdev.c | 13 ++++ > lib/librte_ethdev/rte_ethdev.h | 44 +++++++++++ > lib/librte_ethdev/rte_ethdev_core.h | 6 ++ > lib/librte_ethdev/rte_ethdev_version.map | 1 + > lib/librte_mbuf/rte_mbuf.h | 2 + > 15 files changed, 201 insertions(+), 5 deletions(-) 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.