21/05/2020 21:57, PATRICK KEROULAS: > > > 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 :) > > > 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.
