From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <dev-bounces@dpdk.org> Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id 164D4A05D3 for <public@inbox.dpdk.org>; Wed, 27 Mar 2019 15:54:39 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 2DEB57CB0; Wed, 27 Mar 2019 15:54:38 +0100 (CET) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id 08FC3326D for <dev@dpdk.org>; Wed, 27 Mar 2019 15:54:36 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Mar 2019 07:54:35 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.60,277,1549958400"; d="scan'208";a="144333550" Received: from fmsmsx106.amr.corp.intel.com ([10.18.124.204]) by FMSMGA003.fm.intel.com with ESMTP; 27 Mar 2019 07:54:35 -0700 Received: from fmsmsx102.amr.corp.intel.com (10.18.124.200) by FMSMSX106.amr.corp.intel.com (10.18.124.204) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 27 Mar 2019 07:54:34 -0700 Received: from fmsmsx117.amr.corp.intel.com ([169.254.3.142]) by FMSMSX102.amr.corp.intel.com ([169.254.10.60]) with mapi id 14.03.0415.000; Wed, 27 Mar 2019 07:54:33 -0700 From: "Wiles, Keith" <keith.wiles@intel.com> To: Stephen Hemminger <stephen@networkplumber.org> CC: Tom Barbette <barbette@kth.se>, dpdk-dev <dev@dpdk.org>, "Richardson, Bruce" <bruce.richardson@intel.com>, "Mcnamara, John" <john.mcnamara@intel.com>, Thomas Monjalon <thomas@monjalon.net>, "Yigit, Ferruh" <ferruh.yigit@intel.com>, Andrew Rybchenko <arybchenko@solarflare.com>, Shahaf Shuler <shahafs@mellanox.com>, "Yongseok Koh" <yskoh@mellanox.com> Thread-Topic: [dpdk-dev] [PATCH v2 0/3] Add rte_eth_read_clock API Thread-Index: AQHU5GU+6LVCiFWFkE+OD86VC5pTkaYgAs0AgAADuIA= Date: Wed, 27 Mar 2019 14:54:32 +0000 Message-ID: <3652C395-2CA3-4F74-BD45-0F06386633FB@intel.com> References: <20190327061935.19572-1-barbette@kth.se> <20190327074112.427c4758@shemminger-XPS-13-9360> In-Reply-To: <20190327074112.427c4758@shemminger-XPS-13-9360> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.254.22.73] Content-Type: text/plain; charset="UTF-8" Content-ID: <E3D0CEB846880143941FF3E75F334FC9@intel.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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 <dev.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org Sender: "dev" <dev-bounces@dpdk.org> Message-ID: <20190327145432.p-wvASusTvCpse9K8EZsZ1ZhO7seffbNVzOXmbjfbjE@z> > On Mar 27, 2019, at 9:41 AM, Stephen Hemminger <stephen@networkplumber.or= g> wrote: >=20 > On Wed, 27 Mar 2019 07:19:32 +0100 > Tom Barbette <barbette@kth.se> wrote: >=20 >> 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. >>=20 >> 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). >>=20 >> This patch series adds support for MLX5. >>=20 >> 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. >>=20 >> 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. >>=20 >> 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 fun= ctions >> to use PTP synchronization. >> The device raw clock is not "sync" in any way. More importantly, the ret= urned >> value is not a timeval, but an amount of ticks. We could have a cast-bas= ed >> solution, but on top of being an ugly solution, some people seeing the t= imeval >> type of rte_eth_timesync_read_time could use it blindly. >>=20 >> Change in v2: >> - Rebase on current master >>=20 >> 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 >>=20 >> doc/guides/nics/features.rst | 1 + >> doc/guides/sample_app_ug/rxtx_callbacks.rst | 9 ++- >> drivers/net/mlx5/mlx5.c | 1 + >> drivers/net/mlx5/mlx5.h | 1 + >> drivers/net/mlx5/mlx5_ethdev.c | 29 +++++++ >> drivers/net/mlx5/mlx5_glue.c | 8 ++ >> drivers/net/mlx5/mlx5_glue.h | 2 + >> examples/rxtx_callbacks/Makefile | 2 + >> examples/rxtx_callbacks/main.c | 86 ++++++++++++++++++++- >> examples/rxtx_callbacks/meson.build | 1 + >> lib/librte_ethdev/rte_ethdev.c | 13 ++++ >> lib/librte_ethdev/rte_ethdev.h | 44 +++++++++++ >> lib/librte_ethdev/rte_ethdev_core.h | 6 ++ >> lib/librte_ethdev/rte_ethdev_version.map | 1 + >> lib/librte_mbuf/rte_mbuf.h | 2 + >> 15 files changed, 201 insertions(+), 5 deletions(-) >=20 >=20 > I like this approach but would like to see the same API supported > on multiple devices. >=20 > The current timestamp API is a mess because not all devices behave the > same way. Trying to write an application that uses timestamping is theref= ore > very difficult. Another question is this an optional API for a PMD? I assume it is. 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? Regards, Keith