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 97A93A0350; Thu, 25 Jun 2020 13:55:40 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id E4C13E07; Thu, 25 Jun 2020 13:55:39 +0200 (CEST) Received: from mail-wm1-f67.google.com (mail-wm1-f67.google.com [209.85.128.67]) by dpdk.org (Postfix) with ESMTP id 606191D6D5 for ; Wed, 24 Jun 2020 00:10:21 +0200 (CEST) Received: by mail-wm1-f67.google.com with SMTP id f139so332069wmf.5 for ; Tue, 23 Jun 2020 15:10:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zzwAWYxOHqK7yvOIAJ7ZZfplXBJzvCp5NBT4T+7kYiM=; b=hhg0KhDWa3vNcraRZuBW5vU8+5FpdZO/zyN+TRdsH5JNSTXWv0JIyFQ0cCo+RjvvZ4 67GadWHBjkVMVjbGfqa+MVjwppDXvAC+O7ZfWD784lnpq6ghzUPJQZ28S0vk1Yb/gNdS +BN00YQClDD/q6skRDn9nlDbY2zrziCLN66JeLzoVRUtX2Sb5lMeiXBzyZEuX1V9026d EAxjQooCCF0EC7/uByxUUIVL/s+GrUwt1tAsIZQ/pK71g99ydIQsnuEPiajEi6Prr/6s wQx+JkH3hAaZS/a5Fa9FsJ8RIve2gY/f8R927SBCryK1QvBgWFDBKMc+Vh4cIHF1Zjk4 B2pg== 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=zzwAWYxOHqK7yvOIAJ7ZZfplXBJzvCp5NBT4T+7kYiM=; b=hJRRHsUluRMVHRSgC+xn+hWHOtAr2xL9cchvc7tuvKypzYhXr3Q0qLz8CFRiOoTZoP MWq1bij9jDQPTWxXSULv3MhkuCEXN5GlOBa9gBB4NflisX5MkVv/IBNviasZHcdg0TL3 aayzp5ktPJWi0mMOLBaQjVOFWoe26BTwlvvr7EV0no+kLPOhqxqHyFmWu1G5tCx1gWh5 qOU7roWb4Q++xSfCDmYu+RvQZOQPBZfPiWQ5jJF7zy5WuZyUUMR71E7/MPll87Iaqmjj 1iIgiQSDIuRHjzD7CxOW+6EmIe2H2LWnzPnhp9kAje80Q3uKuyvBS9TNLhJ/lxbboOA+ eumQ== X-Gm-Message-State: AOAM530bIS5JZExErQ850AjF5GFc5XLqlfrB/6mL1brd4UjzpX5iOBGa YIB/dkN60cC20LAAOWFNPjmbfMIwWHXmgJ3TkGw= X-Google-Smtp-Source: ABdhPJzsq6wnESSZa2e8V6KCMNDV/WC/v8wWU6u8sgoXFa++WX4IO+oWVpUQr8f9I6UHjnf1imhRxmUfQXMVkMp/B50= X-Received: by 2002:a1c:2146:: with SMTP id h67mr24201673wmh.46.1592950221118; Tue, 23 Jun 2020 15:10:21 -0700 (PDT) MIME-Version: 1.0 References: <20200610193938.218768-1-vivien.didelot@gmail.com> <5991f5d8-5d7f-4caf-733c-a5d29110a046@intel.com> In-Reply-To: <5991f5d8-5d7f-4caf-733c-a5d29110a046@intel.com> From: Vivien Didelot Date: Tue, 23 Jun 2020 18:10:09 -0400 Message-ID: To: Ferruh Yigit Cc: dev@dpdk.org, PATRICK KEROULAS , Olivier MATZ X-Mailman-Approved-At: Thu, 25 Jun 2020 13:55:38 +0200 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] [PATCH] 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 Oliver, Surprisingly, dumping PCAP with hardware timestamps seems to be a niche, but we do need this feature for our network analyzing tool. Do you guys have objections for this patch? Regards, Vivien On Wed, Jun 17, 2020 at 4:16 AM Ferruh Yigit wrote: > On 6/10/2020 8:39 PM, 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 7a67c960c..cedceaf9d 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; > > Hi Vivien, > > No objection from pcap PMD point of view. > > But should we have a Tx mbuf flag, 'PKT_TX_TIMESTAMP', for applications to > request drivers to use the timestamp field on Tx path? Not sure if there > can be > any problem on using Rx flag on both direction? > > Also the metric is not defined for the 'mbuf->timestamp', it doesn't need > to be > nanoseconds, not sure if it is correct to assume it is. Or should we > define a > metric for timestamp on the Tx path? > > cc'ed Oliver, I think he can comment better on above two questions. > > Thanks, > ferruh > >