From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id D04CF2BB9 for ; Tue, 17 Jan 2017 15:53:59 +0100 (CET) Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga101.jf.intel.com with ESMTP; 17 Jan 2017 06:53:58 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,245,1477983600"; d="scan'208";a="923516370" Received: from irsmsx105.ger.corp.intel.com ([163.33.3.28]) by orsmga003.jf.intel.com with ESMTP; 17 Jan 2017 06:53:57 -0800 Received: from irsmsx103.ger.corp.intel.com ([169.254.3.77]) by irsmsx105.ger.corp.intel.com ([169.254.7.38]) with mapi id 14.03.0248.002; Tue, 17 Jan 2017 14:53:56 +0000 From: "Mcnamara, John" To: Jerin Jacob CC: "Horton, Remy" , "dev@dpdk.org" , "Pattan, Reshma" , Thomas Monjalon , "olivier.matz@6wind.com" , "Richardson, Bruce" Thread-Topic: [dpdk-dev] [PATCH v7 5/6] lib: added new library for latency stats Thread-Index: AQHScBSHpoacQ3W5Mky5piO2SUYXrqE8FHOAgABvRXCAABgqgIAAEPmA Date: Tue, 17 Jan 2017 14:53:55 +0000 Message-ID: References: <1484583573-30163-1-git-send-email-remy.horton@intel.com> <1484583573-30163-6-git-send-email-remy.horton@intel.com> <20170117042935.GA32676@localhost.localdomain> <20170117123418.GA2611@localhost.localdomain> In-Reply-To: <20170117123418.GA2611@localhost.localdomain> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ctpclassification: CTP_IC x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiYWNjZjQyYzUtYWVlYi00Y2RkLWE2NmYtNTk2NmE5YmNhMWYxIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6Ik15bk9oN1duSFUrSER5M25zYkMwVkU2ZEE0NmpPOGJFVnlPOEZCZUFmNTQ9In0= x-originating-ip: [163.33.239.181] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH v7 5/6] lib: added new library for latency stats 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, 17 Jan 2017 14:54:00 -0000 > -----Original Message----- > From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com] > Sent: Tuesday, January 17, 2017 12:34 PM > To: Mcnamara, John > Cc: Horton, Remy ; dev@dpdk.org; Pattan, Reshma > ; Thomas Monjalon ; > olivier.matz@6wind.com > Subject: Re: [dpdk-dev] [PATCH v7 5/6] lib: added new library for latency > stats >=20 > On Tue, Jan 17, 2017 at 11:19:24AM +0000, Mcnamara, John wrote: > > > -----Original Message----- > > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Jerin Jacob > > > Sent: Tuesday, January 17, 2017 4:30 AM > > > To: Horton, Remy > > > Cc: dev@dpdk.org; Pattan, Reshma ; Thomas > > > Monjalon > > > Subject: Re: [dpdk-dev] [PATCH v7 5/6] lib: added new library for > > > latency stats > > > > > > On Mon, Jan 16, 2017 at 04:19:32PM +0000, Remy Horton wrote: > > > > From: Reshma Pattan > > > > > > > > Add a library designed to calculate latency statistics and report > > > > them to the application when queried. The library measures > > > > minimum, average and maximum latencies, and jitter in nano > > > > seconds. The current implementation supports global latency stats, > > > > i.e. per application > > > stats. > > > > > > > > Signed-off-by: Reshma Pattan > > > > Signed-off-by: Remy Horton > > > > --- > > > > MAINTAINERS | 4 + > > > > config/common_base | 5 + > > > > doc/api/doxy-api-index.md | 1 + > > > > doc/api/doxy-api.conf | 1 + > > > > doc/guides/rel_notes/release_17_02.rst | 5 + > > > > lib/Makefile | 1 + > > > > lib/librte_latencystats/Makefile | 57 +++ > > > > lib/librte_latencystats/rte_latencystats.c | 389 > > > +++++++++++++++++++++ > > > > lib/librte_latencystats/rte_latencystats.h | 146 ++++++++ > > > > .../rte_latencystats_version.map | 10 + > > > > lib/librte_mbuf/rte_mbuf.h | 3 + > > > > > > It is a value added feature for DPDK. But what is the plan for > > > incorporating the mbuf change? I have 8 month old mbuf change for > > > ARM for natural alignment. If we are accepting any mbuf change then > > > we need to include outstanding mbuf changes to avoid future ABI > breakage. > > > > > > http://dpdk.org/dev/patchwork/patch/12878/ > > > > > > > Hi Jerin, >=20 > Hi John, >=20 > > > > As far as I know the plan was to reach some sort of consensus on the > > mbuf structure at the DPDK Userspace 2016, during and after Olivier's > > presentation and then to make those changes during 17.02. > > > > However, I believe Olivier had other work commitments in this release > > and wasn't able to work on the mbuf changes. > > > > The above mbuf change (and addition at the end of the struct) should > > have gone into that mbuf rework, along with your changes. > > > > However, since the mbuf rework didn't happen we need to add the field > > in this release. >=20 > So we don't care the mbuf ABI breakage in the next release. This wasn't > the message I got earlier for ARM's mbuf change. >=20 > http://dpdk.org/dev/patchwork/patch/12878/ Hi Jerin, We do care about ABI breakage but I was under the impression that the timestamp change wasn't breaking the ABI since it was at the end of the struct. I also ran the ABI validator against the change and it didn't show = any breakage. http://dpdk.org/doc/guides/contributing/versioning.html#running-the-abi-val= idator The rearm_data alignment patch, on the other hand, does break ABI. I think that is the main difference between the two patches. If the timestamp change does break ABI then it should also wait until the m= buf restructuring. > ... >=20 > There is nothing against you or this feature. The only part concerns me > that some set of patches can always override any rule and include in the > release (even as marking as EXPERIMENTAL) because of its important for > some set of consumers. > Another set has to wait in the queue because its not important for some > people. > For me, it is not a sign of vendor neutral open source project. To be fair I don't think we are trying to override any rule here.=20 Also, we aren't the only vendor looking for a timestamp in the mbuf. Mellanox also submitted a patch: http://dpdk.org/ml/archives/dev/2016-October/048809.html However, it is also fair to acknowledge that the rearm_data alignment patch shouldn't have had to wait so long. I can't really answer for that directly= . My feeling is that it was targeted for the mbuf rework but got forgotten when that work slipped. John