From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-32-ewr.dyndns.com (mxout-053-ewr.mailhop.org [216.146.33.53]) by lists.bufferbloat.net (Postfix) with ESMTP id 306492E032F for ; Thu, 24 Feb 2011 11:29:51 -0800 (PST) Received: from scan-32-ewr.mailhop.org (scan-32-ewr.local [10.0.141.238]) by mail-32-ewr.dyndns.com (Postfix) with ESMTP id 4B3296F806E for ; Thu, 24 Feb 2011 19:29:39 +0000 (UTC) X-Spam-Score: -1.0 (-) X-Mail-Handler: MailHop by DynDNS X-Originating-IP: 209.85.214.43 Received: from mail-bw0-f43.google.com (mail-bw0-f43.google.com [209.85.214.43]) by mail-32-ewr.dyndns.com (Postfix) with ESMTP id C04736F7ADD; Thu, 24 Feb 2011 19:29:34 +0000 (UTC) Received: by bwz14 with SMTP id 14so1718051bwz.16 for ; Thu, 24 Feb 2011 11:29:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:from:to:cc:in-reply-to:references :content-type:date:message-id:mime-version:x-mailer :content-transfer-encoding; bh=8XE5RQ2J7iYc1N44i67Ei3QjqdvHCrga2Z3lHc8Xebs=; b=Ffx0aa/NZvg7CoOm11q2WonmGunQ4tP1yF8ko75qMs5oV7XlsLd4EVkxjas5aXZoWu PzGD2a/aTvLkc6FWVxCnhup7SwVqhz1zsAnstjEwQTsvaAtKF/p+Uj/vS7PGQK3NX63s 7QetuFW/LKxCS9jhnRlW19fVV8Rqu0n1RVxKk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:x-mailer:content-transfer-encoding; b=EXLIR2zIggIuih2+bClJl8t/0UiaviF4BRGM0gB3nufJes1Xcjmmj0P/RvmLg31jlN 0EeXafJTFzkZ8MMsHW4mzM2nhiJJGm7CL7xCpy0pbx/kjG7eRTuYCZC4DfFcubdidzbr pa3Z+6/vGDMGDS4+v/ch4mYIV5pQ7RF6TVjiM= Received: by 10.204.66.130 with SMTP id n2mr1221828bki.175.1298575773889; Thu, 24 Feb 2011 11:29:33 -0800 (PST) Received: from [10.150.51.210] (gw0.net.jmsp.net [212.23.165.14]) by mx.google.com with ESMTPS id b6sm2346026bkb.10.2011.02.24.11.29.31 (version=SSLv3 cipher=OTHER); Thu, 24 Feb 2011 11:29:33 -0800 (PST) From: Eric Dumazet To: Dave =?ISO-8859-1?Q?T=E4ht?= In-Reply-To: <87sjvds2r7.fsf@cruithne.co.teklibre.org> References: <4D6668F4.5010705@freedesktop.org> <4D668827.8060508@freedesktop.org> <1298567313.2814.7.camel@edumazet-laptop> <87sjvds2r7.fsf@cruithne.co.teklibre.org> Content-Type: text/plain; charset="UTF-8" Date: Thu, 24 Feb 2011 20:29:29 +0100 Message-ID: <1298575769.2659.10.camel@edumazet-laptop> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 8bit Cc: Van Jacobson , bloat-devel@lists.bufferbloat.net, bloat@lists.bufferbloat.net Subject: Re: [Bloat] Please enter issues into the issue tracker - Issue system organisation needed. X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2011 19:29:51 -0000 Le jeudi 24 février 2011 à 11:31 -0700, Dave Täht a écrit : > I would really like a sane implementation of some basic tc scripts for > SFB and CHOKe to be out there. > > Dan Siemon's recent set of bufferbloat-related tests > > http://www.coverfire.com/archives/2011/02/21/network-latency-experiments/ > > appeared to invoke issues between multiple queuing disciplines when > using SFB. > Hmm.. hard to say because I personally use SFQ a lot, in ingress and egress. It's really good for many uses, but you also need a shaper above SFQ, of course ! Notes: - We had some bugs in SFQ that I fixed two months ago, take care ! - Its important to set TSO off (ethtool -K eth0 tso off), or else we send big packets (up to 64Kbytes) and this used to break SFQ fairness. This can really hurt latencies of interactive flows. Extract of SFQ changelog : commit 18c8d82ae5b802c5d82e0dfbcc08b1b568955f46 Author: Eric Dumazet Date: Fri Dec 31 12:48:55 2010 -0800 sfq: fix slot_dequeue_head() slot_dequeue_head() should make sure slot skb chain is correct in both ways, or we can crash if all possible flows are in use. Jarek pointed out slot_queue_init() can now be done in sfq_init() once, instead each time a flow is setup. Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller commit eeaeb068f1393b4db4861481bf594bcd1c3eda7a Author: Eric Dumazet Date: Tue Dec 28 21:53:33 2010 +0000 sch_sfq: allow big packets and be fair SFQ is currently 'limited' to small packets, because it uses a 15bit allotment number per flow. Introduce a scale by 8, so that we can handle full size TSO/GRO packets. Use appropriate handling to make sure allot is positive before a new packet is dequeued, so that fairness is respected. Signed-off-by: Eric Dumazet Acked-by: Jarek Poplawski Cc: Patrick McHardy Signed-off-by: David S. Miller commit ee09b3c1cff0335137dc1b146488e4352f640f13 Author: Eric Dumazet Date: Wed Dec 22 11:39:59 2010 -0800 sfq: fix sfq class stats handling sfq_walk() runs without qdisc lock. By the time it selects a non empty hash slot and sfq_dump_class_stats() is run (with lock held), slot might have been freed : We then access q->slots[SFQ_EMPTY_SLOT], out of bounds, and crash in slot_queue_walk() On previous kernels, bug is here but out of bounds qs[SFQ_DEPTH] and allot[SFQ_DEPTH] are located in struct sfq_sched_data, so no illegal memory access happens, only possibly wrong data reported to user. Also, slot_dequeue_tail() should make sure slot skb chain is correctly terminated, or sfq_dump_class_stats() can access freed skbs. Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller commit eda83e3b63e88351310c13c99178eb4634f137b2 Author: Eric Dumazet Date: Mon Dec 20 12:54:58 2010 +0000 net_sched: sch_sfq: better struct layouts Here is a respin of patch. I'll send a short patch to make SFQ more fair in presence of large packets as well. Thanks [PATCH v3 net-next-2.6] net_sched: sch_sfq: better struct layouts This patch shrinks sizeof(struct sfq_sched_data) from 0x14f8 (or more if spinlocks are bigger) to 0x1180 bytes, and reduce text size as well. text data bss dec hex filename 4821 152 0 4973 136d old/net/sched/sch_sfq.o 4627 136 0 4763 129b new/net/sched/sch_sfq.o All data for a slot/flow is now grouped in a compact and cache friendly structure, instead of being spreaded in many different points. commit aa3e219997e4b949be4199660936099ded0b401f Author: Eric Dumazet Date: Mon Dec 20 13:18:16 2010 -0800 net_sched: sch_sfq: fix allot handling When deploying SFQ/IFB here at work, I found the allot management was pretty wrong in sfq, even changing allot from short to int... We should init allot for each new flow, not using a previous value found in slot. Before patch, I saw bursts of several packets per flow, apparently denying the default "quantum 1514" limit I had on my SFQ class.