mbox series

[RFC,0/3] mlx5 to PCAP capture with hardware timestamps

Message ID 20200625190119.265739-1-vivien.didelot@gmail.com (mailing list archive)
Headers
Series mlx5 to PCAP capture with hardware timestamps |

Message

Vivien Didelot June 25, 2020, 7:01 p.m. UTC 
  This series allows to capture packets from a Mellanox ConnectX-5 interface
into a PCAP file with support for hardware timestamps. Since libibverbs
already provides timestamp conversion to nanoseconds for mlx5, the necessary
glue is added before writing the driver's timestamps into the PCAP headers.

Patrick Keroulas (2):
  net/mlx5: add timestamp-to-ns converter from libibverbs
  ethdev: add API to convert raw timestamps to nsec

Vivien Didelot (1):
  net/pcap: support hardware Tx timestamps

 doc/guides/rel_notes/release_20_08.rst   |  1 +
 drivers/common/mlx5/linux/mlx5_glue.c    | 16 +++++++++++++
 drivers/common/mlx5/linux/mlx5_glue.h    |  4 ++++
 drivers/net/mlx5/linux/mlx5_ethdev_os.c  | 30 ++++++++++++++++++++++++
 drivers/net/mlx5/linux/mlx5_os.c         |  1 +
 drivers/net/mlx5/mlx5.h                  |  1 +
 drivers/net/pcap/rte_eth_pcap.c          | 30 ++++++++++++++----------
 lib/librte_ethdev/rte_ethdev.c           | 12 ++++++++++
 lib/librte_ethdev/rte_ethdev.h           | 17 ++++++++++++++
 lib/librte_ethdev/rte_ethdev_core.h      |  5 ++++
 lib/librte_ethdev/rte_ethdev_version.map |  2 ++
 lib/librte_mbuf/rte_mbuf_core.h          |  3 ++-
 lib/librte_pdump/rte_pdump.c             | 14 ++++++++++-
 13 files changed, 121 insertions(+), 15 deletions(-)

Comments

Morten Brørup July 8, 2020, 2:34 p.m. UTC | #1 
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Vivien Didelot
> Sent: Thursday, June 25, 2020 9:01 PM
> 
> This series allows to capture packets from a Mellanox ConnectX-5
> interface
> into a PCAP file with support for hardware timestamps. Since libibverbs
> already provides timestamp conversion to nanoseconds for mlx5, the
> necessary
> glue is added before writing the driver's timestamps into the PCAP
> headers.

Which clock source is the nanosecond timestamps output from this function using? CLOCK_REALTIME, the NIC clock, the CPU clock, or something else?

If it is the NIC clock, I guess a simple scaling factor could be used instead, for performance reasons. The driver could expose the scaling factor (or for even better resolution: its clock frequency), e.g. through the capabilities API, so the application can cache it and convert to nanoseconds by multiplying a scaling factor and adding an offset. The application would have to handle clock drift between the NIC clock and CLOCK_REALTIME (or some other preferred reference clock source) anyway.