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 64D80A0093; Thu, 21 May 2020 22:10:01 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id C36A01D723; Thu, 21 May 2020 22:10:00 +0200 (CEST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by dpdk.org (Postfix) with ESMTP id 253E61D708 for ; Thu, 21 May 2020 22:09:59 +0200 (CEST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 8C3945C0150; Thu, 21 May 2020 16:09:58 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Thu, 21 May 2020 16:09:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=fm1; bh= Tf9WHMKVWNM7NnK3CZ9VPw009bcDCu+EDHhlcrGi9WE=; b=B5hYClrDKH0zYJXr 1WUquG/E2oNP79t1BpZWU94GXIJYOYb1Ry1IM7faOup0D2ttqbXwxU0jgLmVnvMu zxlP5ttX8MHIYB3JIfTOIRx36LN+BnghJ7LMDf29egtbvmCnb61aKJpfhtFNntIX QOLGEmcZntM8NdJcbgkDT2m8GtmYBFUkPZK6AlKU7V8AMM8W3Zm4UK4O+fuhUYHz /ObdZrHHiqNVZtk5fPoE8xInV3aHvB37Rwe7t41XaMzNdwHiWfE0+gcxWb4+QGBZ XhkW068u9ce7zdSZx282Z7ODHr+iPtmdm/eDddtHTttwMo1K8NiYJXxVO2MsW4ak RdKroA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=Tf9WHMKVWNM7NnK3CZ9VPw009bcDCu+EDHhlcrGi9 WE=; b=Skw9dsiMXeRx/0El7KhQ0EeOOnio1FudpUA1ECwW2w2RmC/Prmfal8LWr c2b7jxETKcxLCRhq2ZkljUQUS1byUBCvE2vkKtzfLwk9/YKwJ1b4PolwAotpSrLj MyyKfi8i2fOUqg7depMpRw9OZJCIAu0tyP3r0h9rFr9k/A+2j7A1lChscEztErDZ LvMPMkDE3Xm8OocC/VpnsRTrjU8GmOdux64M/HgqZUQvjG2OtOqQsD5IEwaqh73J D7m4b+N5/IbKJICaNAECWHJoRfXlSOSCAPtH6T0Ilj+c1ZUbUVyUAgPrVxhCAMKq AuUzSTbitQCyxbGIzUMgEAIROzWbQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudduuddgudefiecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpeegjeffhffhgefhteevffegffetleevkefhgffhfeegvdelueev teffgfduleevhfenucffohhmrghinhepghhithhhuhgsrdgtohhmnecukfhppeejjedrud efgedrvddtfedrudekgeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgr ihhlfhhrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 752F8328005D; Thu, 21 May 2020 16:09:57 -0400 (EDT) From: Thomas Monjalon To: PATRICK KEROULAS Cc: dev@dpdk.org, Vivien Didelot , shahafs@mellanox.com, rasland@mellanox.com, matan@mellanox.com Date: Thu, 21 May 2020 22:09:53 +0200 Message-ID: <2766519.SlWGiteSXv@thomas> In-Reply-To: References: <3986292.sUUuQTochr@thomas> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] mlx5 & pdump: convert HW timestamps to nanoseconds 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" 21/05/2020 21:57, PATRICK KEROULAS: > > > I'm trying to build an accurate capture device based on Mellanox > > > Connect-X5 with following requirements: > > > - capture every incoming packets with hardware timestamps > > > - output: pcap with timestamps in nanoseconds > > > My problem is that the packets forwarded to `dpdk-pdump` carry raw > > > timestamps from NIC clock. > > > > Please could you describe how you use dpdk-pdump? > > Is it using the mlx5 PMD or pcap PMD? > > We're actually using both: > # Rx, receive from NIC > CONFIG_RTE_LIBRTE_MLX5_PMD=y > # Tx, output to pcap file > CONFIG_RTE_LIBRTE_PMD_PCAP=y > > $ sudo ./build/app/testpmd -w 0000:01:00.0 -w 0000:01:00.1 -n4 -- > --enable-rx-timestamp > $ dpdk-pdump -- --pdump 'port=0,queue=*,rx-dev=capture.pcap' OK thanks > We've sent this placeholder with the intention to start the discussion. > https://github.com/DPDK/dpdk/commit/bd371e1ba5bfc5b7092d712a01bbc28799fd58bc.patch > https://github.com/DPDK/dpdk/commit/e6f5c731c4ab27ab80b229af98c9b3d257e13843.patch We don't use GitHub. It is just a mirror. Thanks for having started the discussion in the mailing list, it is more efficient :) > > > mlx5 part of libibverbs includes a ts-to-ns converter which takes the > > > instantaneous clock info. It's unused in dpdk so far. I've tested it in the > > > device/port init routine and the result looks reliable. Since this approach > > > looks very simple, compared to the time sync mechanism, I'm trying to > > > integrate. > > > > > > The conversion should occur in the primary process (testpmd) I suppose. > > > 1) The needed clock info derives from ethernet device. Is it possible to > > > access that struct from a rx callback? > > > 2) how to attach the nanosecond to mbuf so that `pdump` catches it? > > > (workaround: copy `mbuf->udata64` in forwarded packets.) > > > 3) any other idea? > > > > The timestamp is carried in mbuf. > > Then the conversion must be done by the ethdev caller (application or > > any other upper layer). > > What if the converter function needs a clock_info? > https://github.com/linux-rdma/rdma-core/blob/7af01c79e00555207dee6132d72e7bfc1bb5485e/providers/mlx5/mlx5dv.h#L1201 > I'm affraid this info may change by the time the converter is called > by upper layer. Indeed, the clock in the device is not an atomic one :) We need to adjust the time conversion continuously. I am not an expert of time synchronization, so I add more people Cc who could help for having a precise timestamp.