rte_eth_timesync_enable returns 1

["Davis, Tim" <Tim.Davis@analog.com>]

[-- Attachment #1: Type: text/plain, Size: 1997 bytes --]

Hi everyone,

I have been recently trying to get hardware transmit timestamping working and am having some issues. I have seen that 'rte_eth_timesync_enable' is returning 1 which does not appear to be a documented return value (https://doc.dpdk.org/api-22.11/rte__ethdev_8h.html#a5f45aabbfbb08ef986caddc70c48df4c). I assume because of this I subsequently cannot use 'rte_eth_timesync_read_tx_timestamp' as an error occurs.

This is a simple breakdown of API calls:

rte_eal_init()
rte_eth_dev_count_avail()
rte_eth_dev_is_valid_port()
rte_eth_dev_info_get()
rte_eth_dev_adjust_nb_rx_tx_desc()
rte_eth_dev_configure(port_id, 1 /* rxrings */, 1 /* txrings */, &port_conf)
rte_eth_rx_queue_setup()
rte_eth_tx_queue_setup()
rte_eth_dev_start()
rte_eth_timesync_enable() - returns 1
rte_eth_macaddr_get()
rte_eth_promiscuous_enable()
rte_eth_link_get()
...
rte_eth_tx_burst()
rte_eth_timesync_read_tx_timestamp() - timespec = 0

offloads:

portConf.txmode.offloads |= RTE_ETH_TX_OFFLOAD_MBUF_FAST_FREE;
portConf.txmode.offloads |= RTE_ETH_TX_OFFLOAD_MULTI_SEGS;

portConf.rxmode.offloads |= RTE_ETH_RX_OFFLOAD_TIMESTAMP;


Without rte_eth_timesync_enable and rte_eth_timesync_read_tx_timestamp, the tx burst works as expected. If I ignore the return of rte_eth_timesync_enable and try to read the tx timestamp and the timespec is always 0.

Other info:

  *   HW: Connect-6 Dx
  *   Mlxconfig: REAL_TIME_CLOCK_ENABLE=1
  *   Sys info: RHEL 4.18.0-477.27.1.el8_8.x86_64
  *   DPDK API version 22.11.3

sudo ethtool -T
Time stamping parameters for ens1f0np0:
Capabilities:
        hardware-transmit
        hardware-receive
        hardware-raw-clock
PTP Hardware Clock: 1
Hardware Transmit Timestamp Modes:
        off
        on
Hardware Receive Filter Modes:
        none
        all

driver: mlx5_core
version: 23.07-0.5.1
firmware-version: 22.36.1010 (DEL0000000027)

Any help or guidance would be much appreciated.

Kind regards,
Tim


[-- Attachment #2: Type: text/html, Size: 8757 bytes --]