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