From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 13FBD21F3D2 for ; Thu, 14 May 2015 02:19:19 -0700 (PDT) Received: from hms-beagle-5.lan ([134.2.89.70]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0M1n4s-1ZDElN1bLe-00toaF; Thu, 14 May 2015 11:19:15 +0200 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sebastian Moeller In-Reply-To: Date: Thu, 14 May 2015 11:19:12 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <002A5BFC-5511-4995-8785-370251F24083@gmx.de> References: <554F64E1.6000609@gmail.com> <554F9594.60808@gmail.com> <50DB1E31-61AE-4298-B80F-8C6F7487C99B@gmail.com> To: Jonathan Morton X-Mailer: Apple Mail (2.1878.6) X-Provags-ID: V03:K0:mH47XKWyx5+bmxxX+A0CQKt2d+U5e5ddmIPrkeaDOeRoPY2fyP/ iUwK2bGD9poynNOEQDsje4D1iUPB+mVDQX+S8Mm4G4y4OvdA5HQoOBmBYl1QlMjQW+111sx 3oRv5M0Ap/kDdbgBx/PwM1sW9E/XieZbqNEoUXAPjcS9nvFTKimtTdD5pi5qYfV1Tj1hHom ikGiY3jluLsl7VmnpqbCg== X-UI-Out-Filterresults: notjunk:1; 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 09:19:51 -0000 Hi Jonathan, On May 13, 2015, at 08:43 , Jonathan Morton = wrote: >>> I would humbly suggest that we should just get a numerical option = for cake to specify the overhead... >>=20 >> That is in the plans, along with keywords in tc as mnemonics for the = most common configurations. >=20 > 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. 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)? Also from: static inline u32 cake_overhead(struct cake_sched_data *q, u32 in) { u32 out =3D in + q->rate_overhead; =20 if(q->rate_flags & CAKE_FLAG_ATM) { out +=3D 47; do_div(out, 48); out *=3D 53; } =20 return out; } =20 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 know we generally recommend not to use GRO oat least on slow links, = but maybe cake should do the right thing even if encountering offloads? 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. That said autadjusting for GRO does = seem to make some sense, even the light version of just getting the = number of actual ethernet packets hiding in the GRO aggregate an = multiplying the rate_overhead with that number, or probably better just = multiply out by the number of packets in the aggregate (to make sure we = honor AAL5=92s nasty integer number of cells per packet rule). I am out = of my league here, but I have a hunch this might be something useful for = the cake audience and the goal to keep configuration simple. >=20 > The iproute2 support isn=92t as complete as I=92d eventually like. = However, you can specify a numerical overhead (positive or negative, = within sane limits) independently of whether ATM framing compensation is = turned on or off. Excellent, so this will also work for PTM encapsulation and = additional ISP mandated overheads. >=20 > There are also two =93easy mode=94 keywords: =93raw=94 is equivalent = to =93noatm overhead 0=94, and =93conservative=94 means =93atm overhead = 48=94. The latter will almost certainly overestimate the actual = overhead. Great, this is probably the most user friendly set of keywords = to start out with, at worst overestimating the overhead can make the = shaper assume a packet is double its actual wire size and hence wasting = 50% of bandwidth, but the larger the packet the smaller the wasted = percentage of bandwidth get, and users can iteratively decrease the = overhead to find the sweet spot for their link. So I fully endorse these = two settings (for what my endorsement is worth ;) ) >=20 > The help text for cake also now indicates the default options more = clearly. >=20 > Also pushed is a one-line build fix for iproute2. This is really looking great, I will need to switch my router = over to this (or better get a new router so the old one can stay = configured as is, as family friendly back-up ;) ) Best Regards Sebastian >=20 > - Jonathan Morton >=20