On Tue, 26 Feb 2019 13:50:46 +0530 Leslie Monis <lesliemo...@gmail.com> wrote:
> On Mon, Feb 25, 2019 at 04:38:11PM -0800, Stephen Hemminger wrote: > > On Tue, 26 Feb 2019 00:39:54 +0530 > > Leslie Monis <lesliemo...@gmail.com> wrote: > > > > > The current implementation of the PIE queuing discipline is according to > > > the > > > IETF draft [http://tools.ietf.org/html/draft-pan-aqm-pie-00] and the paper > > > [PIE: A Lightweight Control Scheme to Address the Bufferbloat Problem]. > > > However, a lot of necessary modifications and enhancements have been > > > proposed > > > in RFC 8033, which have not yet been incorporated in the source code of > > > Linux. > > > This patch series helps in achieving the same. > > > > > > Performance tests carried out using Flent [https://flent.org/] > > > > > > Changes from v2 to v3: > > > - Used div_u64() instead of direct division after explicit type casting > > > as > > > recommended by David > > > > > > Changes from v1 to v2: > > > - Excluded the patch setting PIE dynamically active/inactive as the test > > > results were unsatisfactory > > > - Fixed a scaling issue when adding more auto-tuning cases which caused > > > local variables to underflow > > > - Changed the long if/else chain to a loop as suggested by Stephen > > > - Changed the position of the accu_prob variable in the pie_vars > > > structure as recommended by Stephen > > > > > > Mohit P. Tahiliani (7): > > > net: sched: pie: change value of QUEUE_THRESHOLD > > > net: sched: pie: change default value of pie_params->target > > > net: sched: pie: change default value of pie_params->tupdate > > > net: sched: pie: change initial value of pie_vars->burst_time > > > net: sched: pie: add more cases to auto-tune alpha and beta > > > net: sched: pie: add derandomization mechanism > > > net: sched: pie: update references > > > > > > include/uapi/linux/pkt_sched.h | 2 +- > > > net/sched/sch_pie.c | 107 ++++++++++++++++++++------------- > > > 2 files changed, 66 insertions(+), 43 deletions(-) > > > > Are you concerned at all that changes to default values might change > > expected behavior of existing users? > > Hi Stephen, > > As Dave mentioned, the changes which we have made do not really change the > behaviour of the aqm drastically. Our performance tests show that these > changes > improve performance without any side-effects. So existing users (if there are > any) should not be negatively affected in any way. Thanks for answering. Looks good
