From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by dpdk.org (Postfix) with ESMTP id 2689911D9 for ; Mon, 14 Mar 2016 15:40:08 +0100 (CET) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga104.fm.intel.com with ESMTP; 14 Mar 2016 07:40:07 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.24,335,1455004800"; d="scan'208";a="933448904" Received: from irsmsx103.ger.corp.intel.com ([163.33.3.157]) by orsmga002.jf.intel.com with ESMTP; 14 Mar 2016 07:40:05 -0700 Received: from irsmsx108.ger.corp.intel.com ([169.254.11.13]) by IRSMSX103.ger.corp.intel.com ([169.254.3.239]) with mapi id 14.03.0248.002; Mon, 14 Mar 2016 14:40:05 +0000 From: "Dumitrescu, Cristian" To: Thomas Monjalon , Stephen Hemminger CC: "dev@dpdk.org" Thread-Topic: [dpdk-dev] [PATCH 0/3] sched: patches for 2.2 Thread-Index: AQHRdibvymTmJ1EDtEWBk+3d8+Ige59PK0tQgAjW7YCAAAVQAIAABvGAgAECauA= Date: Mon, 14 Mar 2016 14:40:04 +0000 Message-ID: <3EB4FA525960D640B5BDFFD6A3D891264796D7DD@IRSMSX108.ger.corp.intel.com> References: <1448822809-8350-1-git-send-email-stephen@networkplumber.org> <4107462.qD4IMYcbAE@xps13> <3EB4FA525960D640B5BDFFD6A3D891264796D475@IRSMSX108.ger.corp.intel.com> <7147300.0jXl9hpqrT@xps13> In-Reply-To: <7147300.0jXl9hpqrT@xps13> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiYjlmYmNlMzUtYmQ1Yy00Mjg2LTg0OWUtM2ZmZmNmZWFlYjg3IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6IlFvOFh1aFFEM2tSOU1sUkl4UEhvc2NncXR0OWdMOXhTSnZqdWxhb1BUd1k9In0= 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 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: Mon, 14 Mar 2016 14:40:08 -0000 > -----Original Message----- > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > Sent: Sunday, March 13, 2016 11:09 PM > To: Dumitrescu, Cristian ; Stephen > Hemminger > Cc: dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH 0/3] sched: patches for 2.2 >=20 > 2016-03-13 22:47, Dumitrescu, Cristian: > > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > > > 2016-03-08 07:49, Dumitrescu, Cristian: > > > > Regarding Stephen's patches, I think there is a pending issue regar= ding > the > > > legal side of the Copyright, which is attributed to Intel, although > Stephen's > > > code is relicensed with BSD license by permission from the original c= ode > > > author (which also submitted the code to Linux kernel under GPL). Thi= s > was > > > 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 > algorithm > > > that is very generic and totally independent of the QoS code, therefo= re it > > > should be placed into a different folder that is globally visible to = other > > > libraries (librte_eal/common ?) just in case other usages for this al= gorithm > > > are identified in the future. I suggest we break the patch into two > separate > > > 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 hav= e > > > rte_reciprocal.[hc] hanging in librte_sched folder without being used > here, > > > while it might be used by other parts of DPDK. > > > > > > Let's keep the improvement as-is to test it in the first release cand= idate. > > > We can move the code and/or fix the file header later. > > > > > > Series applied, thanks. > > > > Hi Thomas, > > > > I am OK with this, as long as Stephen commits to fix the copyright in t= he > > header file >=20 > There is no copyright issue. Just an Intel mention in the disclaimer. Thanks, Thomas, for confirming this. My knowledge on copyright issues is li= mited, so I was not sure whether this is an issue or not. >=20 > > and move the rte_reciprocal.[hc] into a common area like > > librte_eal/common in time for the next release candidate. >=20 > If it is moved as a public API, it must be better documented. > If it stay here, it must be removed from SYMLINK-y-include. My vote would go for making this a public API, moving it to a common place = (like librte_eal/common) and better documenting it. I already see other lib= raries that would benefit from a faster implementation of division (e.g. li= brte_meter), there are probably others as well. I'd like to get Stephen's o= pinion on this.