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 0FDE4A05D3 for <public@inbox.dpdk.org>; Wed, 27 Mar 2019 15:41:20 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 7AFFA5F14; Wed, 27 Mar 2019 15:41:19 +0100 (CET) Received: from mail-pg1-f196.google.com (mail-pg1-f196.google.com [209.85.215.196]) by dpdk.org (Postfix) with ESMTP id 5290F5B2C for <dev@dpdk.org>; Wed, 27 Mar 2019 15:41:18 +0100 (CET) Received: by mail-pg1-f196.google.com with SMTP id q1so1863267pgv.13 for <dev@dpdk.org>; Wed, 27 Mar 2019 07:41:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=1I28288s6S6CZmtU/1vp4KGn2zxt5VhYi7oixiyFvHU=; b=q+DW5Djkt71euba/2Nw34jmHjO8VmN1CVr7erAcs+WRRRGmV5bJs8hF3Di+iyD886W IcvM2QYkEAx7aMg81igyLS/EHb9MyC3qUuJaltFfnwXjQNhi5/SubaRN517zy0OL5h33 /LYy7emK/yQ+raRNHFGJxsFWFy67Gg8gCZ4mTZiRv6eAS82WcMIcs20mhOUJjcv2ykDD PA15JpaPUoC7tQjfTIgYgUfJb5Muqvcrohxvi3Q217GZ5xS8fjNNF6O4xb2wOLrRqNvu Tm4OMT8awUI5CkE5wy/19kgb67YOCNRejUMOaorcUKp1FFqkYEKs/dSIHIr7Ev88Jd+w YuTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=1I28288s6S6CZmtU/1vp4KGn2zxt5VhYi7oixiyFvHU=; b=TgroRHw9PxTUqNh2KCLzU0mJjvEu/fSb9FUVO9clLQ/xhn66we844r0GzOCPXIM7B/ nA+vuwCIVXCxupLnNAPc1EOuW52b4309mA1wqLA8gyp0lc07TaL9DkEOnT/3gvdt5jUv u32Sfzijgrt9XLTd5MAv1AGCbTj2tBzFVZrAhaffEHeXSOIweyRlfBYK+PgIonA/5p+S Stak5UscNGMvrOfAeBQBGwg5cgSEOCTH9teRTje4pN5nBcHzWsqxPuzXdoiTzfEZXwsI n4SgiCHQynXmCFRA8fplr4SbUZbqXsjApXwM3v3ZqRbhKHpn5C+sYE+w7NFUVJh7AM6a ZO7w== X-Gm-Message-State: APjAAAXlXyol4yIrSfS6bPVGtFgyzCdVS9iMIjUkS2G65fuh/NnppIn4 eeSNsG7q8yoGEPmosgn4Fea+fA== X-Google-Smtp-Source: APXvYqxfWyGn3CYJsRoxY3iPSaL2zXDOHHi9mM8vqHSP6yxZbs+nTZtATzIW8ELcUPp2E9ykf9OfJA== X-Received: by 2002:a63:28f:: with SMTP id 137mr8201839pgc.377.1553697677437; Wed, 27 Mar 2019 07:41:17 -0700 (PDT) Received: from shemminger-XPS-13-9360 (204-195-22-127.wavecable.com. [204.195.22.127]) by smtp.gmail.com with ESMTPSA id f125sm41288556pfc.91.2019.03.27.07.41.16 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 27 Mar 2019 07:41:17 -0700 (PDT) Date: Wed, 27 Mar 2019 07:41:12 -0700 From: Stephen Hemminger <stephen@networkplumber.org> To: Tom Barbette <barbette@kth.se> Cc: dev@dpdk.org, bruce.richardson@intel.com, john.mcnamara@intel.com, Thomas Monjalon <thomas@monjalon.net>, Ferruh Yigit <ferruh.yigit@intel.com>, Andrew Rybchenko <arybchenko@solarflare.com>, Shahaf Shuler <shahafs@mellanox.com>, Yongseok Koh <yskoh@mellanox.com> Message-ID: <20190327074112.427c4758@shemminger-XPS-13-9360> In-Reply-To: <20190327061935.19572-1-barbette@kth.se> References: <20190327061935.19572-1-barbette@kth.se> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit 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: <20190327144112._dFPhKx_S8P0uk_8geWLmxPfsKUvDB0kI-972u97hc4@z> On Wed, 27 Mar 2019 07:19:32 +0100 Tom Barbette <barbette@kth.se> 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 > > 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(-) 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.