From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 7063D21F394 for ; Sun, 22 Mar 2015 05:51:50 -0700 (PDT) Received: from hms-beagle.home.lan ([87.164.165.7]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0LbMmA-1ZEjKT3LEA-00kxlK; Sun, 22 Mar 2015 13:51:47 +0100 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: <750FA673-E20D-4D48-9386-097D32CD31FB@gmail.com> Date: Sun, 22 Mar 2015 13:51:45 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <51665FD7-629A-4B8C-B258-2E9AF8E3B5D0@gmx.de> 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> To: Jonathan Morton X-Mailer: Apple Mail (2.1878.6) X-Provags-ID: V03:K0:qSiEZ5G9eU0JZDJvk9YbS3++XZMMwOveSuiNm8AmQPbe8wbY5DG vVWatZpKpvioKiV4TkQLqU6BoTVNHx2smgB1V/pl6Ci2LZAQwkozKd/G/F5IkEg14tE83oD g+9JxfRxEeM3ZuO45X4Pfmi77ZPacvOy8rg9eslCX6maUj3DW7VG58v5x7aa7YTx6BFiJNT c0jPwnmHyKa0GYrKnJsaw== X-UI-Out-Filterresults: notjunk:1; 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 12:52:20 -0000 Hi Jonathan, On Mar 22, 2015, at 11:43 , Jonathan Morton = wrote: >=20 >> 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? 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. >=20 >> (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. 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 ;) )? Best Regards Sebastian >=20 > - Jonathan Morton >=20