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 9E226271 for ; Fri, 21 Sep 2018 03:58:12 +0200 (CEST) X-IronPort-AV: E=Sophos;i="5.54,282,1534784400"; d="scan'208";a="94559010" Received: from 125.235.240.45.adsl.viettel.vn (HELO mta2.viettel.com.vn) ([125.235.240.45]) by mailfilter01.viettel.com.vn with ESMTP; 21 Sep 2018 08:58:10 +0700 Received: from localhost (localhost [127.0.0.1]) by mta2.viettel.com.vn (Postfix) with ESMTP id 5CE3C68CE7B; Fri, 21 Sep 2018 08:58:08 +0700 (ICT) Received: from mta2.viettel.com.vn ([127.0.0.1]) by localhost (mta2.viettel.com.vn [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id l5DoNYcBinkQ; Fri, 21 Sep 2018 08:58:08 +0700 (ICT) Received: from localhost (localhost [127.0.0.1]) by mta2.viettel.com.vn (Postfix) with ESMTP id C7C9F68CE5E; Fri, 21 Sep 2018 08:58:04 +0700 (ICT) X-Virus-Scanned: amavisd-new at Received: from mta2.viettel.com.vn ([127.0.0.1]) by localhost (mta2.viettel.com.vn [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id x-FBIwN5zUFQ; Fri, 21 Sep 2018 08:58:04 +0700 (ICT) Received: from ANMLONGTB5 (unknown [27.68.241.28]) by mta2.viettel.com.vn (Postfix) with ESMTPSA id 4C51368CED4; Fri, 21 Sep 2018 08:58:04 +0700 (ICT) To: Cc: References: <1537345496-70207-1-git-send-email-longtb5@viettel.com.vn> <3AEA2BF9852C6F48A459DA490692831F2A39B32D@IRSMSX109.ger.corp.intel.com> In-Reply-To: <3AEA2BF9852C6F48A459DA490692831F2A39B32D@IRSMSX109.ger.corp.intel.com> Message-ID: <000001d4514f$9f77ecd0$de67c670$@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: AQHda06JAXJ0Ef8nQkq4Y4qymXcj5wJHQalRpNWEMZA= Content-Language: en-us MilterAction: FORWARD Date: Fri, 21 Sep 2018 08:58:04 +0700 (ICT) From: longtb5@viettel.com.vn Subject: Re: [dpdk-dev] Incorrect latencystats implementation 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, 21 Sep 2018 01:58:13 -0000 Hi Reshma, > -----Original Message----- > From: reshma.pattan@intel.com [mailto:reshma.pattan@intel.com] > Sent: Thursday, September 20, 2018 8:09 PM > To: longtb5@viettel.com.vn > Cc: dev@dpdk.org > Subject: RE: Incorrect latencystats implementation > > > > > -----Original Message----- > > From: longtb5@viettel.com.vn [mailto:longtb5@viettel.com.vn] > > Sent: Wednesday, September 19, 2018 9:17 AM > > To: Pattan, Reshma > > Cc: dev@dpdk.org; Bao-Long Tran > > Subject: Incorrect latencystats implementation > > > > > > I have submit a patch to implement the trivial fix. For the drop case > > I can think of 2 options. We can either clear timestamp when putting > > mbufs back to their pool, or change lib latencystats implementation to > > perform packet selection at TX callback and let RX callback add timestamp > to every packet. > > Both option could affect performance but I think the second option is > > less aggressive. > > What happens when applications drop the packets? Do they free the mbuf? > In such case, can application set the timestamp to 0 before freeing the mbuf, > instead of making these changes in latency library.? > Yes, applications can set the mbuf timestamp before freeing. But in my opinion that would not be a clean solution. Applications should not have to worry about the timestamp field at all, since that is an implementation detail of the library. For simple apps, wrapping rte_pktmbuf_free() to perform timestamp reset could be done without much hassle, but that kind of ad-hoc solution would become messy for more complex ones where packets are dropped at different places. From a usability point of view, as an user I want the lib to provide latency measurements without me having to touch existing codebase other than adding codes that use the APIs. > Regards, > Reshma Thanks and regards, BL