Message ID | 20200724202315.19533-1-patrick.keroulas@radio-canada.ca (mailing list archive) |
---|---|
Headers |
Return-Path: <dev-bounces@dpdk.org> X-Original-To: patchwork@inbox.dpdk.org Delivered-To: patchwork@inbox.dpdk.org Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 9546EA0526; Fri, 24 Jul 2020 22:23:35 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 1BA401C031; Fri, 24 Jul 2020 22:23:34 +0200 (CEST) Received: from mail-qk1-f196.google.com (mail-qk1-f196.google.com [209.85.222.196]) by dpdk.org (Postfix) with ESMTP id CBFC61C030 for <dev@dpdk.org>; Fri, 24 Jul 2020 22:23:32 +0200 (CEST) Received: by mail-qk1-f196.google.com with SMTP id l23so9880270qkk.0 for <dev@dpdk.org>; Fri, 24 Jul 2020 13:23:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=radio-canada-ca.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id; bh=cGgFOtVKGHrO3bwsAIq0vsCvXiZA6Weq/0VmTSz2lxI=; b=GBZ+7f3VVylngdJXmjEyx+ZiDszUpeAa5thvm6+/xaCJo7d/v2FifFFg69fPXm4eC7 QMeyZw70vtwzS06bf/mlJt0zH12vv+YXawGKGOucMswR9q+6aNOHIqZY7IjThxuC6l63 D8VSqz0qGKXmWtP3HHaKaS+TXOPcLuQF18/o+soRXltHmsWgCjmuOM2YpoZGWLSMzJ8k 7p/+97chJU+whrHDJTIDxlCrYnolSExZ67KBZlRhg4TbMOvBp1N/Skq8eJuCn6HRn4QD p8onqTQbbr+AgaZrSEUyCMOZTTKFjJ6fCbe5uTS6PQGmpDWCJ55gBxkgZFKZkciVAU5K OtvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=cGgFOtVKGHrO3bwsAIq0vsCvXiZA6Weq/0VmTSz2lxI=; b=XZ8g5A2vqK6bHp35i8des9D4Wn36M6LIFeokWlnljZV6VWKRZpBOa29e7bHA/CcPW4 db875l/YBcZ6LIkBdVw20xG4CdlAW8zqQieAOyXTobQzPcarqOt303lLefw7R+ssMfIG ELiZM16sUErkDw3TMZV7mXj6fO2pat1FaSmFUAQ7BMeo75nHsDYm8otbBC7Kcdhx+UsY zGPFLgdABU6CTTvdhD8Sn9/UKRXkMw8jVySbAHm5qM3NdYUY7CmSph34wW1vzytR/2WI t2JU8ndgZ6CAKsSpK24+6LI1fMzkhVvRyGuZnpyle2WY2IckzRCLI1+zD5zwgAEbdGsk xiig== X-Gm-Message-State: AOAM5331QtxM29pAsK3BFA/LSgZBbt1CMQt9U903vC1/9SEUyJRwwckP Y2Q5O446g40Xn4nkItmY/XUJXTDmwq8= X-Google-Smtp-Source: ABdhPJwMtdDnTRlhMQvA6mOEu0wjcQPBPyjW7TYiDpg37eGNjkk4O8JzVA7jRgIZOBXctaDxs2ftvA== X-Received: by 2002:a05:620a:222c:: with SMTP id n12mr12122934qkh.210.1595622211843; Fri, 24 Jul 2020 13:23:31 -0700 (PDT) Received: from localhost.localdomain (modemcable246.10-73-45.static.videotron.ca. [45.73.10.246]) by smtp.gmail.com with ESMTPSA id f7sm5216089qkj.32.2020.07.24.13.23.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 24 Jul 2020 13:23:31 -0700 (PDT) From: Patrick Keroulas <patrick.keroulas@radio-canada.ca> To: dev@dpdk.org Cc: Patrick Keroulas <patrick.keroulas@radio-canada.ca> Date: Fri, 24 Jul 2020 16:23:11 -0400 Message-Id: <20200724202315.19533-1-patrick.keroulas@radio-canada.ca> X-Mailer: git-send-email 2.17.1 Subject: [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 <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> |
Series | pdump HW Rx timestamps for mlx5 | |
Message
Patrick Keroulas
July 24, 2020, 8:23 p.m. UTC
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 doc/guides/rel_notes/release_20_08.rst | 1 + drivers/common/mlx5/mlx5_devx_cmds.c | 2 ++ drivers/common/mlx5/mlx5_devx_cmds.h | 1 + drivers/net/mlx5/linux/mlx5_ethdev_os.c | 22 ++++++++++++++++ drivers/net/mlx5/linux/mlx5_os.c | 1 + drivers/net/mlx5/mlx5.h | 1 + drivers/net/pcap/rte_eth_pcap.c | 32 +++++++++++++----------- lib/librte_ethdev/rte_ethdev.c | 12 +++++++++ lib/librte_ethdev/rte_ethdev.h | 17 +++++++++++++ lib/librte_ethdev/rte_ethdev_core.h | 5 ++++ lib/librte_ethdev/rte_ethdev_version.map | 2 ++ lib/librte_pdump/rte_pdump.c | 27 ++++++++++++++++++++ 12 files changed, 109 insertions(+), 14 deletions(-)
Comments
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.
> From: Ferruh Yigit [mailto:ferruh.yigit@intel.com] > Sent: Tuesday, October 6, 2020 6:26 PM > > 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&ar > chive=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#a4346bf07a0d302c9ba4fe06ba > ffd3196 > 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. Regarding RX timestamps: I believe that it is on the roadmap to remove the timestamp field from the mbuf and make it a dynamic field instead. Furthermore, I understand that some Mellanox NICs have accurate "wall clock" timestamping capability, possibly even PTP synchronized. So I propose to make two variants of the dynamic timestamp field, one with an accurate "wall clock" timestamp for NICs with that capability, and one with an NIC-specific unitless timestamp (like the current timestamp). Regarding TX timestamps: Do any NICs currently have a TX pipeline that puts a TX timestamp in the descriptor on transmission to the wire instead of just marking the descriptor as free? If not, then there is probably no need for TX timestamps at that level of accuracy for captured packets. The application can set the timestamp in the captured/mirrored packets while cloning the originals and passing them on to the NIC driver. And if the dynamic mbuf field that instructs the NIC to transmit the packet at a specific time is present, the application might even use that timestamp, knowing that the NIC will transmit the packet at that time. Med venlig hilsen / kind regards - Morten Brørup