From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.taht.net (mail.taht.net [IPv6:2a01:7e00::f03c:91ff:feae:7028]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 70EBE3B2A4 for ; Tue, 21 Nov 2017 14:00:00 -0500 (EST) Received: from nemesis.taht.net (unknown [IPv6:2603:3024:1536:86f0:2e0:4cff:fec1:1206]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.taht.net (Postfix) with ESMTPSA id A726021341; Tue, 21 Nov 2017 18:59:58 +0000 (UTC) From: Dave Taht To: Jonathan Morton Cc: cake@lists.bufferbloat.net References: <1510945885-9986-1-git-send-email-dave.taht@gmail.com> <1510945885-9986-3-git-send-email-dave.taht@gmail.com> <8760a81y3s.fsf@nemesis.taht.net> <91830311-fea3-cb03-be2e-b132ae54ad89@gmail.com> Date: Tue, 21 Nov 2017 10:59:57 -0800 In-Reply-To: <91830311-fea3-cb03-be2e-b132ae54ad89@gmail.com> (Jonathan Morton's message of "Tue, 21 Nov 2017 00:52:08 +0200") Message-ID: <873757v4nm.fsf@nemesis.taht.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Cake] [RFC PATCH 2/3] Add cake related includes and source files X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Nov 2017 19:00:00 -0000 Jonathan Morton writes: > On 17/11/17 21:52, Dave Taht wrote: >> Actually using **to_free sanely (here, in qdisc_reduce_backlog, etc) >> would be good. I like very much how fq_codel does bulk dropping now. >> >> I think, but am unsure, that the whole heap concept would just "go", >> in that case. > > I don't see how. My principal point was that the bulk_drop facility now in fq_codel was very cpu efficient. I'm willing to keep this, but I'd like to see it benchmarked under the same udp_flood scenarios as what prompted that change to fq_codel - Say, a 1Gbit flood into a 10 or a 100Mbit shaped connection. > The max-heap is not used to keep track of packets to drop, but which queue is > the longest. If a single flow goes completely crazy, that allows dropping a lot > of packets from *that* queue without having to search over the others every > time. At the same time, if the queues are more evenly filled, it still allows > the longest queues to be trimmed without overly penalising whichever queue > happened to get caught at the wrong moment. > > In cases where several packets need to be dropped to maintain the backlog limit, > those packets already end up on 'to_free' correctly. Isn't that how it's > supposed to work?