From: "Dumitrescu, Cristian" <cristian.dumitrescu@intel.com>
To: Thomas Monjalon <thomas.monjalon@6wind.com>,
Stephen Hemminger <stephen@networkplumber.org>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH 0/3] sched: patches for 2.2
Date: Sun, 13 Mar 2016 22:47:28 +0000 [thread overview]
Message-ID: <3EB4FA525960D640B5BDFFD6A3D891264796D475@IRSMSX108.ger.corp.intel.com> (raw)
In-Reply-To: <4107462.qD4IMYcbAE@xps13>
> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> Sent: Sunday, March 13, 2016 10:26 PM
> 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
>
> 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.
Hi Thomas,
I am OK with this, as long as Stephen commits to fix the copyright in the header file and move the rte_reciprocal.[hc] into a common area like librte_eal/common in time for the next release candidate.
Thanks,
Cristian
next prev parent reply other threads:[~2016-03-13 22:47 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
2016-03-13 22:47 ` Dumitrescu, Cristian [this message]
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=3EB4FA525960D640B5BDFFD6A3D891264796D475@IRSMSX108.ger.corp.intel.com \
--to=cristian.dumitrescu@intel.com \
--cc=dev@dpdk.org \
--cc=stephen@networkplumber.org \
--cc=thomas.monjalon@6wind.com \
/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).