From: Thomas Monjalon <thomas.monjalon@6wind.com>
To: "Dumitrescu, Cristian" <cristian.dumitrescu@intel.com>,
Stephen Hemminger <stephen@networkplumber.org>
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH 0/3] sched: patches for 2.2
Date: Sun, 13 Mar 2016 23:25:35 +0100 [thread overview]
Message-ID: <4107462.qD4IMYcbAE@xps13> (raw)
In-Reply-To: <3EB4FA525960D640B5BDFFD6A3D8912647968B0C@IRSMSX108.ger.corp.intel.com>
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.
next prev parent reply other threads:[~2016-03-13 22:26 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-29 18:46 Stephen Hemminger
2015-11-29 18:46 ` [dpdk-dev] [PATCH 1/3] rte_sched: keep track of RED drops Stephen Hemminger
2015-11-29 22:12 ` Thomas Monjalon
2015-11-30 17:47 ` [dpdk-dev] [PATCH] rte_sched: drop deprecation notice for RED statistics Stephen Hemminger
2015-11-29 18:46 ` [dpdk-dev] [PATCH 2/3] rte_sched: introduce reciprocal divide Stephen Hemminger
2015-12-02 16:45 ` Dumitrescu, Cristian
2015-12-02 16:57 ` Hannes Frederic Sowa
2015-12-02 22:05 ` Stephen Hemminger
2015-11-29 18:46 ` [dpdk-dev] [PATCH 3/3] rte_sched: eliminate floating point in calculating byte clock Stephen Hemminger
2015-12-02 16:48 ` Dumitrescu, Cristian
2015-12-02 22:08 ` Stephen Hemminger
2016-03-04 15:00 ` [dpdk-dev] [PATCH 0/3] sched: patches for 2.2 Thomas Monjalon
2016-03-08 7:49 ` Dumitrescu, Cristian
2016-03-08 16:33 ` Stephen Hemminger
2016-03-08 19:53 ` Dumitrescu, Cristian
2016-03-08 20:40 ` Stephen Hemminger
2016-03-10 18:41 ` Dumitrescu, Cristian
2016-03-10 18:44 ` Stephen Hemminger
2016-03-10 18:51 ` Dumitrescu, Cristian
2016-03-13 22:25 ` Thomas Monjalon [this message]
2016-03-13 22:47 ` Dumitrescu, Cristian
2016-03-13 23:09 ` Thomas Monjalon
2016-03-14 14:40 ` Dumitrescu, Cristian
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4107462.qD4IMYcbAE@xps13 \
--to=thomas.monjalon@6wind.com \
--cc=cristian.dumitrescu@intel.com \
--cc=dev@dpdk.org \
--cc=stephen@networkplumber.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).