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 3F089A04A2; Wed, 3 Jun 2020 23:59:16 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id B90431D592; Wed, 3 Jun 2020 23:59:15 +0200 (CEST) Received: from mail-pj1-f65.google.com (mail-pj1-f65.google.com [209.85.216.65]) by dpdk.org (Postfix) with ESMTP id 323E11D585 for ; Wed, 3 Jun 2020 23:59:14 +0200 (CEST) Received: by mail-pj1-f65.google.com with SMTP id nm22so177848pjb.4 for ; Wed, 03 Jun 2020 14:59:14 -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=VOIMrNzv6C+G2WIhxkkx1y1ToFj+m8R0qyDDld/yDa0=; b=u6QUyJWueGYBCBxVtoHfwpHDOS2QBcJfdzqI0Mbvn3ai/IF2rTYXKdbFnIESyk16Mo wUX2NX+KEdRx7213JCyo+S+jwEFZalpIvsV383CGzgAYgOXIe5iOJRBuXH0JllmiiaLH 3Jdi9B1uOaBA3yej3Qr6Tb2uwIEYBVkK/RmFlZw8ny4iMWXg4oftyG83pd8q0S/EXyue j7xGgNh/wBBoyUBKoA+zBQAh4wGzx4CNXEqUhjNpuJMoMuBuLkqB8bZCLkKSUM7C+qbi pKN93p4oRC6qgKuqrYJsOyyQoYwV+17Y9VmvqdSSGWLf7QtDRilC6f+Av6UuIoSGKE8j XpBg== 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=VOIMrNzv6C+G2WIhxkkx1y1ToFj+m8R0qyDDld/yDa0=; b=KIQrjB9BHe2Q+Ce3A9QXWctale7yYFQNMAaiQR4ibFm/NGrfxTTk/z26akaD7yjSTe N+BRd61cEalEiC0bxR51APIbsczGhi5VZNyqMpbvBrIV2wTYS9Kpi2EJPaMDtacjgBPL 5oExUSjWR9mTCvi/Y+fnoeIj2xxtAQErpCV96KUJ2gGcizBn2Lwqgy9IjCBnHIxf3aPo KACyvTZIy39B/Bd9h7vZxc1UmMydgIjAfEe7GQBGxBz1nvQRHTwA1Sehtq+2FKBSd5a+ KSm98CWoIcnVjECc32uxsg0YLPskso9yoB139SWD4eVNfQSL8M36kG8LcYZKw2XnD+YL Vp4Q== X-Gm-Message-State: AOAM532PsTEWtcEULn/mTIXID46MPpV+bKHcTSuJQg4JMB/ZzFCm6Hg6 yN+W0EWoBSDjRDbgZ+A2+o12vg== X-Google-Smtp-Source: ABdhPJxYBTu3TBGwuVHXGcGrfA54A+MG+5gIiMmv+ClQxZbQiY6GKC/vOUhLSGgPurtJsaoTi0ns+w== X-Received: by 2002:a17:902:7588:: with SMTP id j8mr1800583pll.43.1591221553169; Wed, 03 Jun 2020 14:59:13 -0700 (PDT) Received: from hermes.lan (204-195-22-127.wavecable.com. [204.195.22.127]) by smtp.gmail.com with ESMTPSA id 191sm2781640pfy.161.2020.06.03.14.59.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 03 Jun 2020 14:59:12 -0700 (PDT) Date: Wed, 3 Jun 2020 14:59:04 -0700 From: Stephen Hemminger To: Vivien Didelot Cc: Ferruh Yigit , dev@dpdk.org, patrick.keroulas@radio-canada.ca, thomas@monjalon.net Message-ID: <20200603145904.0dc34319@hermes.lan> In-Reply-To: <20200603162652.GB13716@t480s.localdomain> References: <20200523172130.2285380-1-vivien.didelot@gmail.com> <1d7b6c2e-84a9-5e20-1353-4f64de667b03@intel.com> <20200603131139.6f79ecc7@hermes.lan> <20200603162652.GB13716@t480s.localdomain> 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 Wed, 3 Jun 2020 16:26:52 -0400 Vivien Didelot wrote: > On Wed, 3 Jun 2020 13:11:39 -0700, Stephen Hemminger wrote: > > On Wed, 3 Jun 2020 18:50:51 +0100 > > Ferruh Yigit wrote: > > > > > On 5/23/2020 6:21 PM, 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). > > > > > > Overall good idea and patch looks good. > > > > > > Only concern is change in the libpcap dependency. Do you know which libpcap > > > version supports 'PCAP_TSTAMP_PRECISION_NANO'? > > > If a user of pcap PMD updates to latest DPDK and the environment doesn't have > > > new version of the libpcap, this change will require an environment update and > > > this may or may not be easy to do. That is why not sure if the updates require > > > dependency change should wait for the LTS or not. > > > > > > Another things is the backward compatibility, as far as I understand the pcap > > > file recorded with nanosecond precision can be read and parsed without problem > > > by old application that doesn't know the nanosecond precision, but can you > > > please confirm this? > > > > We should do pcapng instead of doing the pcap with nano timestamp. > > My impression is that libpcap is a dormant project at this point, and the > > finer grain timestamp is a hack that is only in some verisions. > > That was one of the reasons pcapng started. > > Reading tv_usec as nanoseconds has been supported for years in libpcap. > > For instance PCAP_TSTAMP_PRECISION_NANO was introduced in ba89e4a18e8b > ("Make timestamps precision configurable") on May 17, 2013. > > BTW, I have no clue what you mean by "floating point math". It was a concern that 1e9 constant in C is interpreted as floating point. But probably a non-issue. Have gotten burned in the past by floating point creeping into DPDK (in Qos code).