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 4CF47A00C5; Thu, 21 May 2020 17:34:01 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 1B2071D6F7; Thu, 21 May 2020 17:34:01 +0200 (CEST) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) by dpdk.org (Postfix) with ESMTP id B98DA1D6F2 for ; Thu, 21 May 2020 17:33:58 +0200 (CEST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id 8C24AF42; Thu, 21 May 2020 11:33:55 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Thu, 21 May 2020 11:33:55 -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= HPBkR7DycInyGNdjLn9U4krc5dMW/3z85VPYVMzz5V8=; b=YE+jnpigdNPKs/em YhhoU5+hqunghZwmKp4yo/3KvYpelT6H+LNdvIu2oZBp4Da9nmskVO6DWkMm2uFv rbHE4jmKb+RGqthga9GN2yOiLX6DNui1jLL05xzDlJD0B/Xn9O9bX88j90XTsA93 pUqBPz8QFRlwgHzliBkmv+7wcH69tmZaPj2oNtcsR8Ov7whYbiANQ3EWUfUvEGws m5hI+ElGyGjC709lWhmZ4G6OcOZOZE+oElyHyJyD2XFxosJ7+LANlmd0qoRpLpi8 bRziEvB1b9/b5iVodngGzMVTOp3Y8qOp2ikcTT6Uh3RcF1kmaWyNzcHE92YrULop HSDYwg== 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=HPBkR7DycInyGNdjLn9U4krc5dMW/3z85VPYVMzz5 V8=; b=MwaTocdS8Rjt/iJj5nJ+c3Rwgm73WwJOXMAX4243ZNJa3ElZT04Y4//QS pb0i08zEUIBzUgM5VP+88uh0fN5AVeXz2Ai4Aj3QnNEJntWw5rz0PwsO2lYLMbgw aS47EUlvs6zt6mgTl3yvhh2asqgLnsLoVtyDNucEASeGVUSGrtIZhHfJJWXMD5HR BB/bNOZD3JvLLIGZi6Mnn2nfYCbt3IVs88CB/RH37RbJi+nSo5MvUFWoOtTYAWuh IZDFdcMPPENggtmfQwZyAm5nhIsB6mcGoNk05MtSwHo37sjVN3zFj2aoH6j2ZgWp QHqYKUkfP3XJCmKZnpAIv/aeXAIww== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudduuddgkeekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepudeggfdvfeduffdtfeeglefghfeukefgfffhueejtdetuedtjeeu ieeivdffgeehnecukfhppeejjedrudefgedrvddtfedrudekgeenucevlhhushhtvghruf hiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhhomhgrshesmhhonhhjrghl ohhnrdhnvght 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 239503280059; Thu, 21 May 2020 11:33:54 -0400 (EDT) From: Thomas Monjalon To: PATRICK KEROULAS Cc: dev@dpdk.org Date: Thu, 21 May 2020 17:33:50 +0200 Message-ID: <3986292.sUUuQTochr@thomas> In-Reply-To: References: 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" 19/05/2020 20:20, PATRICK KEROULAS: > Hello, > > 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? > 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).