From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailfilter03.viettel.com.vn (mailfilter03.viettel.com.vn [125.235.240.55]) by dpdk.org (Postfix) with ESMTP id E95DC5F2E; Thu, 20 Sep 2018 14:16:19 +0200 (CEST) X-IronPort-AV: E=Sophos;i="5.53,398,1531760400"; d="scan'208";a="94898046" Received: from 125.235.240.44.adsl.viettel.vn (HELO mta1.viettel.com.vn) ([125.235.240.44]) by mailfilter03.viettel.com.vn with ESMTP; 20 Sep 2018 19:16:18 +0700 Received: from localhost (localhost [127.0.0.1]) by mta1.viettel.com.vn (Postfix) with ESMTP id 1077860F2FD; Thu, 20 Sep 2018 19:16:06 +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 2S6-5b2yKUhb; Thu, 20 Sep 2018 19:16:05 +0700 (ICT) Received: from localhost (localhost [127.0.0.1]) by mta1.viettel.com.vn (Postfix) with ESMTP id E06CD60F379; Thu, 20 Sep 2018 19:16:05 +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 NbDBMcnWqOVq; Thu, 20 Sep 2018 19:16:05 +0700 (ICT) Received: from ANMLONGTB5 (unknown [27.68.241.28]) by mta1.viettel.com.vn (Postfix) with ESMTPSA id 9781B60F2FD; Thu, 20 Sep 2018 19:16:05 +0700 (ICT) To: Cc: , References: <1537345496-70207-1-git-send-email-longtb5@viettel.com.vn> <1537345834-70456-1-git-send-email-longtb5@viettel.com.vn> <3AEA2BF9852C6F48A459DA490692831F2A39B0A6@IRSMSX109.ger.corp.intel.com> In-Reply-To: <3AEA2BF9852C6F48A459DA490692831F2A39B0A6@IRSMSX109.ger.corp.intel.com> Message-ID: <000101d450dc$caf26f20$60d74d60$@viettel.com.vn> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHda06JAXJ0Ef8nQkq4Y4qymXcj5wGmx81UAYGHKKWkzaBpwA== Content-Language: en-us MilterAction: FORWARD Date: Thu, 20 Sep 2018 19:16:05 +0700 (ICT) From: longtb5@viettel.com.vn Subject: Re: [dpdk-dev] [PATCH] latency: clear mbuf timestamp after 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: Thu, 20 Sep 2018 12:16:20 -0000 Hi, Thanks, I have sent a v2. Any comment on the problem of dropped mbuf that I described in the cover letter? In our application the max_latency_ns metric is useless since after running for a while it would always take on obviously incorrect value (up to a few minutes). I suspect the impact on avg_latency_ns is much less severe but significant nonetheless. > -----Original Message----- > From: reshma.pattan@intel.com [mailto:reshma.pattan@intel.com] > Sent: Thursday, September 20, 2018 5:25 PM > To: longtb5@viettel.com.vn > Cc: dev@dpdk.org; stable@dpdk.org > Subject: RE: [PATCH] latency: clear mbuf timestamp after latency calculation > > Hi, > > > -----Original Message----- > > From: longtb5@viettel.com.vn [mailto:longtb5@viettel.com.vn] > > Sent: Wednesday, September 19, 2018 9:23 AM > > To: Pattan, Reshma > > Cc: dev@dpdk.org; Bao-Long Tran ; > > stable@dpdk.org > > Subject: [PATCH] latency: clear mbuf timestamp after latency > > calculation > > > > The timestamp of a mbuf should be cleared after that mbuf was used for > > latency calculation, otherwise future packets which reuse the same > > mbuf would inherit that previous timestamp. The latencystats library > > looks for mbuf with non-zero timestamp, thus incorrectly inherited > > value would result in incorrect latency measurement. > > > > Cc: stable@dpdk.org > > > > Signed-off-by: Bao-Long Tran > > You need to add the Fixes line just before CC: in the commit message. > > Original commit that introduced the bug was 5cd3cac9ed. So fixes should be > added like below > Fixes: 5cd3cac9ed ("latency: added new library for latency stats"). > > You can send v2 with fixes line and my ack. Other than that > > Acked-by: Reshma Pattan