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