Hi Ferruh, 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.
Regards Alan On Fri, Apr 5, 2019 at 4:36 PM Ferruh Yigit <ferruh.yi...@intel.com> wrote: > > On 1/16/2018 4:07 PM, alangordonde...@gmail.com wrote: > > From: Alan Dewar <alan.de...@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.de...@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/
