From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) (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 8203121F3C4 for ; Thu, 14 May 2015 03:24:44 -0700 (PDT) Received: by lagv1 with SMTP id v1so60837417lag.3 for ; Thu, 14 May 2015 03:24:42 -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=+V9TtCIlHrLs26b350aV4oEKnsjqCI28Hu1rdNJ3ats=; b=F/uUrLrxUH26/As1pRm2IKwkN0fhAiC/2LvLTWJrJUesKEUM2z5ufTYk49vQzkTSwB ws+QG9UaMQRN1frCkSeNIFuAMtbk+LA8MMOkfKKX/QDhYlrwcoMVDJsfESPRsBzLYivO uKgVcRlUFX7DZOHUcBGH597BNw83fgzZBhNWjB99iX7MS7f43myWLL4otAa2Urc54WsM dVTlZPJnd59onJNoUVBFAfJDg454LfQsIrim1thdwGB/l0Np0xNsQZgmX8tqxDVxM0+y 6gxFGDoHxc7L8NObaDQquBVdfYUeiBZ6S39//+TUPo56QCz4ZHXaKfY8Doy8qX6yvPW5 MsJA== X-Received: by 10.152.27.1 with SMTP id p1mr2567032lag.112.1431599082402; Thu, 14 May 2015 03:24:42 -0700 (PDT) Received: from bass.home.chromatix.fi (87-95-105-63.bb.dnainternet.fi. [87.95.105.63]) by mx.google.com with ESMTPSA id t1sm5988305lbb.25.2015.05.14.03.24.34 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 14 May 2015 03:24:41 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Jonathan Morton In-Reply-To: <002A5BFC-5511-4995-8785-370251F24083@gmx.de> Date: Thu, 14 May 2015 13:24:18 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <554F64E1.6000609@gmail.com> <554F9594.60808@gmail.com> <50DB1E31-61AE-4298-B80F-8C6F7487C99B@gmail.com> <002A5BFC-5511-4995-8785-370251F24083@gmx.de> To: Sebastian Moeller X-Mailer: Apple Mail (2.2098) Cc: cake@lists.bufferbloat.net Subject: Re: [Cake] openwrt build with latest cake and other qdiscs 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: Thu, 14 May 2015 10:25:14 -0000 >> I=92ve just pushed support for an overhead parameter; both cake = itself and the iproute2 module. I took the opportunity to put in a = minor optimisation for the cell-framing compensation as well. >=20 > Great, thanks a lot. I have a question though: = http://lxr.free-electrons.com/ident?i=3Dpsched_l2t_ns basically does the = same operation, but slightly different: > DIV_ROUND_UP instead of do_div((n+d-1), d) > What is the kernel policy here, reuse specialized macros or rather = code more readable (with slight redundancy)? It looks as though the DIV_ROUND_UP() expands to exactly the same code, = except that a plain division is used instead of do_div(). The latter = includes a conversion to multiplying by the inverse on ARM, when the = divisor is a constant (which it is), since ARM doesn=92t have a hardware = integer divide. (AArch64 does.) With that said, I haven=92t closely examined the resulting assembler. I=92m also not going to use psched_l2t_ns(), because I use the corrected = packet length for other purposes than just time. It also fails to = support negative overheads, which can occasionally occur when using = IPoA. > It seems clear that cake does fully rely on the supplied overhead, = unlike htb which will automatically add ethernet overhead and an = estimate? of the additional header GRO packets drag in, see: > http://lxr.free-electrons.com/source/net/core/dev.c#L2744 I can=92t figure out the connection between HTB and that code. Also, = that appears to be GSO, not GRO. I=92m not precisely sure what the = difference is, but I=92d hazard a guess that GSO is outbound, GRO is = inbound. Frankly, I hate having to deal with packet aggregates in the core = network stack. Device drivers can aggregate if that makes sense for the = hardware, but I=92d much rather that was kept out of my qdisc. Peeling = is on the agenda; that=92ll make sure we are dealing with actual, = individual packets when we need to. Certainly when dealing with = cell-framing overhead, we *always* need to know individual packet sizes. > I actually like that cake does not try to auto-adjust the overhead by = itself, since the kernel does this automatically for an ethernet link, = but not say for a PPPoE interface, making it a bit tricky to recommend = the proper encapsulation to ATM users, =93use 40 if you shape on the = pppoe-wan interface but 26 if you shape on the wan interface directly is = a sure way to confuse people=94. I consider that a user-interface problem, as well as reflecting a = general problem with PPPoE. Actually, PPPoE has *never* been = user-friendly; it outright sucks in all respects. I can=92t think of a = single reason to use PPPoE instead of PPPoA. AFAIK, all Finnish and = most British DSL ISPs use either PPPoA or bridging; I=92ve only = personally encountered PPPoE in the US. To help reduce confusion, it would probably be best to offer consistent = advice on which interface to shape and how much overhead to account for = there. I think shaping the traffic that actually goes over the link is = more correct than shaping the traffic that goes to the modem (which = might include some management traffic that doesn=92t go on the wire). = So you should shape on the PPPoE interface and add the full 40 bytes = there. Happily, this advice is also safe if the user accidentally = selects the wrong interface, since 40 bytes is conservative for the = Ethernet interface. Anyway, user-interface problems are best solved in userspace. Cake=92s = internal implementation is thus kept simple and numerical. The tc = module now supports that directly, and more user-friendly support can be = added either there or in external scripts, or some combination of the = two. - Jonathan Morton