21/05/2020 21:57, PATRICK KEROULAS:

quoted

quoted

I'm trying to build an accurate capture device based on Mellanox
Connect-X5 with following requirements:
- capture every incoming packets with hardware timestamps
- output: pcap with timestamps in nanoseconds
My problem is that the packets forwarded to `dpdk-pdump` carry raw
timestamps from NIC clock.

Please could you describe how you use dpdk-pdump?
Is it using the mlx5 PMD or pcap PMD?

We're actually using both:
# Rx, receive from NIC
CONFIG_RTE_LIBRTE_MLX5_PMD=y
# Tx, output to pcap file
CONFIG_RTE_LIBRTE_PMD_PCAP=y

$ sudo ./build/app/testpmd -w 0000:01:00.0 -w 0000:01:00.1 -n4 --
--enable-rx-timestamp
$ dpdk-pdump -- --pdump 'port=0,queue=*,rx-dev=capture.pcap'

OK thanks

We've sent this placeholder with the intention to start the discussion.
https://github.com/DPDK/dpdk/commit/bd371e1ba5bfc5b7092d712a01bbc28799fd58bc.patch
https://github.com/DPDK/dpdk/commit/e6f5c731c4ab27ab80b229af98c9b3d257e13843.patch

We don't use GitHub. It is just a mirror.
Thanks for having started the discussion in the mailing list,
it is more efficient :)

quoted

quoted

mlx5 part of libibverbs includes a ts-to-ns converter which takes the
instantaneous clock info. It's unused in dpdk so far. I've tested it in the
device/port init routine and the result looks reliable. Since this approach
looks very simple, compared to the time sync mechanism, I'm trying to
integrate.

The conversion should occur in the primary process (testpmd) I suppose.
1) The needed clock info derives from ethernet device. Is it possible to
   access that struct from a rx callback?
2) how to attach the nanosecond to mbuf so that `pdump` catches it?
   (workaround: copy `mbuf->udata64` in forwarded packets.)
3) any other idea?

The timestamp is carried in mbuf.
Then the conversion must be done by the ethdev caller (application or
any other upper layer).

What if the converter function needs a clock_info?
https://github.com/linux-rdma/rdma-core/blob/7af01c79e00555207dee6132d72e7bfc1bb5485e/providers/mlx5/mlx5dv.h#L1201
I'm affraid this info may change by the time the converter is called
by upper layer.

Indeed, the clock in the device is not an atomic one :)
We need to adjust the time conversion continuously.
I am not an expert of time synchronization, so I add more people Cc
who could help for having a precise timestamp.