[dpdk-dev] [PATCH 0/3] sched: patches for 2.2

[Dumitrescu, Cristian]

> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Sunday, March 13, 2016 10:26 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-08 07:49, Dumitrescu, Cristian:
> > We are working on implementing an alternative solution based on 2x 64-bit
> 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 cases
> 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 release
> 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 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 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 and move the rte_reciprocal.[hc] into a common area like librte_eal/common in time for the next release candidate.

Thanks,
Cristian