Thread (14 messages) 14 messages, 5 authors, 2020-06-05

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

From: Slava Ovsiienko <hidden>
Date: 2020-06-05 16:30:12

-----Original Message-----
From: PATRICK KEROULAS <redacted>
Sent: Friday, June 5, 2020 3:10
To: Slava Ovsiienko <redacted>
Cc: dev@dpdk.org; Vivien Didelot <redacted>; Shahaf
Shuler [off-list ref]; Raslan Darawsheh
[off-list ref]; Matan Azrad [off-list ref]
Subject: Re: [dpdk-dev] mlx5 & pdump: convert HW timestamps to
nanoseconds

On Wed, Jun 3, 2020 at 3:48 AM Slava Ovsiienko
[off-list ref] wrote:
quoted
quoted
From: PATRICK KEROULAS <redacted>
* rdma-code, libibverbs-dev: 28.0
* NIC Part Number:      MCX516A-CDA_Ax
* ConnectX-5 Ex EN
* FW: 16.25.1020
It looks like outdated firmware, please:
- update the firmware - at least 16.27.2008 is GA. I would recommend
to install OFED - it updates the FW
- make sure the UCTX_EN option in FW configuration is set to "true"
Hello Slava,

I managed to query device_frequency_khz by simply setting UCTX_EN=1,
convert the mbuf->timestamp to nsec and write a pcap. However, the
accuracy is quite disappointing, compared to libvma or even SW TS.

The freq value looks constant (=78125kHz). Correct me if I'm wrong, a ptp
client is supposed to continuously adjust some kind of VCO on the NIC. And
AFAIK, it is not the case for ConnectX-5, no clock adjustment, just some free running counter.
ConnectX6DX  will provide an option of adjustable nanosecond UTC in timestamps.
even setting a crazy value through /dev/ptp interface manually doesn't affect
device_frequency_khz. Please could you clarify?

This leads me back to mlx5dv_clock_info->nsec. If this is a valid method, I
think the only missing piece is to access it from the secondary process, which
implies to share ibv_context.

Best Regards,

PK
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help