From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (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 E7C0B21F2B9 for ; Tue, 3 Nov 2015 09:46:43 -0800 (PST) Received: from hms-beagle.home.lan ([217.237.68.126]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MJWAZ-1ZsIsx2l9n-0031qC; Tue, 03 Nov 2015 18:46:36 +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: <87fv0nasy5.fsf@toke.dk> Date: Tue, 3 Nov 2015 18:46:35 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: 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> <87si4natbf.fsf@toke.dk> <87fv0nasy5.fsf@toke.dk> To: =?windows-1252?Q?Toke_H=F8iland-J=F8rgensen?= X-Mailer: Apple Mail (2.1878.6) X-Provags-ID: V03:K0:RNg7r/fdMw41vXItyLrwGV4xXykV//10S71oXOqBQ9UsnQmaks3 vfeo0zFEroddahYbyYpCDcbhdTuQZa6prsLPgzMN6Pj6NksMlEGox2l0wC4CCebjJBNXaLs v/+eWcWcU42WgIzfi6vrQRJFHUMtKMyg2bIN3cyyhuie7/j2Sghu5Vuau4R+pf4X9GOT3PO 9aZjI6V+k7uAsuugNFDcQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:Qms4oDANAl8=:mJ8STVOaZTjJYfQtq0PSdJ TbQBlmFJhMt85noYkDzyWvRSpE4RIEBZ5S48aMStFTJ0C8LEce7qLSkfGcD2t9ro75O+DnD3M Ha6OMbLfUs3Z2TOfGkVeQ6PuRL1GGXpKuv8FuxvLdBDQw7crouR0XYs85JufW4EWftA0iNMZJ ZQnIijZidVrgalFrPRQBlfKjOeyVNm1SrKWY1h2tAcPnt9dttZVdDxIEiwCBfOdNlDHR5O9Uy 5RHK1McT8ctwc6W1iizVIQttj8+gjrg8/5kDMm4H+wKP+e8obKeCS2k4ZumgbLY9rsklRfdZJ 6Kpki7kUlCKSEpX1T8xWbYLvTjPvzlsyVKwIo4Fpvj59+vrmyA3si88a/JNm2Jx5R+j5jaR5/ bmKBGZSzjuYl7F3Y8J1IkQ+raqcOlCKw7XJGKHgqkw62vVksUj2Z0W+MIcwAfIt8J9iEIcBs2 ERIxad+asjM0RmL+e/43V0d3Y+7KgDnI62XXpYinCUFiE/ES5uPR9CEc3zpzdvx7NNp3QNcA1 afs2Hh7ZnpdkrmFnhBG5aKqy9+wwMQf0q8QxnDhdCLEokBWBOiM6jsJ6m59Ycj/GEnDaOAXLg 7auFhWiqyK3qwerqlE9VQiC3rIaGGF9z4vWpGLedHMpK2AgkzFL1814HLv5AP3XlAqZy5Mv9a qYy0kV4ur98yv8JPt9VM7sEdIFY8DJ0m7UNB5czXEUYadqEh01Li7+5yJUV0PrVzrUR8YKW3T 0fNmbGHqEgn3c/1IqIQg9s6fvnLs/rThlfI1gNVjyhrFq6bwpCd1DPzztXhwDrcKSTVVOIcB/ sAKcxcB 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:47:06 -0000 Hi Toke, On Nov 3, 2015, at 18:33 , Toke H=F8iland-J=F8rgensen = wrote: > Jonathan Morton writes: >=20 >>> Which is the same data that Cake uses. Hmm, weird=85 >>=20 >> No, Cake uses skb->truesize for this particular purpose. It uses >> qdisc_pkt_len(skb) only for timing purposes. >=20 > Ah, right. Well, I would consider that a bug. If we're doing a "max > queue size" it should (conceptually) be in packet data units. A hard > memory limit may make sense *in addition*, but then that should be a > separate safeguard IMO. I guess I have constantly been talking about a different limit = than you, sorry. I was and still am advocating for the hard memory = limit. But I maintain that as the kernel typically uses 2KB skis per = packet (independent of packet size, as long as MTU =3D 1500 or so) the = packet limit will also do double duty as memory limit. Then again the = max queue size in packets is more an implementation thing in my mind ;) = I believe the only people changing limit will not be people thinking = about how many packets they want queued maximally, but rather those that = want to avoid OOM; from that view a memory limit seems quite natural. So = maybe we need a min(max_packets, consumed_queue_memory) as true limit? = Potentially with a notification if there is a large effective difference = between the two? Best Regards Sebastian >=20 > -Toke