[dpdk-dev] mlx5 & pdump: convert HW timestamps to nanoseconds

Slava Ovsiienko viacheslavo at mellanox.com
Sun May 31 21:47:20 CEST 2020


Hi, Patrick

Please, see below.

>From: PATRICK KEROULAS <patrick.keroulas at radio-canada.ca> 
>Sent: Friday, May 29, 2020 23:56
>To: Slava Ovsiienko <viacheslavo at mellanox.com>
>Cc: dev at dpdk.org; Vivien Didelot <vivien.didelot at gmail.com>; Shahaf Shuler <shahafs at mellanox.com>; Raslan Darawsheh <rasland at mellanox.com>; Matan Azrad ><matan at mellanox.com>
>Subject: Re: [dpdk-dev] mlx5 & pdump: convert HW timestamps to nanoseconds
>
>
>On Tue, May 26, 2020 at 12:00 PM Slava Ovsiienko <mailto:viacheslavo at mellanox.com> wrote:
>>> Hi, Patrick
>>
>> ConnectX HW timestamp is the captured value of internal 64-bit counter running at the frequency,
>> reported in the device_frequency_khz field of struct mlx5_ifc_cmd_hca_cap_bits{}.
>> This structure is queried in mlx5_devx_cmd_query_hca_attr() routine.
>> So, with known frequency it is possible to recalculate timestamp ticks to desired units.
>
>Hello Slava,
>
>Assuming that the NIC clock is already synced thanks to a PTP client,
>does the bit counter give an absolute time value (0 => 1 January 1970
>00:00:00)? Or do I need to calculate a time duration from the process
>start time?
[SO]
I would not make any assumption about internal clock phase and its relation to time (UTC?).
I suppose the getting the initial value of clock counter and calculating the actual time at the app start is valid approach.

>I just want to validate the path from mlx5 eth dev(Rx) to eth pcap (Tx) :
>- query the oscillator frequency at the mlx5_eth_dev init step
>  (mlx5_devx_cmd_query_hca_attr())
>- store the freq with other hca_attr, carried by dev config which should
>  be shared with the secondary process
>- in eth_pcap_tx_dumper(), retrieve the freq from the dev given by
>  mbuf->port
>- convert all the incoming mbuf->timestamp using this freq whose
>  variation should be negligible over the capture duration
>
Should work OK, as for me.

>Last question: what is your opinion about this other method?
>https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Flinux-rdma%2Frdma-core%2Fblob%2F7af01c79e00555207dee6132d72e7bfc1bb5485e%>2Fproviders%2Fmlx5%2Fmlx5dv.h%23L1201&data=02%7C01%7Cviacheslavo%40mellanox.com%7C81833b88026b4aa93ecb08d80412b902%>7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C637263825741568283&sdata=dNr63ujwKDcWTCAAWO7und3B50kcmEFYxu01y2hoy%2Bw%3D&reserved=0
>
>Thanks a lot!
This code checks the counter periodically to track the counter wraparound and provides the older timestamp conversion (got before clock base update).
 If your have the stream of pkts with monotonically increasing timestamp you could track this counter wrap in your code (save the last ts conversion result and counter value).

With best regards, Slava



More information about the dev mailing list