From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <cristian.dumitrescu@intel.com> Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id E069747CD for <dev@dpdk.org>; Sun, 13 Mar 2016 23:47:31 +0100 (CET) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga103.fm.intel.com with ESMTP; 13 Mar 2016 15:47:30 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.24,333,1455004800"; d="scan'208";a="936213758" Received: from irsmsx102.ger.corp.intel.com ([163.33.3.155]) by fmsmga002.fm.intel.com with ESMTP; 13 Mar 2016 15:47:29 -0700 Received: from irsmsx108.ger.corp.intel.com ([169.254.11.13]) by IRSMSX102.ger.corp.intel.com ([169.254.2.19]) with mapi id 14.03.0248.002; Sun, 13 Mar 2016 22:47:29 +0000 From: "Dumitrescu, Cristian" <cristian.dumitrescu@intel.com> To: Thomas Monjalon <thomas.monjalon@6wind.com>, Stephen Hemminger <stephen@networkplumber.org> CC: "dev@dpdk.org" <dev@dpdk.org> Thread-Topic: [dpdk-dev] [PATCH 0/3] sched: patches for 2.2 Thread-Index: AQHRdibvymTmJ1EDtEWBk+3d8+Ige59PK0tQgAjW7YCAAAVQAA== Date: Sun, 13 Mar 2016 22:47:28 +0000 Message-ID: <3EB4FA525960D640B5BDFFD6A3D891264796D475@IRSMSX108.ger.corp.intel.com> References: <1448822809-8350-1-git-send-email-stephen@networkplumber.org> <5760276.6KREI08Oct@xps13> <3EB4FA525960D640B5BDFFD6A3D8912647968B0C@IRSMSX108.ger.corp.intel.com> <4107462.qD4IMYcbAE@xps13> In-Reply-To: <4107462.qD4IMYcbAE@xps13> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNDQwYzNlMTctZjU3Yy00YjRhLWJhNTQtYTA1Nzc0NTdmNjJmIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6ImZIZndsN3A5YkkyNzZZSEx0akdDQ1dneW1aTW11ak9RQzhUTmZ3NTlnUEE9In0= x-ctpclassification: CTP_IC x-originating-ip: [163.33.239.182] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH 0/3] sched: patches for 2.2 X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK <dev.dpdk.org> List-Unsubscribe: <http://dpdk.org/ml/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://dpdk.org/ml/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <http://dpdk.org/ml/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> X-List-Received-Date: Sun, 13 Mar 2016 22:47:32 -0000 > -----Original Message----- > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > Sent: Sunday, March 13, 2016 10:26 PM > To: Dumitrescu, Cristian <cristian.dumitrescu@intel.com>; Stephen > Hemminger <stephen@networkplumber.org> > Cc: dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH 0/3] sched: patches for 2.2 >=20 > 2016-03-08 07:49, Dumitrescu, Cristian: > > We are working on implementing an alternative solution based on 2x 64-b= it > multiplication, which is supported by CPUs and compilers for more than a > decade now. The 32-bit solution proposed by Stephen requires truncation > with some loss of precision, which can potentially lead to some corner ca= ses > which are difficult to predict, therefore I am not feeling 100% confident= with > it. The 32-bit arithmetic gave me a lot of headaches when developing QoS > code, therefore I am very cautious of it. > > > > I am not sure we are able to finalize implementation and testing for re= lease > 16.4, therefore it would be fair to accept Stephen's solution for release= 16.4 > and consider the new safer 2x 64-bit multiplication solution which does n= ot > involve any loss of precision once it becomes available. > > > > Regarding Stephen's patches, I think there is a pending issue regarding= the > legal side of the Copyright, which is attributed to Intel, although Steph= en's > code is relicensed with BSD license by permission from the original code > author (which also submitted the code to Linux kernel under GPL). This wa= s > already flagged. This is a legal issue and I do not feel comfortable with= ack-ing > this patch until the legal resolution on this is crystal clear. > > > > I also think the new files called rte_reciprocal.[hc] implement an algo= rithm > that is very generic and totally independent of the QoS code, therefore i= t > should be placed into a different folder that is globally visible to othe= r > libraries (librte_eal/common ?) just in case other usages for this algori= thm > are identified in the future. I suggest we break the patch into two separ= ate > patches submitted independently: one introducing the rte_reciprocal.[hc] > algorithm to librte_eal/common and the second containing just the > librte_sched changes, which are small. I am thinking ahead here: once we > have the 2x64-bit multiplication solution in place, we should not have > rte_reciprocal.[hc] hanging in librte_sched folder without being used her= e, > while it might be used by other parts of DPDK. >=20 > Let's keep the improvement as-is to test it in the first release candidat= e. > We can move the code and/or fix the file header later. >=20 > Series applied, thanks. Hi Thomas, I am OK with this, as long as Stephen commits to fix the copyright in the h= eader file and move the rte_reciprocal.[hc] into a common area like librte_= eal/common in time for the next release candidate. Thanks, Cristian