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 D972F21F319 for ; Sun, 22 Mar 2015 08:29:52 -0700 (PDT) Received: by labe2 with SMTP id e2so42162939lab.3 for ; Sun, 22 Mar 2015 08:29:50 -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=k0WeeknRJYIaxfVlvraLeyLplGknwDs3qadaQC5qT20=; b=SBGpAI2A8bltJM4ltHXGcO+taaVRkBW+A5VeksQtzdAPHNDCZpooM2WP5NHcXPDXik oIOJkVcAsLcr0IdIndOijk1x4106EJeX98NsXjfuuROTQ8xQvWe43JlUjQezrk5W2srV oBuRSN8IP0TbH/JoCgN6kSpuhY6DDtFWgUJamzvMi61tqNekRqZ28i/kGpIDcb2eIeEN S2n/whRYfsYhZgpaW3eh5xUZeNgIcLgnUwQb8WLaDAw5DulHT8q+oF1Y0XpaO1hecvUz wiwUadTRGqtmeWB+2FjvwaxAjqW9kIW5d4OEi4NjwWGo6byOBfEessy0SPIUIFPnmv9K OAYA== X-Received: by 10.152.7.212 with SMTP id l20mr68819182laa.68.1427038190510; Sun, 22 Mar 2015 08:29:50 -0700 (PDT) Received: from bass.home.chromatix.fi (37-136-93-223.rev.dnainternet.fi. [37.136.93.223]) by mx.google.com with ESMTPSA id m4sm2070247lae.47.2015.03.22.08.29.48 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 22 Mar 2015 08:29:49 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Jonathan Morton In-Reply-To: <51665FD7-629A-4B8C-B258-2E9AF8E3B5D0@gmx.de> Date: Sun, 22 Mar 2015 17:29:45 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6AA447D2-6148-464C-908D-98160A0E24C7@gmail.com> References: <7081A75C-899A-4DB7-8D77-935A37B362D8@gmail.com> <5509957B.30600@pollere.com> <491C7497-BE3E-452B-A797-C7FC1102E7ED@gmail.com> <750FA673-E20D-4D48-9386-097D32CD31FB@gmail.com> <51665FD7-629A-4B8C-B258-2E9AF8E3B5D0@gmx.de> To: Sebastian Moeller X-Mailer: Apple Mail (2.2070.6) Cc: "codel@lists.bufferbloat.net" Subject: Re: [Codel] The next slice of cake 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: Sun, 22 Mar 2015 15:30:21 -0000 >>> On 22 Mar, 2015, at 11:39, Sebastian Moeller = wrote: >>>=20 >>> I could be out to lunch here, as usual,;but I argue the byte limit = should include the kernel overhead (could this be based on = skb->truesize) as this is what counts against real memory. My assumption = here is that in normal operation we rarely/never get queues to fill up = to the limit anyways >>=20 >> Such an argument could certainly be made. Does skb->truesize include = the skb header, as well as the buffer space allocated? >=20 > According to http://vger.kernel.org/~davem/skb_sk.html (=93We = keep track of how many bytes of system memory are consumed by a packet = in 'skb->truesize'. This is the total of how large a data buffer we = allocated for the packet, plus the size of 'struct sk_buff' itself.") it = looks like this should be the right number, but I am not well versed in = reading kernel code, so there might be some caveats I am not aware of. The statement in that commentary seems to be authoritative enough to = rely on. >>> (as tho would turn the queue into tail-drop effectively) >>=20 >> But fq_codel (and cake) are a little cleverer than that, even when = they hit the hard limit. They still drop from the head, and they shoot = the longest flow-queue first. >=20 > Excellent, learned something new today; in fq_codel does this = come from the per-codel instance 1000 packet limit or from the default = fq_codel 102400? packet limit (just in case someone knows off hand, I = can try to understand the kernel code myself, given enough time ;) )? Off the top of my head, most likely both. (If a per-queue limit is hit, = then by definition that=92s the longest queue.) I should probably re-read the code to be certain of that, though. I=92m = currently eyeball-deep in running software updates on half a dozen very = obsolete machines, and cracking the cases on half a dozen routers to see = what hardware they=92ve got inside. So far I think *one* of them has = actually matched what the OpenWRT database lists, and even then there=92s = an obvious error. - Jonathan Morton