From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 16B7921F2F0 for ; Wed, 22 Apr 2015 15:38:55 -0700 (PDT) Received: by labbd9 with SMTP id bd9so464427lab.2 for ; Wed, 22 Apr 2015 15:38:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=C+m+lUm40Bx0jCFrwBu+ogb6JC3zfj423pfjQwNAO/Y=; b=JUHH6N9T6jaUVxgDRK3LiSV3vCXYyZhewTCsK3np7CCu5HuMeIoPPfhs2TBNBQvUcD tq65oV96CvXNbDb4lHoZP7VrCiJAu9t/e+kokjrl7EbEgi922AIMSFgUg561oEt6uoRD uDZHEl/h2gToNDq9UoRiKeRh4e9scEmSlnpy4rHh+s87Ki2Hd4uhVvK24HT1amajKCad GmFCDas+moG3AqZLiLyH0TJ4uh7p7IEoVI+zuTSzefd/aQxu2Zhq8omN2OkcALc3zVCl zdxILhwTQs2EVCy7A9Tj6N2ZTSuE8GCNuNhufC+yx8RbnVvne9sdLKvv0kPNjcuwYeXU NSag== X-Received: by 10.152.2.105 with SMTP id 9mr26189787lat.16.1429742333573; Wed, 22 Apr 2015 15:38:53 -0700 (PDT) Received: from bass.home.chromatix.fi (188-67-141-134.bb.dnainternet.fi. [188.67.141.134]) by mx.google.com with ESMTPSA id uj9sm1401975lbb.38.2015.04.22.15.38.47 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 22 Apr 2015 15:38:52 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Jonathan Morton In-Reply-To: Date: Thu, 23 Apr 2015 01:38:42 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <0A340D13-7319-4599-AC69-EA8D2328A266@gmail.com> References: To: Adrian Popescu X-Mailer: Apple Mail (2.2098) Cc: cake@lists.bufferbloat.net Subject: Re: [Cake] cake - first impression X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2015 22:39:24 -0000 > On 23 Apr, 2015, at 00:26, Adrian Popescu = wrote: >=20 > Cake is fast and seems to work, but there are some issues. >=20 > tc doesn't allow setting the number of flows for cake: >=20 > tc qdisc add dev eth0 root cake bandwidth 10mbit flows 2048 > What is "2048"? > Usage: ... cake [ bandwidth RATE | unlimited ] > [ besteffort | precedence | diffserv8 | diffserv4 ] > [ flowblind | srchost | dsthost | hosts | flows ] > [ atm ] >=20 > bandwidth validation doesn't catch errors such as 100mbps: > tc qdisc add dev eth0 root cake bandwidth 100mbps > tc qdisc > qdisc cake 8003: dev eth0 root refcnt 3 bandwidth 800Mbit diffserv4 = flows Firstly, tc delegates much of the qdisc configuration parsing to modules = specialised for each qdisc. Helper callbacks are provided for parsing = tricky items like rates and times (and for printing them) - so the = interpretation of =E2=80=9Cmbps=E2=80=9D as =E2=80=9CmegaBYTES per = second=E2=80=9D, versus =E2=80=9Cmbit=E2=80=9D as =E2=80=9CmegaBITS per = second" is entirely up to tc itself. The full range of such suffixes is = therefore detailed in the tc manpage, and I have no inclination to = artificially limit that. Cake doesn=E2=80=99t support adjusting the number of queues per traffic = class (yet), partly because we might want to set a different number for = each class. As an extreme case, we could set just one queue for the = bulk class, observing that fewer resources should be expended on a = low-priority class. The =E2=80=9Cflows=E2=80=9D keyword is provided as = a way to restore the default FQ behaviour, using the entire 5-tuple = rather than a subset or ignoring it completely. On the other hand, there are potentially valid arguments for keeping the = same number of queues in each class, not least that some ISPs use = Diffserv in inappropriate ways, and that the overhead per queue is = fairly low. The memory usage for queue housekeeping is in the kilobytes = with the present settings, which is trivial on most modern hardware, and = the algorithms are mostly O(1) on CPU under normal conditions; there=E2=80= =99s an edge case or two which triggers an O(n) scan, but I think = there=E2=80=99s a reasonable way to eliminate even that. There may also be nuances to queue counts that we haven=E2=80=99t yet = implemented and might complicate matters, such as a dual-layer FQ = offering per-host fairness as well as per-flow fairness. Due to this = uncertainty, and a strong desire to keep cake=E2=80=99s configuration = simple, it=E2=80=99s a compile-time option only (ie. you have to edit = the code). Hence it=E2=80=99s a work in progress, albeit one that already works = quite well. - Jonathan Morton