Thread (23 messages) 23 messages, 4 authors, 2016-03-14

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

From: Thomas Monjalon <hidden>
Date: 2016-03-13 23:10:50

2016-03-13 22:47, Dumitrescu, Cristian:
From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
quoted
2016-03-08 07:49, Dumitrescu, Cristian:
quoted
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.
quoted
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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help