From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 14519A04BB; Tue, 6 Oct 2020 18:35:18 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id E82332E81; Tue, 6 Oct 2020 18:35:16 +0200 (CEST) Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by dpdk.org (Postfix) with ESMTP id A9A6B2B8B for ; Tue, 6 Oct 2020 18:35:14 +0200 (CEST) IronPort-SDR: 1VmuTbQZiuKiLiZoJ2rsj2cyG5JxTaX+wibpKc8Q/HG9tvqEEIlTXhYG4/hmXFOc7LGY96w1aa fTZpBplkQClQ== X-IronPort-AV: E=McAfee;i="6000,8403,9765"; a="249273352" X-IronPort-AV: E=Sophos;i="5.77,343,1596524400"; d="scan'208";a="249273352" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Oct 2020 09:25:51 -0700 IronPort-SDR: D2HUKFnJP10v0QP0Eab83PKkreR+oWSk5yQQpYv3f64I1FL78XfmW805z9KH6kuPIOI2SBnkD/ HFHHsvJbrYbw== X-IronPort-AV: E=Sophos;i="5.77,343,1596524400"; d="scan'208";a="342364433" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.213.241.102]) ([10.213.241.102]) by fmsmga004-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Oct 2020 09:25:46 -0700 To: Patrick Keroulas , dev@dpdk.org, Vivien Didelot References: <20200724202315.19533-1-patrick.keroulas@radio-canada.ca> From: Ferruh Yigit Cc: Stephen Hemminger , =?UTF-8?Q?Morten_Br=c3=b8rup?= , Viacheslav Ovsiienko , Tom Barbette , Reshma Pattan , Olivier Matz , Thomas Monjalon , Andrew Rybchenko Message-ID: <4e38acac-fd2c-8172-269e-a45dbfcf0f37@intel.com> Date: Tue, 6 Oct 2020 17:25:42 +0100 MIME-Version: 1.0 In-Reply-To: <20200724202315.19533-1-patrick.keroulas@radio-canada.ca> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [[PATCH v3 0/4] pdump HW Rx timestamps for mlx5 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" On 7/24/2020 9:23 PM, Patrick Keroulas wrote: > The intention is to produce a pcap with nanosecond precision when > Rx timestamp offloading is activated on mlx5 NIC. > > The packets forwarded by testpmd hold the raw counter but a pcap > requires a time unit. Assuming that the NIC clock is already synced > with external master clock, this patchset simply integrates the > nanosecond converter that derives from device frequency and start time. > > v2 -> v3: > - replace ib_verbs nanosecond converter with more generic method > based on device frequency and start time. > > Patrick Keroulas (3): > net/mlx5: query device frequency > ethdev: add API to query device frequency > pdump: convert timestamp to nanoseconds on Rx path > > Vivien Didelot (1): > net/pcap: support hardware Tx timestamps > We have three patch/patchset for same issue, 1) Current one, https://patches.dpdk.org/user/todo/dpdk/?series=11294 2) Vivien's series: https://patches.dpdk.org/user/todo/dpdk/?series=10678 3) Vivien's pcap patch: https://patches.dpdk.org/user/todo/dpdk/?series=10403 And one related one from Slava, 4) https://patchwork.dpdk.org/project/dpdk/list/?series=10948&state=%2A&archive=both I am replying to this one since this is the latest, but first can we clarify if all are still valid and can we combine the effort? Second, the problems to solve, 1) Device provided timestamp value has no unit, it needs to be converted to nanosecond. There are different approaches in above patches, - One adds '.convert_ts_to_ns' dev_ops to make PMD convert the timestamp - Other adds '.eth_get_clock_freq' dev_ops, to get frequency from device clock so that conversion can be done within the app. - I wonder why existing 'rte_eth_read_clock()' can't be enough for conversion, as described in its documentation: https://doc.dpdk.org/api/rte__ethdev_8h.html#a4346bf07a0d302c9ba4fe06baffd3196 rte_eth_read_clock(port, start); rte_delay_ms(100); rte_eth_read_clock(port, end); double freq = (end - start) * 10; 2) Where to put the timestamps data, is it to the 'mbuf->timestamp' or dynamic filed 'RTE_MBUF_DYNFIELD_TIMESTAMP_NAME'? Using dynamic field of requires more work on registering and looking up the fields. 3) Calculation in the datapath should be done in a performance optimized way, instead of using division. 4) Should the timestamp value provided by the Rx device used, or should the time when the packet transmitted used. I can see current use case seems first one, but can there be cases we would like to record when packet exactly sent. 5) Should we create a 'PKT_TX_TIMESTAMP' flag, instead of re-using the Rx one, to let the application explicitly define which packets to record timestamp. Please add if I missing more.