From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail2.tohojo.dk (mail2.tohojo.dk [77.235.48.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id 8831621F547 for ; Tue, 3 Nov 2015 09:25:44 -0800 (PST) X-Virus-Scanned: amavisd-new at mail2.tohojo.dk DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=201310; t=1446571541; bh=H8RIHAYmeIOIJLq7Pi5Zqp9eM1Kh5pFKEs5QpQpQTos=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=cQGlzyww6UrEKdYrK2nEbR1znjAI7Ra78nXY49QZ1r2URHcsk/xD2px0o5ROfje79 9GfE3TDgTJYrrk+3Ds595dsOAsvmICF5TadAwoRWd2zLlKHOktlzIpNTOZ9gXKNGNb 0lLIYFtspMs78yvHjBflP3pi8JkDvKd6XWn2k5kQ= Received: by alrua-karlstad.karlstad.toke.dk (Postfix, from userid 1000) id A38614E6C78; Tue, 3 Nov 2015 18:25:40 +0100 (CET) From: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= To: Sebastian Moeller References: <87pozspckj.fsf@toke.dk> <6A2609D9-7747-487B-9484-ECC69C50DE96@gmx.de> <874mh3pai9.fsf@toke.dk> <50C2A7B7-1B81-41E1-B534-CA449296FE77@gmail.com> <87a8qvc8tz.fsf@toke.dk> <328DEF4F-F149-42C5-920E-53D16DCF544C@gmx.de> Date: Tue, 03 Nov 2015 18:25:40 +0100 In-Reply-To: <328DEF4F-F149-42C5-920E-53D16DCF544C@gmx.de> (Sebastian Moeller's message of "Tue, 3 Nov 2015 18:11:30 +0100") X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87si4natbf.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: cake@lists.bufferbloat.net Subject: Re: [Cake] Long-RTT broken again X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.13 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, 03 Nov 2015 17:26:07 -0000 Sebastian Moeller writes: >> Right, well, in that case fixing the calculation to use the actual >> packet size would make sense in any case? > > Would it? I thought actually using the amount of =E2=80=9Cpinned=E2=80=9D= kernel > memory would be more relevant, it a ACK packet pins 2KB then it should > be accounted at 2KB, IF the goal of the accounting is to avoid > un-scheduled OOM, no? And if something like Dave=E2=80=99s patch kicks in= that > copies larger mostly empty skbs to smaller sizes, these packets then > should be accounted with that smaller size. In anyway I believe with > default kernels there is a strong correlation between a packet count > limit and a byte count limit=E2=80=A6 No, a limit on a qdisc is in terms of the packets we are transmitted. We can't expect the user to know how much memory the kernel actually allocates to an skb in order to configure their package queue. If someone configures a limit, they are going to do a BDP calculation, input that, and complain when that doesn't work. FWIW, this is what the in-kernel FIFO qdisc does when configured in byte mode: if (is_bfifo) limit *=3D psched_mtu(qdisc_dev(sch)); on init and if (likely(sch->qstats.backlog + qdisc_pkt_len(skb) <=3D sch->limit)) return qdisc_enqueue_tail(skb, sch); on enqueue. Which is the same data that Cake uses. Hmm, weird... -Toke