From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 175F33BA8E for ; Fri, 4 May 2018 15:10:15 -0400 (EDT) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1525461013; bh=bPnKxhBhRP5/P+C/7S4Sqorad2M/BkHREqq6WIl0Wm8=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=YicU8/xJusUayFFeFbOZUcIwBFYHsgmwXoPG6sNBV5ZqxvdX5gtKMIN7PkUsHruV6 kZt6aqF4bNK6aea8U35LCWWiKl+d+MUb84nqxJGkasXLe7D0n1lrR31q0NTfRxIc27 ggPhSsvN/jHgqrnxPLYByLhyisUfS6H7Amb04Yag7hVh2LonleEblDs/kJ+CBnE/J4 0RjyKG6RyYlJ4cMUiiwFg+Lnw4Ka8YOl//u2KwzJckElmQm+mBIILuwOJNWuxahRr/ FvA0YZDztSPW7eDADT26pEzXLLRw4hJqcKsZW0OK8EWg1LeSqiAjJ1N+G1+m+Opjkb HymN2HGD/ZGwg== To: Cong Wang Cc: Linux Kernel Network Developers , Cake List In-Reply-To: References: <152544254217.11750.5727163821563013360.stgit@alrua-kau> <152544255298.11750.16512595539680113590.stgit@alrua-kau> Date: Fri, 04 May 2018 21:10:17 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87in831bl2.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Cake] [PATCH net-next v8 1/7] sched: Add Common Applications Kept Enhanced (cake) qdisc X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2018 19:10:15 -0000 Thank you for the review! A few comments below, I'll fix the rest. > [...] > > So sch_cake doesn't accept normal tc filters? Is this intentional? > If so, why? For two reasons: - The two-level scheduling used in CAKE (tins / diffserv classes, and flow hashing) does not map in an obvious way to the classification index of tc filters. - No one has asked for it. We have done our best to accommodate the features people want in a home router qdisc directly in CAKE, and the ability to integrate tc filters has never been requested. >> +static u16 quantum_div[CAKE_QUEUES + 1] = {0}; >> + >> +#define REC_INV_SQRT_CACHE (16) >> +static u32 cobalt_rec_inv_sqrt_cache[REC_INV_SQRT_CACHE] = {0}; >> + >> +/* http://en.wikipedia.org/wiki/Methods_of_computing_square_roots >> + * new_invsqrt = (invsqrt / 2) * (3 - count * invsqrt^2) >> + * >> + * Here, invsqrt is a fixed point number (< 1.0), 32bit mantissa, aka Q0.32 >> + */ >> + >> +static void cobalt_newton_step(struct cobalt_vars *vars) >> +{ >> + u32 invsqrt = vars->rec_inv_sqrt; >> + u32 invsqrt2 = ((u64)invsqrt * invsqrt) >> 32; >> + u64 val = (3LL << 32) - ((u64)vars->count * invsqrt2); >> + >> + val >>= 2; /* avoid overflow in following multiply */ >> + val = (val * invsqrt) >> (32 - 2 + 1); >> + >> + vars->rec_inv_sqrt = val; >> +} >> + >> +static void cobalt_invsqrt(struct cobalt_vars *vars) >> +{ >> + if (vars->count < REC_INV_SQRT_CACHE) >> + vars->rec_inv_sqrt = cobalt_rec_inv_sqrt_cache[vars->count]; >> + else >> + cobalt_newton_step(vars); >> +} > > Looks pretty much duplicated with codel... Cobalt is derived from CoDel, and so naturally shares some features with it. However, it is quite different in other respects, so we can't just use the existing CoDel code for the parts that are similar. We don't feel quite confident enough in Cobalt (yet) to propose it replace CoDel everywhere else in the kernel; so we have elected to keep it internal to CAKE instead. >> [...] >> >> +static int cake_init(struct Qdisc *sch, struct nlattr *opt, >> + struct netlink_ext_ack *extack) >> +{ >> + struct cake_sched_data *q = qdisc_priv(sch); >> + int i, j; >> + >> + sch->limit = 10240; >> + q->tin_mode = CAKE_DIFFSERV_BESTEFFORT; >> + q->flow_mode = CAKE_FLOW_TRIPLE; >> + >> + q->rate_bps = 0; /* unlimited by default */ >> + >> + q->interval = 100000; /* 100ms default */ >> + q->target = 5000; /* 5ms: codel RFC argues >> + * for 5 to 10% of interval >> + */ >> + >> + q->cur_tin = 0; >> + q->cur_flow = 0; >> + >> + if (opt) { >> + int err = cake_change(sch, opt, extack); >> + >> + if (err) >> + return err; > > > Not sure if you really want to reallocate q->tines below for this > case. I'm not sure what you mean here? If there's an error we return it and the qdisc is not created. If there's not, we allocate and on subsequent changes cake_change() will be called directly, or? Can the init function ever be called again during the lifetime of the qdisc? -Toke