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

2019-03-27 Thread Tom Barbette
On 2019-03-27 15:54, Wiles, Keith wrote: I know the API rte_eht_read_clock() is attempting to read the NIC for this timestamp, but if the PMD does not support this request can we just default to the rte_rdtsc() as a return value? I would not advise that, because the goal of the function is to h

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

2019-03-27 Thread Wiles, Keith
> On Mar 27, 2019, at 9:41 AM, Stephen Hemminger > wrote: > > On Wed, 27 Mar 2019 07:19:32 +0100 > 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 v

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

2019-03-27 Thread Thomas Monjalon
27/03/2019 15:41, Stephen Hemminger: > On Wed, 27 Mar 2019 07:19:32 +0100 > 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.

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

2019-03-27 Thread Stephen Hemminger
On Wed, 27 Mar 2019 07:19:32 +0100 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 n

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

2019-03-26 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. As with