From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailfilter01.viettel.com.vn (mailfilter01.viettel.com.vn [125.235.240.53]) by dpdk.org (Postfix) with ESMTP id E531D1B108 for ; Tue, 25 Sep 2018 17:22:51 +0200 (CEST) X-IronPort-AV: E=Sophos;i="5.54,302,1534784400"; d="scan'208";a="96098199" Received: from 125.235.240.44.adsl.viettel.vn (HELO mta1.viettel.com.vn) ([125.235.240.44]) by mailfilter01.viettel.com.vn with ESMTP; 25 Sep 2018 22:22:49 +0700 Received: from localhost (localhost [127.0.0.1]) by mta1.viettel.com.vn (Postfix) with ESMTP id 2ABA9612805; Tue, 25 Sep 2018 22:22:37 +0700 (ICT) Received: from mta1.viettel.com.vn ([127.0.0.1]) by localhost (mta1.viettel.com.vn [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id gXeGUjLi50et; Tue, 25 Sep 2018 22:22:37 +0700 (ICT) Received: from localhost (localhost [127.0.0.1]) by mta1.viettel.com.vn (Postfix) with ESMTP id 04DB0612807; Tue, 25 Sep 2018 22:22:37 +0700 (ICT) X-Virus-Scanned: amavisd-new at Received: from mta1.viettel.com.vn ([127.0.0.1]) by localhost (mta1.viettel.com.vn [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Cz1RS2BWxD6W; Tue, 25 Sep 2018 22:22:36 +0700 (ICT) Received: from zimbra.viettel.com.vn (mailbox4.viettel.com.vn [10.30.182.139]) by mta1.viettel.com.vn (Postfix) with ESMTP id 84F0F612805; Tue, 25 Sep 2018 22:22:36 +0700 (ICT) To: reshma pattan Cc: Konstantin Ananyev , dev@dpdk.org Message-ID: <1015925804.3544038.1537888956319.JavaMail.zimbra@viettel.com.vn> In-Reply-To: <3AEA2BF9852C6F48A459DA490692831F2A39E20E@IRSMSX109.ger.corp.intel.com> References: <1537545703-9599-1-git-send-email-reshma.pattan@intel.com> <000201d45221$394a8350$abdf89f0$@viettel.com.vn> <3AEA2BF9852C6F48A459DA490692831F2A39E20E@IRSMSX109.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [14.162.34.65] X-Mailer: Zimbra 8.0.9_GA_6191 (ZimbraWebClient - GC69 (Win)/8.0.9_GA_6191) Thread-Topic: [PATCH] latencystats: fix timestamp marking and latency calculation Thread-Index: AQHUUcR8+BpEkWljakW68pBrFc8fu6T7i/QAgAPeYRCxNnP8Ig== MilterAction: FORWARD Date: Tue, 25 Sep 2018 22:22:37 +0700 (ICT) From: longtb5@viettel.com.vn Subject: Re: [dpdk-dev] [PATCH] latencystats: fix timestamp marking and latency calculation 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: Tue, 25 Sep 2018 15:22:54 -0000 Hi Reshma, I mean in the latencystats document. A few lines about what is taken away by the library (the mbuf timestamp when PKT_RX_TIMESTAMP is set) would be very helpful. Best regards, BL ----- Original Message ----- From: "reshma pattan" To: longtb5@viettel.com.vn Cc: "Konstantin Ananyev" , dev@dpdk.org Sent: Monday, September 24, 2018 8:07:18 PM Subject: RE: [PATCH] latencystats: fix timestamp marking and latency calculation Hi, > -----Original Message----- > From: longtb5@viettel.com.vn [mailto:longtb5@viettel.com.vn] > Sent: Saturday, September 22, 2018 3:58 AM > To: Pattan, Reshma ; Ananyev, Konstantin > ; dev@dpdk.org > Subject: RE: [PATCH] latencystats: fix timestamp marking and latency > calculation > > Hi Reshma, > > > -----Original Message----- > > From: reshma.pattan@intel.com [mailto:reshma.pattan@intel.com] > > Sent: Friday, September 21, 2018 11:02 PM > > To: longtb5@viettel.com.vn; konstantin.ananyev@intel.com; > dev@dpdk.org > > Cc: Reshma Pattan > > Subject: [PATCH] latencystats: fix timestamp marking and latency > calculation > > > > Latency calculation logic is not correct for the case where packets > > gets dropped before TX. As for the dropped packets, the timestamp is > > not cleared, and such packets still gets counted for latency > > calculation in > next > > runs, that will result in inaccurate latency measurement. > > > > So fix this issue as below, > > > > Before setting timestamp in mbuf, check mbuf don't have any prior > > valid time stamp flag set and after marking the timestamp, set mbuf > > flags to indicate timestamp is valid. > > > > Before calculating timestamp check mbuf flags are set to indicate > timestamp > > is valid. > > > > This solution as suggested by Konstantin is great. Not only does it solve the > problem but also now the usage of mbuf->timestamp is not exclusive to > latencystats anymore. The application can make use of timestamp at the > same as latencystats simply by toggling PKT_RX_TIMESTAMP. I think we > should update the doc to include this information. > Do you mean latency stats document? Or Mbuf doc. Thanks, Reshma