From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yk0-x232.google.com (mail-yk0-x232.google.com [IPv6:2607:f8b0:4002:c07::232]) (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 D85F721F5DA for ; Tue, 3 Nov 2015 11:17:22 -0800 (PST) Received: by ykft191 with SMTP id t191so33102220ykf.0 for ; Tue, 03 Nov 2015 11:17:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lIoOvzZFwubN1jsQBhiFhdUvfeAtkvniVyN+1rgSKjA=; b=PHU31A96/Zjn9HkVDetMT6myMwl+c6zKUcOXoMNK+LrlgNK4St6ikqDCI3QL7yBnsB LKmzClIVjgnqo+/OkMnC/zZ7UQpJLcC+Z4p5u1BfrJM/h1ljkEPH2VtMV9SSOl3al8T8 cea3aFtaanmPSoQq/o2npVGhwGYbLnPaaxuEB/+TcwP7SBLQsZVhGpIIuP++K/JHO/u5 gKNyTocBDca2tkFkfyccr45ta44kJtJIlGseWPzb1eHmPgfpDUrGDj8Wj3lYOEBRclDq 0svKLyvmCw/aDOPolmcXxAHfrXgxapwIUV+fVg73jjL42KVIQI3vYocdkazjr667avbg 7iSw== MIME-Version: 1.0 X-Received: by 10.129.156.23 with SMTP id t23mr21443864ywg.151.1446578241473; Tue, 03 Nov 2015 11:17:21 -0800 (PST) Received: by 10.37.41.130 with HTTP; Tue, 3 Nov 2015 11:17:21 -0800 (PST) Received: by 10.37.41.130 with HTTP; Tue, 3 Nov 2015 11:17:21 -0800 (PST) In-Reply-To: <0E86DECF-C583-4414-95CF-8F145D7E82D7@gmx.de> 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> <878u6fas88.fsf@toke.dk> <64F71419-78F8-465F-B43E-D0F2CF08AB19@gmx.de> <8737wnarzp.fsf@toke.dk> <87twp39d61.fsf@toke.dk> <0E86DECF-C583-4414-95CF-8F145D7E82D7@gmx.de> Date: Tue, 3 Nov 2015 21:17:21 +0200 Message-ID: From: Jonathan Morton To: Sebastian Moeller Content-Type: multipart/alternative; boundary=94eb2c0b8ce83920f30523a7beff 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 19:17:45 -0000 --94eb2c0b8ce83920f30523a7beff Content-Type: text/plain; charset=UTF-8 Conceptually, I think limiting actual memory usage is the right thing to do. Ideally, the allocations would turn out closer to the actual packet sizes, but by watching the allocated size, we will automagically take advantage of improvements in this area - which must happen elsewhere in the kernel. Limiting total on-wire packet bytes is nice from a theoretical point of view, but we don't live in a theoretical world. The performance discrepancy shouldn't be as big as it is. Limiting packet count is wrong and awful and we shouldn't do that, even if everyone else does. The fact that counting allocated bytes behaves the same way at the moment is unfortunate. - Jonathan Morton --94eb2c0b8ce83920f30523a7beff Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Conceptually, I think limiting actual memory usage is the ri= ght thing to do.=C2=A0 Ideally, the allocations would turn out closer to th= e actual packet sizes, but by watching the allocated size, we will automagi= cally take advantage of improvements in this area - which must happen elsew= here in the kernel.

Limiting total on-wire packet bytes is nice from a theoretic= al point of view, but we don't live in a theoretical world.=C2=A0 The p= erformance discrepancy shouldn't be as big as it is.

Limiting packet count is wrong and awful and we shouldn'= t do that, even if everyone else does.=C2=A0 The fact that counting allocat= ed bytes behaves the same way at the moment is unfortunate.

- Jonathan Morton

--94eb2c0b8ce83920f30523a7beff--