> -----Original Message----- > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > Sent: Sunday, March 13, 2016 11:09 PM > To: Dumitrescu, Cristian <cristian.dumitrescu at intel.com>; Stephen > Hemminger <stephen at networkplumber.org> > Cc: dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCH 0/3] sched: patches for 2.2 > > 2016-03-13 22:47, Dumitrescu, Cristian: > > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > > > 2016-03-08 07:49, Dumitrescu, Cristian: > > > > Regarding Stephen's patches, I think there is a pending issue regarding > 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 code > > > author (which also submitted the code to Linux kernel under GPL). This > 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, therefore 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 > > > algorithm > > > 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 have > > > 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 > > > candidate. > > > 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 the > > header file > > There is no copyright issue. Just an Intel mention in the disclaimer.
Thanks, Thomas, for confirming this. My knowledge on copyright issues is limited, so I was not sure whether this is an issue or not. > > > and move the rte_reciprocal.[hc] into a common area like > > librte_eal/common in time for the next release candidate. > > 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 libraries that would benefit from a faster implementation of division (e.g. librte_meter), there are probably others as well. I'd like to get Stephen's opinion on this.
