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