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 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 ; Mon, 6 Jul 2020 20:36:41 +0200 (CEST) Received: by mail-ot1-f67.google.com with SMTP id h1so10232000otq.12 for ; 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 Date: Mon, 6 Jul 2020 14:36:30 -0400 Message-ID: To: Olivier Matz Cc: Vivien Didelot , dev@dpdk.org, Ferruh Yigit 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Fri, Jun 26, 2020 at 2:48 AM Olivier Matz 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.