> On Mar 27, 2019, at 9:41 AM, Stephen Hemminger <step...@networkplumber.org>
> wrote:
>
> 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.
Another question is this an optional API for a PMD? I assume it is.
I know the API rte_eht_read_clock() is attempting to read the NIC for this
timestamp, but if the PMD does not support this request can we just default to
the rte_rdtsc() as a return value?
Regards,
Keith
