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. More importantly, the returned value is not a timeval. So it's true this patch actually does a cast from timeval in ib_verbs, but it's already a "bad usage" in some sense because the value sitting in tv_nsec is not an amount of nsec but only an amount of ticks. I would be afraid some people seeing the timeval type of rte_eth_timesync_read_time would use it blindly.
But as far as I'm concerned, I can go with one or the other in our use cases... Thanks, Tom ________________________________________ De : z...@semihalf.com <z...@semihalf.com> Envoyé : mercredi 5 décembre 2018 17:33 À : Tom Barbette; dev@dpdk.org Cc : Zyta Szpak Objet : Re: [RFC PATCH 0/3] Add rte_eth_read_clock API From: Zyta Szpak <z...@semihalf.com> 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 to read different clocks?
