From mboxrd@z Thu Jan 1 00:00:00 1970 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) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 9A0A8234BE; Wed, 27 Mar 2019 10:48:41 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Wed, 27 Mar 2019 10:48:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=mesmtp; bh=ku/fMh5A+jmqx/R6kCKDX0CZE5TwrMMVT7MASfPBpEM=; b=si4aYfB+wGQA /CC4q0BepCY3t0/QSw1r8r79mxFkotU5rLRSMtuf/Bo2CJyEZ22iT1jKKnaQ19Iw S/IfYR/fUlkhwwGAXKr0TLIh2e21bQfCINkaGwfHQ7ac3PNZof+HAovbpif6JiYs zphqrz+MDHdG4H4TyiYBpuo9uffGods= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=ku/fMh5A+jmqx/R6kCKDX0CZE5TwrMMVT7MASfPBp EM=; b=M5cEG9DuNF0FVnE5Kpc3BD4qfD97PHPStGcfbEQPtPgXzYs+rfC0NYCfn vTVyeFwMqjO/HPxr1HO6dK8w9tIhgua+/VMmOK8/WixXoESNGk89vPyv00p61OWb TAMi8DEHhc81DXx5nadiiNS1PISed21xrb91rodwKLarnNF+9DllsgrMxJGhEuvK CkuYhx4Zoqy+b0TpYLJPrBRwC5iTOi3t0IRUQQWbKUzg8xnFPlAO6jzQdCq0JsPy 8rtalcgJf9GKdDwNCLH0t4ZhAWzwXjf1+1VMoZU7wmnKgaNXRDrz0Hm8IxZj1Zuv y+pirLWiiwXPRfDM3N+33cbMUYBuQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedutddrkedvgdeigecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucfkph epjeejrddufeegrddvtdefrddukeegnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhho mhgrshesmhhonhhjrghlohhnrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 3CE1B10316; Wed, 27 Mar 2019 10:48:39 -0400 (EDT) From: Thomas Monjalon To: Stephen Hemminger Cc: Tom Barbette , dev@dpdk.org, bruce.richardson@intel.com, john.mcnamara@intel.com, Ferruh Yigit , Andrew Rybchenko , Shahaf Shuler , Yongseok Koh Date: Wed, 27 Mar 2019 15:48:36 +0100 Message-ID: <1643873.36pbUZ63Oi@xps> In-Reply-To: <20190327074112.427c4758@shemminger-XPS-13-9360> References: <20190327061935.19572-1-barbette@kth.se> <20190327074112.427c4758@shemminger-XPS-13-9360> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v2 0/3] Add rte_eth_read_clock API X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2019 14:48:42 -0000 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? From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id 706DCA05D3 for ; Wed, 27 Mar 2019 15:48:44 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 8CCFE5F1B; Wed, 27 Mar 2019 15:48:43 +0100 (CET) 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) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 9A0A8234BE; Wed, 27 Mar 2019 10:48:41 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Wed, 27 Mar 2019 10:48:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=mesmtp; bh=ku/fMh5A+jmqx/R6kCKDX0CZE5TwrMMVT7MASfPBpEM=; b=si4aYfB+wGQA /CC4q0BepCY3t0/QSw1r8r79mxFkotU5rLRSMtuf/Bo2CJyEZ22iT1jKKnaQ19Iw S/IfYR/fUlkhwwGAXKr0TLIh2e21bQfCINkaGwfHQ7ac3PNZof+HAovbpif6JiYs zphqrz+MDHdG4H4TyiYBpuo9uffGods= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=ku/fMh5A+jmqx/R6kCKDX0CZE5TwrMMVT7MASfPBp EM=; b=M5cEG9DuNF0FVnE5Kpc3BD4qfD97PHPStGcfbEQPtPgXzYs+rfC0NYCfn vTVyeFwMqjO/HPxr1HO6dK8w9tIhgua+/VMmOK8/WixXoESNGk89vPyv00p61OWb TAMi8DEHhc81DXx5nadiiNS1PISed21xrb91rodwKLarnNF+9DllsgrMxJGhEuvK CkuYhx4Zoqy+b0TpYLJPrBRwC5iTOi3t0IRUQQWbKUzg8xnFPlAO6jzQdCq0JsPy 8rtalcgJf9GKdDwNCLH0t4ZhAWzwXjf1+1VMoZU7wmnKgaNXRDrz0Hm8IxZj1Zuv y+pirLWiiwXPRfDM3N+33cbMUYBuQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedutddrkedvgdeigecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucfkph epjeejrddufeegrddvtdefrddukeegnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhho mhgrshesmhhonhhjrghlohhnrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 3CE1B10316; Wed, 27 Mar 2019 10:48:39 -0400 (EDT) From: Thomas Monjalon To: Stephen Hemminger Cc: Tom Barbette , dev@dpdk.org, bruce.richardson@intel.com, john.mcnamara@intel.com, Ferruh Yigit , Andrew Rybchenko , Shahaf Shuler , Yongseok Koh Date: Wed, 27 Mar 2019 15:48:36 +0100 Message-ID: <1643873.36pbUZ63Oi@xps> In-Reply-To: <20190327074112.427c4758@shemminger-XPS-13-9360> References: <20190327061935.19572-1-barbette@kth.se> <20190327074112.427c4758@shemminger-XPS-13-9360> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [PATCH v2 0/3] Add rte_eth_read_clock API X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Message-ID: <20190327144836.bIZjkhHMGlh_h2E55ExsfsQn2_pA4BzaB0X0xg-_Dxo@z> 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?