From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-bk0-f43.google.com (mail-bk0-f43.google.com [209.85.214.43]) (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 13B0D21F0A7 for ; Tue, 21 Aug 2012 01:38:24 -0700 (PDT) Received: by bkty15 with SMTP id y15so3972770bkt.16 for ; Tue, 21 Aug 2012 01:38:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:x-mailer:content-transfer-encoding; bh=oiyQ0IGEgDDpOIsT21aNHzyEar3RBhQZUKtTT4JLs5I=; b=fXfvfRrP+QtWVqSO/8CTaxGG0IKbBExvkcH4eHJccCzLQloAEY5pg0pvpVt9REHMpm hhbsUXXZ8pOgHmIrFQsjMxcXbxTtp0L9Jtd7spnl/64sG4/BiIahgKyotB7zwkJefrmB LZ3XUNgXmdWTnmpoKBoCtrNkoKJzpWYbSmsZYVBOHuxEFo8r76iEt8OOmLDHTe1SV9EP Kj4pMVHhaCUQrJMGAzpuvEpsfbMNyy7QW1gvgvcwgHjf+UtYpQoHjvyP+wakld46hB9n hGisBnU+cKlBueHLXtOU9X0pxUx95tQhc0RcTof0Pvpc6rCFg/TpBFPHEaEQUqHd96RH F15w== Received: by 10.205.127.77 with SMTP id gz13mr5050047bkc.17.1345538302606; Tue, 21 Aug 2012 01:38:22 -0700 (PDT) Received: from [172.28.91.230] ([74.125.122.49]) by mx.google.com with ESMTPS id j9sm356166bkv.0.2012.08.21.01.38.20 (version=SSLv3 cipher=OTHER); Tue, 21 Aug 2012 01:38:21 -0700 (PDT) From: Eric Dumazet To: Dave Taht In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Date: Tue, 21 Aug 2012 10:38:18 +0200 Message-ID: <1345538298.5158.401.camel@edumazet-glaptop> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Cc: netdev , codel@lists.bufferbloat.net 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: Tue, 21 Aug 2012 08:38:25 -0000 On Mon, 2012-08-20 at 14:05 -0700, Dave Taht wrote: > We've had a raft of deployment questions regarding fq_codel, memory > use, and the impact of unresponsive flows > over on the cerowrt development list. > > sort of summary of the thread here, with some codel related ideas > > https://lists.bufferbloat.net/pipermail/cerowrt-devel/2012-August/000423.html > > some early data on wifi interactions here > > https://lists.bufferbloat.net/pipermail/cerowrt-devel/2012-August/000407.html > CC netdev codel / fq_codel have a packet limit per qdisc, like any other linux qdisc. DEFAULT_CODEL_LIMIT = 1000 packets fq_codel : 10240 packets For memory constrained boxes, it would be wise to add a 'truesize' limit Not a bytes limit based on skb->len sum, because a skb->len = 60 bytes packet might consume far more memory (more than 2 Kbytes) ath9k driver is known to deliver very fat skbs (skb->truesize is too big) One 'other way' to limit bloat would be to reallocate skbs when one qdisc begins to use more than 25 % of its truesize limit enqueue(q, skb) { if (q->truesize_sum > q->truesize_limit / 4) skb = skb_reduce_truesize(skb, GFP_ATOMIC); ... } This is what some drivers already do in their rx handler (this is called copybreak), but this would do the copy (and extra cpu cost) only in stress situations. Note : we also have a very big struct skb_shared_info (320 bytes), we probably could shrink it for packets without fragments.