Hi, Patrick

Please, see below.

>From: PATRICK KEROULAS <patrick.kerou...@radio-canada.ca> 
>Sent: Friday, May 29, 2020 23:56
>To: Slava Ovsiienko <viachesl...@mellanox.com>
>Cc: dev@dpdk.org; Vivien Didelot <vivien.dide...@gmail.com>; Shahaf Shuler 
><shah...@mellanox.com>; Raslan Darawsheh <rasl...@mellanox.com>; Matan Azrad 
>><ma...@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:viachesl...@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

Reply via email to