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 6480AA0350; Fri, 26 Jun 2020 08:48:21 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 3013D1B203; Fri, 26 Jun 2020 08:48:20 +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 04AA31B13C for ; Fri, 26 Jun 2020 08:48:18 +0200 (CEST) Received: by mail-wr1-f66.google.com with SMTP id h5so8339715wrc.7 for ; Thu, 25 Jun 2020 23:48:18 -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=wm1a4LOC591rh75gODBKx6b8grFWbJbpdHStPBwO1oM=; b=HFAuTh9SYZ2YMCJHe8qcurxynPkAZLbccqHgDlbh5XoV49L/j/wkg/AGAwdsaMhF2b sV4bntvyR6yzzNxS2j34q1XSY4/+wnpP/GiiQ4LWoNBvOPlL2HT0C1r85BehsBcDVquK igdixhrcaKUirGq6UadpvFCvRK2T3KdH4Q9UtnKf9kMn6TgjBd2N8l/PuchLPpXWV4Dj Lh4CL0m/A2rkomMkWSThTzA050AkcM7UkYv46TlHVY3QaugjKIkflNgamF4hPY8gvFnZ hkEUeETqkxqCpJUi5LSkOVQ4LX5x5OQ2xiS6/g1MGAxGl1Chc/smjH7IeX0HVi/S8wZY /Exw== 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=wm1a4LOC591rh75gODBKx6b8grFWbJbpdHStPBwO1oM=; b=omvZ43FFdBVOq7fVMzxGPVNECoofmsUg1NuWD7vxGkyDisHsU3VxwQgEr7k+rirAEN CF6ez3iGnjFb1rMEsw5+MW5ih3rlmt7lWUdLS7FyhfqYaCAGML+FzRVI+3dwnftClB0s csdyUSJ7opjLRsgNoz6FfzmymajjzgceLu/fNT4qkMpe/KHEqL7U5S8ilP75nimhJ46F Rs00NKH77LHvyO9qAcMXybSXsmtwxl9go98T85ebR0HjZUHJwFKF2IPRkWnRYFrbep4r Rk1V2F/B+LcxLC8cHkAZ2PngvPocQElQTozeoOnI2FhuQK4ArpJySyaat8ANboa86eDm YoHA== X-Gm-Message-State: AOAM530sPQEVXBKlNWRUhk8DKi6c5byto6rd8SQvyvhKb1Q/Ar+8eBBh f5Hzsgji9lPseUhGUKNJIlrPGA== X-Google-Smtp-Source: ABdhPJy4+MpV7AxmwypKnRycs76BrYjKumCE4gKHeHPYFcXr7SZ2DrUMBlFr8970z6cbpxwA1b0HVA== X-Received: by 2002:adf:a507:: with SMTP id i7mr2286718wrb.0.1593154098638; Thu, 25 Jun 2020 23:48:18 -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 x13sm37048893wre.83.2020.06.25.23.48.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 25 Jun 2020 23:48:18 -0700 (PDT) Date: Fri, 26 Jun 2020 08:48:17 +0200 From: Olivier Matz To: Vivien Didelot Cc: dev@dpdk.org, Ferruh Yigit , Patrick Keroulas Message-ID: <20200626064817.GW12564@platinum> References: <20200625190119.265739-1-vivien.didelot@gmail.com> <20200625190119.265739-4-vivien.didelot@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200625190119.265739-4-vivien.didelot@gmail.com> 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" On Thu, Jun 25, 2020 at 03:01:19PM -0400, Vivien Didelot wrote: > When hardware timestamping is enabled on Rx path, system time should > no longer be used to calculate the timestamps when dumping packets. > > Instead, use the value stored by the driver in mbuf->timestamp > and assume it is already converted to nanoseconds (otherwise the > application may edit the packet headers itself afterwards). > > Signed-off-by: Vivien Didelot > Signed-off-by: Patrick Keroulas > --- > doc/guides/rel_notes/release_20_08.rst | 1 + > drivers/net/pcap/rte_eth_pcap.c | 30 +++++++++++++++----------- > 2 files changed, 18 insertions(+), 13 deletions(-) > > diff --git a/doc/guides/rel_notes/release_20_08.rst b/doc/guides/rel_notes/release_20_08.rst > index a67015519..cd1ca987f 100644 > --- a/doc/guides/rel_notes/release_20_08.rst > +++ b/doc/guides/rel_notes/release_20_08.rst > @@ -61,6 +61,7 @@ New Features > Updated PCAP driver with new features and improvements, including: > > * Support software Tx nanosecond timestamps precision. > + * Support hardware Tx timestamps. > > * **Updated Mellanox mlx5 driver.** > > diff --git a/drivers/net/pcap/rte_eth_pcap.c b/drivers/net/pcap/rte_eth_pcap.c > index 13a3d0ac7..3d80b699b 100644 > --- a/drivers/net/pcap/rte_eth_pcap.c > +++ b/drivers/net/pcap/rte_eth_pcap.c > @@ -290,19 +290,23 @@ eth_null_rx(void *queue __rte_unused, > #define NSEC_PER_SEC 1000000000L > > static inline void > -calculate_timestamp(struct timeval *ts) { > - uint64_t cycles; > - struct timeval cur_time; > +calculate_timestamp(const struct rte_mbuf *mbuf, struct timeval *ts) { > + if (mbuf->ol_flags & PKT_RX_TIMESTAMP) { > + ts->tv_sec = mbuf->timestamp / NSEC_PER_SEC; > + ts->tv_usec = mbuf->timestamp % NSEC_PER_SEC; > + } else { > + uint64_t cycles = rte_get_timer_cycles() - start_cycles; > + struct timeval cur_time = { > + .tv_sec = cycles / hz, > + .tv_usec = (cycles % hz) * NSEC_PER_SEC / hz, > + }; > > - cycles = rte_get_timer_cycles() - start_cycles; > - cur_time.tv_sec = cycles / hz; > - cur_time.tv_usec = (cycles % hz) * NSEC_PER_SEC / hz; > - > - ts->tv_sec = start_time.tv_sec + cur_time.tv_sec; > - ts->tv_usec = start_time.tv_usec + cur_time.tv_usec; > - if (ts->tv_usec >= NSEC_PER_SEC) { > - ts->tv_usec -= NSEC_PER_SEC; > - ts->tv_sec += 1; > + ts->tv_sec = start_time.tv_sec + cur_time.tv_sec; > + ts->tv_usec = start_time.tv_usec + cur_time.tv_usec; > + if (ts->tv_usec >= NSEC_PER_SEC) { > + ts->tv_usec -= NSEC_PER_SEC; > + ts->tv_sec += 1; > + } > } > } > 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? 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)