From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Monjalon Subject: Re: [PATCH v2 0/3] Add rte_eth_read_clock API Date: Wed, 27 Mar 2019 15:48:36 +0100 Message-ID: <1643873.36pbUZ63Oi@xps> References: <20190327061935.19572-1-barbette@kth.se> <20190327074112.427c4758@shemminger-XPS-13-9360> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit Cc: Tom Barbette , dev@dpdk.org, bruce.richardson@intel.com, john.mcnamara@intel.com, Ferruh Yigit , Andrew Rybchenko , Shahaf Shuler , Yongseok Koh To: Stephen Hemminger Return-path: Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by dpdk.org (Postfix) with ESMTP id 117785F14 for ; Wed, 27 Mar 2019 15:48:42 +0100 (CET) In-Reply-To: <20190327074112.427c4758@shemminger-XPS-13-9360> List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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. > > > > To make sense of this value, one at least needs to be able to query > > the current hardware clock value. As with the TSC, from there > > a frequency can be derieved by querying multiple time the current value of the > > internal clock with some known delay between the queries (example > > provided in the API doc). > > > > This patch series adds support for MLX5. > > > > An example app is provided in the rxtx_callback application. > > It has been updated to display, on top of the software latency > > in cycles, the total latency since the packet was received in hardware. > > The API is used to compute a delta in the TX callback. The raw amount of > > ticks is converted to cycles using a variation of the technique describe above. > > > > Aside from offloading timestamping, which relieve the > > software from a few operations, this allows to get much more precision > > when studying the source of the latency in a system. > > Eg. in our 100G, CX5 setup the rxtx callback application shows > > SW latency is around 74 cycles (TSC is 3.2Ghz), but the latency > > including NIC processing, PCIe, and queuing is around 196 cycles. > > > > One may think at first this API is overlapping with te_eth_timesync_read_time. > > rte_eth_timesync_read_time is clearly identified as part of a set of functions > > to use PTP synchronization. > > The device raw clock is not "sync" in any way. More importantly, the returned > > value is not a timeval, but an amount of ticks. We could have a cast-based > > solution, but on top of being an ugly solution, some people seeing the timeval > > type of rte_eth_timesync_read_time could use it blindly. > > > > Change in v2: > > - Rebase on current master > > > > Tom Barbette (3): > > rte_ethdev: Add API function to read dev clock > > mlx5: Implement support for read_clock > > rxtx_callbacks: Add support for HW timestamp > > I like this approach but would like to see the same API supported > on multiple devices. > > The current timestamp API is a mess because not all devices behave the > same way. Trying to write an application that uses timestamping is therefore > very difficult. So what do you suggest?