From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-we0-f171.google.com (mail-we0-f171.google.com [74.125.82.171]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 5AFEC200AA1; Mon, 27 Aug 2012 08:12:49 -0700 (PDT) Received: by weys43 with SMTP id s43so3320174wey.16 for ; Mon, 27 Aug 2012 08:12:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=DUeBs2cLAfJhQ/Sn5CjMyZkvWq5V3Enp7YeVBgJHc5M=; b=GAolC5waFrBhnyZQNamo8GnKJPxGcsM8ynjxw/X+dH7l52HqYpiaWGOH6UPogEqoCa H5CvTob29CXQ4AP2kcjEHY69f4Z/rw7KhOYSUFKIbRc1n3V/V0FBg5EvkblES/AKezQm 3vcTewwdvOF5bjSR+0+le5REKXE22E2LfOXa60qNm+7IxhIcEkbtGabiYJNcid25QUWu LF5EOMtW17R54WJfm7FFJcZGufVwPqM5jVGjwGmoMV+2w05x+fy/kEtU1gHG07UVbRri gIuU8qlENjzAH3uXNllAzPxtDaUu1Xiyd959U5RswXsvpLqLK9IC/Sp1MtK6B0bLrYfp XXGw== MIME-Version: 1.0 Received: by 10.180.109.129 with SMTP id hs1mr26299304wib.0.1346080367346; Mon, 27 Aug 2012 08:12:47 -0700 (PDT) Received: by 10.223.159.134 with HTTP; Mon, 27 Aug 2012 08:12:47 -0700 (PDT) In-Reply-To: <1346067425.2420.167.camel@edumazet-glaptop> References: <1345538298.5158.401.camel@edumazet-glaptop> <1346067425.2420.167.camel@edumazet-glaptop> Date: Mon, 27 Aug 2012 08:12:47 -0700 Message-ID: From: Dave Taht To: Eric Dumazet Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: codel@lists.bufferbloat.net, cerowrt-devel@lists.bufferbloat.net, Felix Fietkau Subject: Re: [Codel] coping with memory limitations and packet flooding in codel and fq_codel X-BeenThere: codel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: CoDel AQM discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 15:12:50 -0000 On Mon, Aug 27, 2012 at 4:37 AM, Eric Dumazet wrot= e: > On Sun, 2012-08-26 at 14:36 -0700, Dave Taht wrote: > >> From looking over the history of this idea, it does seem to be a good >> idea for small devices with potentially big queues. >> >> http://www.spinics.net/lists/netdev/msg176967.html >> >> That said I do tend to agree with davem's summary in fixing the >> wifi drivers in the first place. The current allocation in the ath9k dri= ver >> doesn't make any sense in the first place, which (to me) implies magic >> lies underneath that I'm reluctant to fiddle with, without deep knowledg= e >> of how the ath9k driver behaves with wep/wpa/ampdus, etc. >> > > Problem is some hardware cannot do this in a smart way, without paying > the price of a sometime expensive copy. > > Thats why I refined this idea to actually trigger only if current > memory needs are above a threshold. Concur. However, rather than implement truesize +/- accounting in the qdisc, which seemed potentially hairy, I just did a: static int codel_qdisc_enqueue(struct sk_buff *skb, struct Qdisc *sch) { struct codel_sched_data *q =3D qdisc_priv(sch); int qlen; if (likely((qlen =3D qdisc_qlen(sch)) < sch->limit)) { if (qlen > sch->limit / 8) skb =3D skb_reduce_truesize(skb); As I am also typically lowering the fq_codel limit to 1024 or 1200 from the default of 10k, this will kick in at a pretty appropriate time, there too, after I add the code... And that said this stuff is totally unneeded on bigger iron. Last year we were safely stuffing 10s and 100s of MB into the tx queue rings without issues... ( :) > If packets are received and immediately consumed, without potentially > staying a long time in a queue, it doesnt really matter they use 200 or > 400% more ram than the rightly sized packets. +1 > > > --=20 Dave T=E4ht http://www.bufferbloat.net/projects/cerowrt/wiki - "3.3.8-17 is out with fq_codel!"