From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by dpdk.org (Postfix) with ESMTP id 266419E3 for ; Fri, 28 Apr 2017 11:12:30 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 9B4462092A; Fri, 28 Apr 2017 05:12:30 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Fri, 28 Apr 2017 05:12:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=k4YtmA4XUxC2Tjh MPyjXO3YAA4gk72DRHL4IIjiQCwo=; b=HpS3B3gAeMbeh78wkf/3gnBdzR+X/17 UjwGR9EnhyN+3Qi0gmwOIgHtmJM6gis0OjGuPIoQNicdFGXWS6LI0GEPu7q4TOq4 goEKhjrqrC1jQzflfqlxNSaguhtyUxXZEzdKUtbK3+OxO5o5t5C2lxL3C0grj2pU vFIxv7AZVt4o= 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-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=k4YtmA4XUxC2TjhMPyjXO3YAA4gk72DRHL4IIjiQCwo=; b=UBJvwW2m TyxtjlmABhBe1/CB5gttMmhAh48TAk/A238jCWQKDVY77agPexaM+e46tLdWB0LL JRDgc/2WYBTGpYNuoQtE7SWObJ5s7j+M/lOSBQwkfR1QdZFhqdm2VKzPBBLGxLEE X+TsCZwEwmRotCdziIZ3ZrTVL9InYpy07R5RMxnp/h3umqFwV96CBjGKzCRI5+0/ q4hw1Jp+J97jFc0xrfStsZ6fM1/jOx87jZRHkLJxveC+QpxEtCROHVrrYRQMPe0G Cj/z4pMd0CYj8etexu/3vIgkmOPGGJrg6M5Fre5n8A9Jy07GUt37btcnbyFuKd04 uLQuPfFgsnYkhQ== X-ME-Sender: X-Sasl-enc: TBwbeQgegk994AlfNsAeXGQcvnf9Ms9WIIvrbrQHde+N 1493370750 Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 4DBA57E21D; Fri, 28 Apr 2017 05:12:30 -0400 (EDT) From: Thomas Monjalon To: "Wu, Jingjing" , Daniel Mrzyglod , Pablo de Lara Cc: dev@dpdk.org, Oleg Kuporosov , olivier.matz@6wind.com Date: Fri, 28 Apr 2017 11:12:29 +0200 Message-ID: <7967304.9Aej4IakVR@xps> In-Reply-To: <9BB6961774997848B5B42BEC655768F810D59753@SHSMSX103.ccr.corp.intel.com> References: <1476369308-17021-1-git-send-email-olegk@mellanox.com> <5493210.cW0TSkhqM8@xps> <9BB6961774997848B5B42BEC655768F810D59753@SHSMSX103.ccr.corp.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH 2/3] app/testpmd: enabled control for packet 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: , X-List-Received-Date: Fri, 28 Apr 2017 09:12:31 -0000 28/04/2017 02:19, Wu, Jingjing: > > 25/04/2017 16:02, Wu, Jingjing: > > > From: Oleg Kuporosov > > > > Implemented two methods of control > > > > > > > > - by --enable-timestamps CL testpmd application we can enable > > timestamping > > > > for all ports; > > > > - in interactive mode port config timestamps on|off is able to > > > > configure timestamping per specific port. > > > > > > > > The control doesn't interact with IEEE1588 PTP implementation there > > > > as it is under macro compilation but can be extended in the future. > > > > > > > > This feature is required for debugging/testing purposes for real > > > > time HW packet timestamping. > > > > > > We have ieee1588fwd.c to demo the timesync enable/disable, can we > > > reuse The fwd engine instead of defining new commands? > > > > Yes for IEEE1588 feature, we should use app/test-pmd/ieee1588fwd.c. > > > > There is more to say about this feature. > > > > The main goal of this patchset was to add a timestamp in the mbuf. > > It has been done by another patchset in 17.05. > > OK. But it is not clear now what is the timestamp for, right? Olivier can comment on the Rx timestamp (PKT_RX_TIMESTAMP). Please Jingjing (or Pablo or Daniel), could you explain the relation with PKT_TX_IEEE1588_TMST? > > Do we know how to test this timestamp in testpmd? > > Mbuf dump can show this value. The problem is if we can use the > rte_eth_timesync_enable/disable to indicate the timestamp > is in mbuf or not. Please could you describe the problem? > > About IEEE1588 feature, why is there a config option? > > CONFIG_RTE_LIBRTE_IEEE1588 > > A feature should never be disabled at compile time. > > There is also a runtime enablement with rte_eth_timesync_enable(). > > > > I think we need some discussions here. > > Yes, I agree. What is your opinion? What prevents from removing CONFIG_RTE_LIBRTE_IEEE1588?