Hi Zyta,
This was my initial proposal, but after discussion with Shahaf Shuler we
thought this was too far from the original intent of the function.
rte_eth_timesync_read_time is clearly identified as part of a set of function
to use PTP synchronization.
This clock is not "sync" in any way. Mor
From: Zyta Szpak
I'd ask few questions: how is this new rte_ethdev_read_clock different from
existing rte_eth_timesync_read_time ?
Is it that this new function does not convert the clock raw value into
timespec? Would it be too much overhead to use the timespec type of value? Or
do they intent
Some NICs allows 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
3 matches
Mail list logo
