DPDK patches and discussions
 help / color / mirror / Atom feed
From: Thomas Monjalon <thomas@monjalon.net>
To: Alan Dewar <alangordondewar@gmail.com>, Alan Dewar <alan.dewar@att.com>
Cc: dev@dpdk.org, "Yigit, Ferruh" <ferruh.yigit@intel.com>,
	"Kantecki, Tomasz" <tomasz.kantecki@intel.com>,
	Stephen Hemminger <stephen@networkplumber.org>,
	"dev@dpdk.org" <dev@dpdk.org>,
	"Dumitrescu, Cristian" <cristian.dumitrescu@intel.com>,
	jasvinder.singh@intel.com, david.marchand@redhat.com,
	bruce.richardson@intel.com
Subject: Re: [dpdk-dev] [PATCH v7] sched: make RED scaling configurable
Date: Tue, 07 Jul 2020 01:09:30 +0200	[thread overview]
Message-ID: <1642305.bAa2EqY5vZ@thomas> (raw)
In-Reply-To: <3EB4FA525960D640B5BDFFD6A3D891268E87276A@IRSMSX108.ger.corp.intel.com>

08/04/2019 15:29, Dumitrescu, Cristian:
> From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > 08/04/2019 10:24, Alan Dewar:
> > > On Fri, Apr 5, 2019 at 4:36 PM Ferruh Yigit <ferruh.yigit@intel.com> wrote:
> > > > On 1/16/2018 4:07 PM, alangordondewar@gmail.com wrote:
> > > > > From: Alan Dewar <alan.dewar@att.com>
> > > > >
> > > > > The RED code stores the weighted moving average in a 32-bit integer as
> > > > > a pseudo fixed-point floating number with 10 fractional bits.  Twelve
> > > > > other bits are used to encode the filter weight, leaving just 10 bits
> > > > > for the queue length.  This limits the maximum queue length supported
> > > > > by RED queues to 1024 packets.
> > > > >
> > > > > Introduce a new API to allow the RED scaling factor to be configured
> > > > > based upon maximum queue length.  If this API is not called, the RED
> > > > > scaling factor remains at its default value.
> > > > >
> > > > > Added some new RED scaling unit-tests to test with RED queue-lengths
> > > > > up to 8192 packets long.
> > > > >
> > > > > Signed-off-by: Alan Dewar <alan.dewar@att.com>
> > > >
> > > > Hi Cristian, Alan,
> > > >
> > > > The v7 of this patch is sting without any comment for more than a year.
> > > > What is the status of this patch? Is it still valid? What is blocking it?
> > > >
> > > > For reference patch:
> > > > https://patches.dpdk.org/patch/33837/
> > >
> > > We are still using this patch against DPDK 17.11 and 18.11 as part of
> > > the AT&T Vyatta NOS.   It is needed to make WRED queues longer than
> > > 1024 packets work correctly.  I'm afraid that I have no idea what is
> > > holding it up from being merged.
> > 
> > It will be in a release when it will be merged in the git tree
> > dpdk-next-qos, managed by Cristian.
> 
> I was hoping to get a review & ACK from Tomasz Kantecki, the author of the WRED code in DPDK, hence the lack of progress on this patch.

It seems nobody was able to provide an feedback after two years,
and it was never merged in the QoS git tree.
The handling of this patch is really a shame.

Alan, please rebase this patch.
If nothing is wrong in CI (including ABI check),
I will merge the next version.



      parent reply	other threads:[~2020-07-06 23:09 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1507022514-21831-1>
2018-01-08 15:27 ` [dpdk-dev] [PATCH v5] " alangordondewar
2018-01-11 13:11   ` Dumitrescu, Cristian
2018-01-12  9:38     ` Dewar, Alan
2018-01-12 11:09       ` Dumitrescu, Cristian
2018-01-12 11:52         ` Dumitrescu, Cristian
2018-01-15 15:36           ` Dewar, Alan
2018-01-16 11:56             ` Dumitrescu, Cristian
2018-01-12 10:44     ` Dewar, Alan
2018-01-12 11:43       ` Dumitrescu, Cristian
2018-01-15 16:16   ` [dpdk-dev] [PATCH v6] " alangordondewar
2018-01-15 16:52     ` Stephen Hemminger
2018-01-16 15:50       ` Alan Dewar
2018-01-16 15:57         ` Alan Dewar
2018-01-16 16:44           ` Dumitrescu, Cristian
2018-01-16 16:07     ` [dpdk-dev] [PATCH v7] " alangordondewar
2019-04-05 15:36       ` Ferruh Yigit
2019-04-05 15:36         ` Ferruh Yigit
2019-04-08  8:24         ` Alan Dewar
2019-04-08  8:24           ` Alan Dewar
2019-04-08  8:53           ` Thomas Monjalon
2019-04-08  8:53             ` Thomas Monjalon
2019-04-08 13:29             ` Dumitrescu, Cristian
2019-04-08 13:29               ` Dumitrescu, Cristian
2020-07-06 23:09               ` Thomas Monjalon [this message]

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=1642305.bAa2EqY5vZ@thomas \
    --to=thomas@monjalon.net \
    --cc=alan.dewar@att.com \
    --cc=alangordondewar@gmail.com \
    --cc=bruce.richardson@intel.com \
    --cc=cristian.dumitrescu@intel.com \
    --cc=david.marchand@redhat.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=jasvinder.singh@intel.com \
    --cc=stephen@networkplumber.org \
    --cc=tomasz.kantecki@intel.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).