> > 25/06/2020 11:59, alangordonde...@gmail.com:
> > > From: Alan Dewar <alan.de...@att.com>
> > >
> > > The QoS scheduler works off port time that is computed from the number
> > > of CPU cycles that have elapsed since the last time the port was
> > > polled. It divides the number of elapsed cycles to calculate how
> > > many bytes can be sent, however this division can generate rounding
> > > errors, where some fraction of a byte sent may be lost.
> > >
> > > Lose enough of these fractional bytes and the QoS scheduler
> > > underperforms. The problem is worse with low bandwidths.
> > >
> > > To compensate for this rounding error this fix doesn't advance the
> > > port's time_cpu_cycles by the number of cycles that have elapsed, but
> > > by multiplying the computed number of bytes that can be sent (which
> > > has been rounded down) by number of cycles per byte.
> > > This will mean that port's time_cpu_cycles will lag behind the CPU
> > > cycles momentarily. At the next poll, the lag will be taken into
> > > account.
> > >
> > > v2:
> > > If the cycles value wraps (100 year+) reset the port's cpu cycle back
> > > to zero.
> > >
> > > Fixes: de3cfa2c98 ("sched: initial import")
> > >
> > > Signed-off-by: Alan Dewar <alan.de...@att.com>
>
> Acked-by: Jasvinder Singh <jasvinder.si...@intel.com>
Applied, thanks
