From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Hemminger Subject: Re: [PATCH net-next 5/8] net: sched: pie: add more conditions to auto-tune alpha and beta Date: Wed, 31 Oct 2018 09:40:34 -0700 Message-ID: <20181031094034.4563aad1@xeon-e3> References: <1541002772-28040-1-git-send-email-lesliemonis@gmail.com> <1541002772-28040-6-git-send-email-lesliemonis@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: jhs@mojatatu.com, netdev@vger.kernel.org, tahiliani@nitk.edu.in, dhavaljkhandla26@gmail.com, hrishihiraskar@gmail.com, bmanish15597@gmail.com, sdp.sachin@gmail.com To: Leslie Monis Return-path: Received: from mail-pf1-f195.google.com ([209.85.210.195]:45892 "EHLO mail-pf1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729696AbeKABjX (ORCPT ); Wed, 31 Oct 2018 21:39:23 -0400 Received: by mail-pf1-f195.google.com with SMTP id v5-v6so2972693pfm.12 for ; Wed, 31 Oct 2018 09:40:37 -0700 (PDT) In-Reply-To: <1541002772-28040-6-git-send-email-lesliemonis@gmail.com> Sender: netdev-owner@vger.kernel.org List-ID: On Wed, 31 Oct 2018 21:49:29 +0530 Leslie Monis wrote: > From: "Mohit P. Tahiliani" > > The update in drop probability depends on the parameters > alpha and beta, which in turn reflect the current congestion > level. However, the previous if-else cases were recommended > when the supported bandwidth was up to 12 Mbps but, current > data links support a much higher bandwidth, and the > requirement for more bandwidth is in never-ending demand. > Hence, RFC 8033 suggests using more if-else cases for better > fine-tuning of parameters alpha and beta in order to control > the congestion as much as possible. > > Signed-off-by: Mohit P. Tahiliani > Signed-off-by: Dhaval Khandla > Signed-off-by: Hrishikesh Hiraskar > Signed-off-by: Manish Kumar B > Signed-off-by: Sachin D. Patil > Signed-off-by: Leslie Monis > --- > net/sched/sch_pie.c | 26 +++++++++++++++++++++++--- > 1 file changed, 23 insertions(+), 3 deletions(-) > > diff --git a/net/sched/sch_pie.c b/net/sched/sch_pie.c > index f4e189a..c84e91e 100644 > --- a/net/sched/sch_pie.c > +++ b/net/sched/sch_pie.c > @@ -343,10 +343,30 @@ static void calculate_probability(struct Qdisc *sch) > * appropriately 2) scaling down by 16 to come to 0-2 range. > * Please see paper for details. > * > - * We scale alpha and beta differently depending on whether we are in > - * light, medium or high dropping mode. > + * We scale alpha and beta differently depending on how heavy the > + * congestion is. > */ > - if (q->vars.prob < MAX_PROB / 100) { > + if (q->vars.prob < MAX_PROB / 1000000) { > + alpha = > + (q->params.alpha * (MAX_PROB / PSCHED_TICKS_PER_SEC)) >> 15; > + beta = > + (q->params.beta * (MAX_PROB / PSCHED_TICKS_PER_SEC)) >> 15; > + } else if (q->vars.prob < MAX_PROB / 100000) { > + alpha = > + (q->params.alpha * (MAX_PROB / PSCHED_TICKS_PER_SEC)) >> 13; > + beta = > + (q->params.beta * (MAX_PROB / PSCHED_TICKS_PER_SEC)) >> 13; > + } else if (q->vars.prob < MAX_PROB / 10000) { > + alpha = > + (q->params.alpha * (MAX_PROB / PSCHED_TICKS_PER_SEC)) >> 11; > + beta = > + (q->params.beta * (MAX_PROB / PSCHED_TICKS_PER_SEC)) >> 11; > + } else if (q->vars.prob < MAX_PROB / 1000) { > + alpha = > + (q->params.alpha * (MAX_PROB / PSCHED_TICKS_PER_SEC)) >> 9; > + beta = > + (q->params.beta * (MAX_PROB / PSCHED_TICKS_PER_SEC)) >> 9; > + } else if (q->vars.prob < MAX_PROB / 100) { > alpha = > (q->params.alpha * (MAX_PROB / PSCHED_TICKS_PER_SEC)) >> 7; > beta = Seems like the if/else chain is getting long in the tail. Maybe a loop or table driven approach would be clearer.