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