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 C7BFF21F4E2 for ; Tue, 3 Nov 2015 03:57:54 -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=1446551871; bh=HCDpsf4/KpsfwxLJuOAgCcoGputGWDDLAKVfxSVc+sU=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=nWwJEW/z/nynxnwByDUTU2bWDRW2l1+0TYKRz43OmBdo3wHU8ZyghVqMIb8ged23z iJRqw0tLRwpICkO3CX0/QDpIeazO/kWrINqEZwxewIzdtgA1zupdJk9SpkMunXJ/YK np/7BZJK1w1Avr2z3I9EG5u4RBCu8hD8qzPFnSso= Received: by alrua-kau.kau.toke.dk (Postfix, from userid 1000) id 80BCFC402A1; Tue, 3 Nov 2015 12:57:50 +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> Date: Tue, 03 Nov 2015 12:57:50 +0100 In-Reply-To: (Sebastian Moeller's message of "Tue, 3 Nov 2015 09:20:40 +0100") X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87ziyvnvlt.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 11:58:17 -0000 Sebastian Moeller writes: > Well, I believe one of the next steps needs to be to expose limit to > user-space, No, just throwing the problem to user space is not a solution: it's a cop-out. We need to fix the issues so things actually work, and then *maybe* expose the value to userspace if there is a real need for it. Not just go "meh, let userspace sort it out"; that is horrible design. > which would have Toke allowed his measurements No, it would not: I'm not trying to test whether we have a qdisc that, through arcane configuration options, can be made to behave properly. That already exists in fq_codel+HTB. What we're doing here is trying to build a no-knobs qdisc here that works well in all the scenarios we can think of. So let's make sure it does, and then talk about whether a variable should be exposed *after* we've done proper auto-tuning. > and would have followed the example of most/all other leaf qdiscs and > put policy into user space where it arguably belongs=E2=80=A6 Packet limit is not policy, it's an implementation detail. If you don't have the memory to run at 100Mbps / 1 second, then *set those values lower*. You're not going to achieve it anyway if you don't have the buffer space. Same thing with the target parameter, BTW: The fact that we still haven't got it right is not an argument for exposing it to userspace, quite the contrary: If we, the experts, can't even get it right, why on earth would be expect users to? -Toke