DPDK patches and discussions
 help / color / mirror / Atom feed
From: Slava Ovsiienko <viacheslavo@mellanox.com>
To: PATRICK KEROULAS <patrick.keroulas@radio-canada.ca>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
	Vivien Didelot <vivien.didelot@gmail.com>,
	 Shahaf Shuler <shahafs@mellanox.com>,
	Raslan Darawsheh <rasland@mellanox.com>,
	Matan Azrad <matan@mellanox.com>
Subject: Re: [dpdk-dev] mlx5 & pdump: convert HW timestamps to nanoseconds
Date: Sun, 31 May 2020 19:47:20 +0000	[thread overview]
Message-ID: <AM4PR05MB326542FB8D5B49EEB7F23AA8D28D0@AM4PR05MB3265.eurprd05.prod.outlook.com> (raw)
In-Reply-To: <CALEF-=D-qtmO-urE4WB3xJCPO1d086a4T=0isk3xhd=90RpJcQ@mail.gmail.com>

Hi, Patrick

Please, see below.

>From: PATRICK KEROULAS <patrick.keroulas@radio-canada.ca> 
>Sent: Friday, May 29, 2020 23:56
>To: Slava Ovsiienko <viacheslavo@mellanox.com>
>Cc: dev@dpdk.org; Vivien Didelot <vivien.didelot@gmail.com>; Shahaf Shuler <shahafs@mellanox.com>; Raslan Darawsheh <rasland@mellanox.com>; Matan Azrad ><matan@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@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	other threads:[~2020-05-31 19:47 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-19 18:20 PATRICK KEROULAS
2020-05-21 15:33 ` Thomas Monjalon
2020-05-21 19:57   ` PATRICK KEROULAS
2020-05-21 20:09     ` Thomas Monjalon
2020-05-22 18:43       ` PATRICK KEROULAS
2020-05-26  7:44         ` Tom Barbette
2020-05-29 20:46           ` N. Benes
2020-05-26 16:00         ` Slava Ovsiienko
2020-05-29 20:56           ` PATRICK KEROULAS
2020-05-31 19:47             ` Slava Ovsiienko [this message]
2020-06-02 19:18           ` PATRICK KEROULAS
2020-06-03  7:48             ` Slava Ovsiienko
2020-06-05  0:09               ` PATRICK KEROULAS
2020-06-05 16:30                 ` Slava Ovsiienko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=AM4PR05MB326542FB8D5B49EEB7F23AA8D28D0@AM4PR05MB3265.eurprd05.prod.outlook.com \
    --to=viacheslavo@mellanox.com \
    --cc=dev@dpdk.org \
    --cc=matan@mellanox.com \
    --cc=patrick.keroulas@radio-canada.ca \
    --cc=rasland@mellanox.com \
    --cc=shahafs@mellanox.com \
    --cc=vivien.didelot@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).