From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id 10FB5275D for ; Tue, 8 Mar 2016 08:49:34 +0100 (CET) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga102.fm.intel.com with ESMTP; 07 Mar 2016 23:49:23 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.22,555,1449561600"; d="scan'208";a="919141782" Received: from irsmsx102.ger.corp.intel.com ([163.33.3.155]) by fmsmga001.fm.intel.com with ESMTP; 07 Mar 2016 23:49:21 -0800 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; Tue, 8 Mar 2016 07:49:20 +0000 From: "Dumitrescu, Cristian" To: Thomas Monjalon Thread-Topic: [dpdk-dev] [PATCH 0/3] sched: patches for 2.2 Thread-Index: AQHRdibvymTmJ1EDtEWBk+3d8+Ige59PK0tQ Date: Tue, 8 Mar 2016 07:49:20 +0000 Message-ID: <3EB4FA525960D640B5BDFFD6A3D8912647968B0C@IRSMSX108.ger.corp.intel.com> References: <1448822809-8350-1-git-send-email-stephen@networkplumber.org> <5760276.6KREI08Oct@xps13> In-Reply-To: <5760276.6KREI08Oct@xps13> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiYjRmZDc5MTQtM2MyNC00MGU1LWI2NmQtOGRmNzc1ZWE2NDgwIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6IkYwSkhQb3pobUJyekVuajVpYkZLWjdYbmtMRjJNdGN5Tzc3SGhlZDJlT0U9In0= x-ctpclassification: CTP_IC x-originating-ip: [163.33.239.180] 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2016 07:49:35 -0000 > -----Original Message----- > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > Sent: Friday, March 4, 2016 3:01 PM > To: Dumitrescu, Cristian > Cc: dev@dpdk.org; Stephen Hemminger > Subject: Re: [dpdk-dev] [PATCH 0/3] sched: patches for 2.2 >=20 > 2015-11-29 10:46, Stephen Hemminger: > > This is the last round of sched updates for 2.2. It is based > > on code changes (extensively) tested by QA and used in the vRouter. > > > > Stephen Hemminger (3): > > rte_sched: keep track of RED drops > > rte_sched: introduce reciprocal divide > > rte_sched: eliminate floating point in calculating byte clock >=20 > Cristian, what is the status of this series, please? We are working on implementing an alternative solution based on 2x 64-bit m= ultiplication, which is supported by CPUs and compilers for more than a dec= ade now. The 32-bit solution proposed by Stephen requires truncation with s= ome loss of precision, which can potentially lead to some corner cases whic= h 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 co= de, therefore I am very cautious of it. I am not sure we are able to finalize implementation and testing for releas= e 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 do= es not 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 Stephe= n's code is relicensed with BSD license by permission from the original cod= e 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 algorith= m 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 sep= arate patches submitted independently: one introducing the rte_reciprocal.[= hc] algorithm to librte_eal/common and the second containing just the librt= e_sched changes, which are small. I am thinking ahead here: once we have th= e 2x64-bit multiplication solution in place, we should not have rte_recipro= cal.[hc] hanging in librte_sched folder without being used here, while it m= ight be used by other parts of DPDK. Thanks, Cristian