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 0AF77A0350; Fri, 22 May 2020 20:43:18 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 9002F1D998; Fri, 22 May 2020 20:43:17 +0200 (CEST) Received: from mail-oi1-f173.google.com (mail-oi1-f173.google.com [209.85.167.173]) by dpdk.org (Postfix) with ESMTP id D19501D995 for ; Fri, 22 May 2020 20:43:15 +0200 (CEST) Received: by mail-oi1-f173.google.com with SMTP id l6so10128998oic.9 for ; Fri, 22 May 2020 11:43:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=radio-canada-ca.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XqO5LxRwBI7GSWL3KsY6GOh1JxUKRy5gF5bU9tBketQ=; b=jRNEQA7Dk5PbqRz3gVAC9/cEAQlL/NHzXCT/rZDoNcW3Vtr94k5gb46znXDwN8EePB GQ9qxA4QJe54dQtIA3TjKFKeV/TmESHr3nmQIwsiI93hNv+d+xFWQPpfLkHL68GOH8Rg 455XeZz5k66WyvtkxZ4v+vhB/XQsKrb+N6oRYSV85b7zsHw+K+q9t3aNkQLxBZo7alPi 11Vj0S5n9H2ZCu66FMFQvGgB6quzdHCRKrVsB7temYysAntFYk9zGWmVMjTnvZKQjeVl J7idwlIp3hY/5X0ClgD7CR85+akyTv09MYyW4qW4rCq9uKbkUadFaaNY/o0k2PpWyAJn W3xA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=XqO5LxRwBI7GSWL3KsY6GOh1JxUKRy5gF5bU9tBketQ=; b=S4VqzfLxWrnUoCV4B8qsJN+EPs2dNcHRdPERZqepPynBxnJA81BzY/Yqjv1q/OIlu9 ckRhFUEAQt/6zEeY23C7G1JT9XzHglybgRqtIK42TPhyVR034r6Hr5tgGJVuS0b7f7K7 3g2tmdoIg/wEhmvWFZ5BE4pnkiejRuBAUgSCPlEHK52zqMy/rtji06D74dbFnMXVvdmW cS5V3HGWB+wVKxEZSDlePOC6opYDZCA+mEMhM5OkBgQCjHnv4TNqBiSd/AGHxopX6eIq tN8T3h/uxl15Zf/D1FbJy41ZNcvjLCa3hKWx6R4DewCpT7vOC5Nv0ZbXNDFMs18iZx/t fTyQ== X-Gm-Message-State: AOAM533b26VhkTXvswqhxy6s7dfNlBHPXNI67pNeU3z2rfINQXw1yHgw EwLYcwx+rz5kRyDJ84b67L1N0medPVwCnSarWLBCFQ== X-Google-Smtp-Source: ABdhPJy0mkp93sXWTQCZChm2Xtq3pRKJaplgRoEBuLtqBhmKOslf/wzgDGWHzAQzkaDN1wI9zwqcFJOMtY/oF05x2Jk= X-Received: by 2002:aca:1312:: with SMTP id e18mr2644817oii.132.1590172993988; Fri, 22 May 2020 11:43:13 -0700 (PDT) MIME-Version: 1.0 References: <3986292.sUUuQTochr@thomas> <2766519.SlWGiteSXv@thomas> In-Reply-To: <2766519.SlWGiteSXv@thomas> From: PATRICK KEROULAS Date: Fri, 22 May 2020 14:43:02 -0400 Message-ID: To: Thomas Monjalon Cc: dev@dpdk.org, Vivien Didelot , shahafs@mellanox.com, rasland@mellanox.com, matan@mellanox.com Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] mlx5 & pdump: convert HW timestamps to nanoseconds 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" > > > > mlx5 part of libibverbs includes a ts-to-ns converter which takes the > > > > instantaneous clock info. It's unused in dpdk so far. I've tested it in the > > > > device/port init routine and the result looks reliable. Since this approach > > > > looks very simple, compared to the time sync mechanism, I'm trying to > > > > integrate. > > > > > > > > The conversion should occur in the primary process (testpmd) I suppose. > > > > 1) The needed clock info derives from ethernet device. Is it possible to > > > > access that struct from a rx callback? > > > > 2) how to attach the nanosecond to mbuf so that `pdump` catches it? > > > > (workaround: copy `mbuf->udata64` in forwarded packets.) > > > > 3) any other idea? > > > > > > The timestamp is carried in mbuf. > > > Then the conversion must be done by the ethdev caller (application or > > > any other upper layer). > > > > What if the converter function needs a clock_info? > > https://github.com/linux-rdma/rdma-core/blob/7af01c79e00555207dee6132d72e7bfc1bb5485e/providers/mlx5/mlx5dv.h#L1201 > > I'm affraid this info may change by the time the converter is called > > by upper layer. > > Indeed, the clock in the device is not an atomic one :) > We need to adjust the time conversion continuously. > I am not an expert of time synchronization, so I add more people Cc > who could help for having a precise timestamp. Thanks Thomas. Not sure this is a synchronization issue. We have dedicated processes (linuxptp) to keep both NIC and sys clocks in sync with an external clock. It is "just" a matter of unit conversion. If it has to be performed in dpdk-pdump, I would need some help to retrieve mlx5_clock_info from inside a secondary process. Looking at mlx5_read_clock(), this info is extracted from ibv_context which looks reachable in a primary process only (segfault, if I try in pdump).