Re: [dpdk-dev] [PATCH v4 0/3] Add rte_eth_read_clock API

2019-05-31 Thread Ferruh Yigit
On 5/2/2019 1:11 PM, Tom Barbette wrote: > Some NICs allow to timestamp packets, but do not support the full > PTP synchronization process. Hence, the value set in the mbuf > timestamp field is only the raw value of an internal clock. > > To make sense of this value, one at least needs to be able

Re: [dpdk-dev] [PATCH v4 0/3] Add rte_eth_read_clock API

2019-05-08 Thread Tom Barbette
Maybe a (last) motivation point. We just did a 100G link traffic capture with time-stamping of all packets in HW using a Mellanox CX5. SW time-stamping fails to reveal queueing delays, and as multi-queue is needed for writing 100G traffic to multiple NVMe drives, does not allow to recover the

[dpdk-dev] [PATCH v4 0/3] Add rte_eth_read_clock API

2019-05-02 Thread Tom Barbette
Some NICs allow to timestamp packets, but do not support the full PTP synchronization process. Hence, the value set in the mbuf timestamp field is only the raw value of an internal clock. To make sense of this value, one at least needs to be able to query the current hardware clock value. This pat