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 C0151A0350; Tue, 30 Jun 2020 09:32:36 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 9FBE01BEA6; Tue, 30 Jun 2020 09:32:29 +0200 (CEST) Received: from mail-qk1-f194.google.com (mail-qk1-f194.google.com [209.85.222.194]) by dpdk.org (Postfix) with ESMTP id 73A053B5 for ; Thu, 25 Jun 2020 20:49:39 +0200 (CEST) Received: by mail-qk1-f194.google.com with SMTP id c30so2548299qka.10 for ; Thu, 25 Jun 2020 11:49:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:message-id:from:to:cc:subject:in-reply-to:references :mime-version:content-disposition:content-transfer-encoding; bh=34OlD2HF96MmxD6sc71r7DAiPc4FCDpPSVNsMsuj2cg=; b=VA8qMMn/hPy6Hv2nQeZ+LMxb/m7i+oQfm65EXprMYoLuO1vjQqH2K1Suhwc8Eomq6j it6zDga4Bo8JvvdRM8kFLvswAjfac13vtmHWB/ffza8Ymqw/pnou2I2I7GZYuoY8JkNn HoS0E/AsPSOI+Wb1JqCR7BAkYGzzzS8Zg74IY+P0suUR6dzRSZLj3lPRWtf0ixX5jWd4 nfifRusBb9EGpGLdkgkNRwNdIg9r+7MMiNHQNqPhxxjDEcm5EBmJUDq4oU6QpWmqn+qr L+Z0wbWXwMphRwQYJMWfCdZX70hzNS1VBr6gSvbUjzg6AtNPeslh96x9JRCmxHHj0/zr p7Jg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:message-id:from:to:cc:subject:in-reply-to :references:mime-version:content-disposition :content-transfer-encoding; bh=34OlD2HF96MmxD6sc71r7DAiPc4FCDpPSVNsMsuj2cg=; b=av2f5+WnwVtlQxTisCV4tfsGU0gFru6aVSOjPIqjiqwR7nu5tlmIQr5In2daDqnDP8 7EHaoOK8RAggYY0kYv37i8QpAv5KcOGNLeAs0f/dHZkE1s1DO5VBeW4I0640bHMRGkp5 tC5Ro73ZOslO4GOwEFC11Aum/mJ+Ys/8mx/yPj6jmV/ZWMUvTwn6MuO/6O36JrnsVBme W1+0s1Tq7lcNhfxuKxllJbOPb5GxJdKvBVROt+uEa/hsr6sTK8z+dfbdVETMWQhMtUNy LjvMb3VUeyoPb+tNpsitoM0UaOfNp0rHk4jPFk6IvrepHoPzywHplQce4GQwh06TeEG+ 6mpg== X-Gm-Message-State: AOAM5314U0G3oSuUf6wiHHrrWTfqfPiA80KlvYSqrNHC2Zxz90tEWl0M xH2NmHPCbL80uldKh8uNKyM+S/95 X-Google-Smtp-Source: ABdhPJw2dhHYS3QhnsdUVeUQ7cCm6qG5monmBkJwJ3BVHSOAn96Syfpk2hNa9Muj9ykC/PrtsjJ9NA== X-Received: by 2002:a37:d207:: with SMTP id f7mr30125318qkj.139.1593110978751; Thu, 25 Jun 2020 11:49:38 -0700 (PDT) Received: from localhost (modemcable249.105-163-184.mc.videotron.ca. [184.163.105.249]) by smtp.gmail.com with ESMTPSA id n36sm7626642qtc.35.2020.06.25.11.49.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 25 Jun 2020 11:49:37 -0700 (PDT) Date: Thu, 25 Jun 2020 14:49:37 -0400 Message-ID: <20200625144937.GB260035@t480s.localdomain> From: Vivien Didelot To: Olivier Matz Cc: Ferruh Yigit , dev@dpdk.org, PATRICK KEROULAS In-Reply-To: <20200625163532.GU12564@platinum> References: <20200610193938.218768-1-vivien.didelot@gmail.com> <5991f5d8-5d7f-4caf-733c-a5d29110a046@intel.com> <20200625163532.GU12564@platinum> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Tue, 30 Jun 2020 09:32:26 +0200 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 Olivier, On Thu, 25 Jun 2020 18:35:32 +0200, Olivier Matz wrote: > As said by Ferruh, the unit of timestamp in mbuf is not normalized to > nanosecs, as seen in rte_mbuf_core.h: > > /** Valid if PKT_RX_TIMESTAMP is set. The unit and time reference > * are not normalized but are always the same for a given port. > * Some devices allow to query rte_eth_read_clock that will return the > * current device timestamp. > */ > uint64_t timestamp; > > Using the timestamp generated from a port which is not a pmd-pcap would > require a conversion, using rte_eth_read_clock() on mbuf->port (assuming > it was not modified, which should be true except if event eth Tx adapter > is used). > > Also, note that the timestamp corresponds to the Rx timestamp. I think it > could be an issue in case the mbuf is reassembled by the application: the > timestamp in reassembled mbuf would be the one from the first fragment. > > So, I share Ferruh's concerns. I think this is not totally true depending on the driver. For instance, we use mlx5 which already provides a timestamp conversion to nanosecs through libibverbs. Let me resend this patch alongside Patrick's mlx5 patches that implemented the needed glue, so that you may understand better the big picture of how we enabled hardware timestamping in PCAP capture using mlx5 and pdump. Regards, Vivien