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

[Thomas Monjalon <thomas.monjalon@6wind.com>]

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 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.

> 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.