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 C353AA04A5; Sun, 24 May 2020 03:39:55 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 96AA11D62C; Sun, 24 May 2020 03:39:55 +0200 (CEST) Received: from mail-pl1-f194.google.com (mail-pl1-f194.google.com [209.85.214.194]) by dpdk.org (Postfix) with ESMTP id 4AF211D628 for ; Sun, 24 May 2020 03:39:54 +0200 (CEST) Received: by mail-pl1-f194.google.com with SMTP id x10so5985665plr.4 for ; Sat, 23 May 2020 18:39:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=nN6MHrOzm6FmaTgN/VUb30tCUMUAyOp+ddlVoqXZCoE=; b=Vu3cjoRH5J20D7Osm7C6v+myv5iDKUusPsJF3UMZRHAqcyLafAwIS2BHxIsADXeluz zrkwfw1RW4Sux0piGP9iMrHqjfSNxrEREC2Hr2mbV64IVoZ+zeUAOyHkyT9suCtfCbVb d6LHJYxoLn3G06Kl5pfycq7D4lr/QEU+B38vigHgBlSrUMlI50l0guDNrxP1Oo9UvzTa jyrsAnypA4ZDiGhZHh5rwX7zadgd7O3DIypm5yhCr7spkHgVVAvZtQF2YOAfQd7Y+D38 NLLyj7+qY+Rw+jKMNw4XoiY3menNQZbavDsnbJysaq2aZ6wFyvB1w47MC40YxiVgU7fy 1DqA== 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:in-reply-to :references:mime-version:content-transfer-encoding; bh=nN6MHrOzm6FmaTgN/VUb30tCUMUAyOp+ddlVoqXZCoE=; b=rNkiEx92UUrWRU9D6XHmasQB/LMoma48xuTirV5sF3mRg65h1c8jGabltJ1mTZIgMf iLSlOCi2xYTqQrU+D/SPlOCqJq7osZGq3I4oLTh3Zmrms79O9EBGSi0ify4M6Rs5vNZL H+bTPrJYVnXZDPna+wl6oymv4F0p6B4t2wRXvF4gmXBFeqFgzQDxN7QnkS34vjMpM4uX qcX+w0HYoz8UvaRhKkJ6/spyckSr8CuOZaOXyKstK2JC4vfaZ+KWHa5dZYoEr3oYsbNu NqSxgDtJaMYlj+747Zkji9vqZyv4vOK7l30mpVKklHPjVTCv0Liaj8RZd5HRvoUr+a+2 axnQ== X-Gm-Message-State: AOAM532XQTm8GSQRqlSS3wfKoDHMOzHrn6gXeUjlmQrkO0OAWDqhoziA 27Vf0S6WIwGAgsp+DGAtAaBx4w== X-Google-Smtp-Source: ABdhPJxTwLnaeGLKLJEWHPrK+fmdevjkvLI70eS4XrZRqS8Td6a0linLQ04u7BYosdjIo9Zt3R3hFw== X-Received: by 2002:a17:90b:41d5:: with SMTP id jm21mr12143253pjb.96.1590284393431; Sat, 23 May 2020 18:39:53 -0700 (PDT) Received: from hermes.lan (204-195-22-127.wavecable.com. [204.195.22.127]) by smtp.gmail.com with ESMTPSA id x190sm9039996pgb.79.2020.05.23.18.39.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 23 May 2020 18:39:52 -0700 (PDT) Date: Sat, 23 May 2020 18:39:50 -0700 From: Stephen Hemminger To: Vivien Didelot Cc: dev@dpdk.org, patrick.keroulas@radio-canada.ca, thomas@monjalon.net Message-ID: <20200523183950.562eb25d@hermes.lan> In-Reply-To: <20200523172130.2285380-1-vivien.didelot@gmail.com> References: <20200523172130.2285380-1-vivien.didelot@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH 1/2] net/pcap: support software Tx nanosecond timestamp 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 Sat, 23 May 2020 13:21:29 -0400 Vivien Didelot wrote: > When capturing packets into a PCAP file, DPDK currently uses > microseconds for the timestamp. But libpcap supports interpreting > tv_usec as nanoseconds depending on the file timestamp precision. > > To support this, use PCAP_TSTAMP_PRECISION_NANO when creating the > empty PCAP file as specified by PCAP_OPEN_DEAD(3PCAP) and implement > nanosecond timeval addition. This also ensures that the precision > reported by capinfos is nanoseconds (9). > > Signed-off-by: Vivien Didelot > --- > drivers/net/pcap/rte_eth_pcap.c | 15 ++++++++++++--- > 1 file changed, 12 insertions(+), 3 deletions(-) > > diff --git a/drivers/net/pcap/rte_eth_pcap.c b/drivers/net/pcap/rte_eth_pcap.c > index b4c79d174..68588c3d7 100644 > --- a/drivers/net/pcap/rte_eth_pcap.c > +++ b/drivers/net/pcap/rte_eth_pcap.c > @@ -287,6 +287,8 @@ eth_null_rx(void *queue __rte_unused, > return 0; > } > > +#define NSEC_PER_SEC 1e9 > + > static inline void > calculate_timestamp(struct timeval *ts) { > uint64_t cycles; > @@ -294,8 +296,14 @@ calculate_timestamp(struct timeval *ts) { > > cycles = rte_get_timer_cycles() - start_cycles; > cur_time.tv_sec = cycles / hz; > - cur_time.tv_usec = (cycles % hz) * 1e6 / hz; > - timeradd(&start_time, &cur_time, ts); > + 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; > + } Please no floating point math in the fast path of capturing packets!