From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id 51C7991F8 for ; Sun, 6 Dec 2015 07:17:29 +0100 (CET) Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by orsmga102.jf.intel.com with ESMTP; 05 Dec 2015 22:17:28 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,389,1444719600"; d="scan'208";a="8287718" Received: from irsmsx105.ger.corp.intel.com ([163.33.3.28]) by fmsmga004.fm.intel.com with ESMTP; 05 Dec 2015 22:17:27 -0800 Received: from irsmsx103.ger.corp.intel.com ([169.254.3.13]) by irsmsx105.ger.corp.intel.com ([169.254.7.203]) with mapi id 14.03.0248.002; Sun, 6 Dec 2015 06:17:26 +0000 From: "Betts, Ian" To: Thomas Monjalon , Stephen Hemminger , "Glynn, Michael J" Thread-Topic: [dpdk-dev] [PATCH v8 0/4] examples: add performance-thread Thread-Index: AQHRLn9lrOhOVTIF3UavZvcpaBLUvp67H02AgAAIVICAASAw4IAAZsQAgAAf+ICAABo5AIAAjnkQ Date: Sun, 6 Dec 2015 06:17:25 +0000 Message-ID: <877C1F8553E92F43898365570816082F35C0BF2F@IRSMSX103.ger.corp.intel.com> References: <1449159683-7092-3-git-send-email-ian.betts@intel.com> <6A5E04BECFB4144EAFCF9EAE3B739A5355917E56@IRSMSX106.ger.corp.intel.com> <20151205114729.1ef2f958@xeon-e3> <1613880.omu1JhFkSP@xps13> In-Reply-To: <1613880.omu1JhFkSP@xps13> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-inteldataclassification: CTP_PUBLIC x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsIiwiaWQiOiI1ZGM3ZDJmNC03MzYwLTQ1NzMtOGY4ZC01YjgwMWFkNDAzMWMiLCJwcm9wcyI6W3sibiI6IkludGVsRGF0YUNsYXNzaWZpY2F0aW9uIiwidmFscyI6W3sidmFsdWUiOiJDVFBfUFVCTElDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjQuMTAuMTkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiT0pnYnNaZExkZ1VBZEpIY05TNHI4ZExzZVBuREdLb3RoUEpValpLMno1dz0ifQ== x-originating-ip: [163.33.239.181] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [PATCH v8 0/4] examples: add performance-thread X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Dec 2015 06:17:29 -0000 -----Original Message----- From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]=20 Sent: Saturday, December 5, 2015 9:21 PM To: Stephen Hemminger; Glynn, Michael J; Betts, Ian Cc: dev@dpdk.org; O'Driscoll, Tim; Richardson, Bruce Subject: Re: [dpdk-dev] [PATCH v8 0/4] examples: add performance-thread > > > Intel may have some milestone to get it into DPDK 2.2 but really=20 > > > this seems too late... > >=20 > > >>>Yes, sure it is too late to have enough discussions in 2.2=20 > > >>>timeframe > > >Just to understand what we mean by too late... > > >The original RFC was issued on 2nd September. > > >Thus there have been some three months available for discussion, and f= or people to raise any questions or concerns. > > >The first patch was available on 30th September, and a number of=20 > > >subsequent patch versions have been issued, meaning the code has been = available for review for two month As mentioned in the reply to Stephen, th= ere has been no adverse feedback during this period. > > >/Ian > >=20 > > Hi Thomas/Stephen > >=20 > > I agree with Ian, how much time is expected for a discussion to happen?= =20 > >=20 > > As Ian stated, the feature was stated in our 2.2 planned feature list, = we created a RFC over 3 months ago, and there's been code available for rev= iew for over 2 months now! (not to mention several version updates, docs, e= tc.).=20 > > Given this, I believe that there has been ample time for the community = to review and provide feedback rather than waiting until the eve of RC3 and= then requesting more time.=20 > >=20 > > In addition, by making it a sample application first people can test=20 > > it, see if it's useful, and further enhance it. Based on usefulness=20 > > and feedback, we can then decide whether to make it a DPDK library=20 > > in a future release, make it a separate library somewhere else, or=20 > > do nothing further on it > >=20 > > For these reasons, I believe it should be merged into RC3 I am not against this idea. I just say that we have no time anymore for discussions. There was no review probably because it is "just" an example. Given that the code is huge, it would be better to have some good feedback = for its integration. But it does not hurt to integrate anyway. The only problem is the maintenance overload. When we change something in a= library, every examples must be updated to keep them working. That's why we must avoid keeping some useless examples. So this one must be discussed during the 2.3 cycle and will see if we keep = it, shrink it, revert it or move to a library. > Since it is an example and well documented that is fine. > Is there an explicit statement that ABI is not binding for examples? >What do you mean by "binding"? I think these are fair comments. I do take the point about maintenance overhead, there is no value in draggi= ng along something that is not being used. After making it available and allowing ti= me for users to explore we can gauge the answer best. Feedback should inform the direction, and whilst we do continue pathfinding= activity internally,=20 in fact we had not planned any updates during the 2.3 cycle, precisely to a= llow time to understand if/how the community would like to see it evolve. =20 So personally I see 2.4 as an appropriate target to implement whatever we d= ecide.