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 64821A00BE; Tue, 7 Jul 2020 16:47:31 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 41DEC1DE4E; Tue, 7 Jul 2020 16:47:31 +0200 (CEST) Received: from mail-wr1-f66.google.com (mail-wr1-f66.google.com [209.85.221.66]) by dpdk.org (Postfix) with ESMTP id 8EF621DE49 for ; Tue, 7 Jul 2020 16:47:30 +0200 (CEST) Received: by mail-wr1-f66.google.com with SMTP id z2so23173076wrp.2 for ; Tue, 07 Jul 2020 07:47:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=A3rPrEKZ3waSMPkRuB7JyrqBH7T0E1XdXqDrNQUG0RI=; b=KySPrLHbPgfoktFShBjivNlTruTl/TSgp98vSowjj4RohNKv0IB1VRdGh+IOFQ9apT P5OuFH6DQHrWXXeIoxwW7uhgEiGf6DlA80TwdpKLaB6Rdtx/zyq2y1DdgYrdR1l75jc5 lxEI5O4rlYxqMZG7D9BGqcm+ZfYrDh5SfaaN2Lh3o9xFdeRPE6d7yRSVxmUeD34rhFF3 BwzmCNwWYpVnq0w6UXx2r8iTOTrdcsTfQSrnrmmxEmLYBC5OcLwZah/bm+0XaOdwHRHp g6VTcCO+drSXNg2wzDCLLODegWvXbyAUcsKx2KDZsR5+9geh1o+pj9HLzq9L/shJG6uj /cPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=A3rPrEKZ3waSMPkRuB7JyrqBH7T0E1XdXqDrNQUG0RI=; b=skxgYGwXD0dIUoyR8xYqyMLMHUe2eb26jnNHIOpPnDsvRZ4Q/QycPcrmHrgU1NVcpf pha+nFIGURRfD2RnRPcVau+lmdoYcG1SFLQipw0skLeGDP+9DxjHqs0CTAJmWGEccWwY FmDP1dniRnFd4510aszfZsnjTdzHF49AH2GQCgaB1KWgTbdKCRPSzdHVB26P8Y4KCcRA lGkszf4x1SWjo7VkKiSA5FwqaLTwGJvNuMV9MQ/OqJ/C94pyFOvBovW0jGLImpSfJh02 e0nS8alwZMpIe1mAvkv4mdbc3xbiJu/DPt/vT6c1Viigz8lFJWCZ1Hjm/hKd1KjmNCHM nReg== X-Gm-Message-State: AOAM5325HP/AW2l8cWp7oRR7dm7N5D8gvelHt+gKnMk/0qVrByKjG9Yf LeuIZ3OZOZ/JcXjd+Z+cevw0Bg== X-Google-Smtp-Source: ABdhPJxtDdHss4VQOEOZryy61b819v4RUCZbyii2l04yVYbvSzlHOILH/J8cvHsygBvTOhwQkxvjPg== X-Received: by 2002:adf:fe85:: with SMTP id l5mr51442597wrr.333.1594133250329; Tue, 07 Jul 2020 07:47:30 -0700 (PDT) Received: from 6wind.com (2a01cb0c0005a600345636f7e65ed1a0.ipv6.abo.wanadoo.fr. [2a01:cb0c:5:a600:3456:36f7:e65e:d1a0]) by smtp.gmail.com with ESMTPSA id g14sm1368436wrw.83.2020.07.07.07.47.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 07 Jul 2020 07:47:29 -0700 (PDT) Date: Tue, 7 Jul 2020 16:47:29 +0200 From: Olivier Matz To: PATRICK KEROULAS Cc: Vivien Didelot , dev@dpdk.org, Ferruh Yigit , Slava Ovsiienko Message-ID: <20200707144729.GK5869@platinum> References: <20200625190119.265739-1-vivien.didelot@gmail.com> <20200625190119.265739-4-vivien.didelot@gmail.com> <20200626064817.GW12564@platinum> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) 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" Hi Patrick, On Mon, Jul 06, 2020 at 02:36:30PM -0400, PATRICK KEROULAS wrote: > 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. OK, your main motivation for hardware timestamping is the accuracy, and your application logs the Rx timestamp into the pcap when using the PMD. For the pmd pcap part, the dynamic Tx timestamp flag that is being introduced by Slava [1] may fit your needs: ie. when the flag is set, it uses the provided timestamp which should be in nanosecs. [1] https://patchwork.dpdk.org/patch/73427/ For the conversion from hardware Rx timestamp into Tx timestamp (in nanosec), could it be done by your application? Early in the Rx path, if a packet has a Rx timestamp flag, do the conversion to nsecs, and set the timestamp field and the Tx timestamp flag. Regards, Olivier