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 inbox.dpdk.org (Postfix) with ESMTP id 22125A00C5;
	Mon,  6 Jul 2020 20:36:43 +0200 (CEST)
Received: from [92.243.14.124] (localhost [127.0.0.1])
	by dpdk.org (Postfix) with ESMTP id 049DE1DC21;
	Mon,  6 Jul 2020 20:36:43 +0200 (CEST)
Received: from mail-ot1-f67.google.com (mail-ot1-f67.google.com
 [209.85.210.67]) by dpdk.org (Postfix) with ESMTP id 00E3F1DC0A
 for <dev@dpdk.org>; Mon,  6 Jul 2020 20:36:41 +0200 (CEST)
Received: by mail-ot1-f67.google.com with SMTP id h1so10232000otq.12
 for <dev@dpdk.org>; Mon, 06 Jul 2020 11:36:41 -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=0r1PdJ148Mf4mRTcZFfRS6kkJjHlrdFivH6YXSojsIc=;
 b=Jk0sewBC0EQpZkmIhoqRKPt/VUy8hazJVMgON+YoM5BqX1F7AgxtJjqx3vlMRIetvs
 qUsRV0tsSurrkq7mRPuWqlC2nOlHeGt2IchOn1Oij/CkossvRPS8S/ye56zJINWSPohu
 Jo63J9OdXVo9G5NO1sZi1x6HMX2uW9J3tC27K5Dy+a3Nep1dZLApCxYYjLucEyV6fSZC
 iH108jD/fFe/9Jno6iAQkMTaswO+UNt7ESfIfa2ejU5C4KLH3WfzVykbWs/VzX/PXB7T
 ++sAyvreUg8Hlo3jn0JL6RAzfQn6ZPGPNUyeBLJUEc0azxBuVjpnelvcRW9DKeC58P03
 bFfw==
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=0r1PdJ148Mf4mRTcZFfRS6kkJjHlrdFivH6YXSojsIc=;
 b=tWwWwmqfiIfuC1ogIjqGWVBUlkXyglP/mMqbRO3xpmECIxbcpHht0V8OQj8pgHVBb6
 sq06Tl3LqrtzDJTrwGv41Cp6UVtDFq/UnnDRGVYwBet1tvtqEQVUOP3IPxYJmqIE3Eys
 IzmaKLCH+tkKy3RiK46zDWIkOhtxZMlxOa5Nk34r0McRPPrjNhqVfgM5p6t1C3+NBF6p
 58yp4UZcE0QrwnenEU6XpOGvJJYI6pT3GBrZplBRoot0nbJaQbTM08gPDemxswhmYZYP
 7FunMoss3BGnfn9AKHR8IaD89dN/L576m/SGBrBzqgTGk3rcY201tFB4eHgpM9FsrkbN
 bV0w==
X-Gm-Message-State: AOAM533kafiLnM8dAq1dMDT4kfP/gJHOvMrJTbJ/I82SQEGE4imH0v2U
 J2CXun4wBsN6oGeFmO15rtpSh9FD7kClhWwGmueLbw==
X-Google-Smtp-Source: ABdhPJx7Q3tmOYKZtPPhRLoqp8ejyWy9Ulw1mOGYTOVrbtre8f9QLor3YBgHcdeLBQYpPSVyjs7rcXcHIW6JcS386jA=
X-Received: by 2002:a05:6830:1d74:: with SMTP id
 l20mr42084271oti.319.1594060601207; 
 Mon, 06 Jul 2020 11:36:41 -0700 (PDT)
MIME-Version: 1.0
References: <20200625190119.265739-1-vivien.didelot@gmail.com>
 <20200625190119.265739-4-vivien.didelot@gmail.com>
 <20200626064817.GW12564@platinum>
In-Reply-To: <20200626064817.GW12564@platinum>
From: PATRICK KEROULAS <patrick.keroulas@radio-canada.ca>
Date: Mon, 6 Jul 2020 14:36:30 -0400
Message-ID: <CALEF-=CWOgTiUDTxqngx7_StG0xap4qGWEWz9uzU7SxqB9U78g@mail.gmail.com>
To: Olivier Matz <olivier.matz@6wind.com>
Cc: Vivien Didelot <vivien.didelot@gmail.com>, dev@dpdk.org, 
 Ferruh Yigit <ferruh.yigit@intel.com>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [dpdk-dev] [RFC PATCH 3/3] net/pcap: support hardware Tx
	timestamps
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>

On Fri, Jun 26, 2020 at 2:48 AM Olivier Matz <olivier.matz@6wind.com> wrote:
> I don't get why you expect that timestamp to be in nanoseconds.
> The conversion is done in librte_pdump (in the previous patch),
> but it won't work if the library is not used, right?
>

You're right Olivier. I took advantage of the definition of mbuf->timestamp
as being "not normalized". The proposed conversion needs NIC clock info
which can't be accessed from the secondary process. Do you have a better
suggestion? Should I set a user flag in mbuf for nanoseconds?

> Out of curiosity, can you explain your motivation for using the hardware
> timestamp? Is it faster? More accurate? (knowing it timestamps the Rx
> operation, not the Tx)

Accuracy is our requirement in the broadcast industry (and probably
in finance as well) where core systems are very time sensitive. Our
application uses the NIC mostly as a receiver for UDP stream monitoring
in order to measure the network propagation delay and jitter. Using SW Rx
timestamps completely breaks this requirement.