From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.toke.dk (mail.toke.dk [IPv6:2001:470:dc45:1000::1]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 7C1D93B29E for ; Mon, 16 Jul 2018 05:30:56 -0400 (EDT) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1531733455; bh=HH2/r8Cvie6IEHLb2BXucOSL9APJFC6hO1b9iIsJDwM=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=CgGUyVnE6R1MPEclk1u+DohtsQVOog/mJCiMcUAH0H7dk7mwtzz/LHYIs5vRzC3iM erduoG16M3fFB430myDO0A9eE7IOKOqAyERwnw/5R/sN6el0mAcQ50afJViFrTnQSl RsST+U4wiXb4vftqkpzciCrC5qov6w0aAYJgOB8NbkB0i/WM09JqoihoBiyAzwtXgw raobc1mPNAusghNqcUsG2aURgncevsEGS1LWLcPerv41kbYfpSkHg86cfuSej7ODAK DAxLWIBKWB/1y/R9DBxLkm7vQe++wo7bCpZJUDo8lSlkNaNVFBr6IIdH8EhTKJPCHd SQhSMlCMU5qoQ== To: Jonathan Morton , Kevin Darbyshire-Bryant Cc: "cake\@lists.bufferbloat.net" In-Reply-To: References: <8736wla3lq.fsf@toke.dk> <4C12C6A1-84E3-4B78-885F-F5C212CD13FF@darbyshire-bryant.me.uk> <87wotw96el.fsf@toke.dk> <83B2AEF4-C052-444F-8AFA-E8C3EE2F4A7F@darbyshire-bryant.me.uk> <87wotw6yeo.fsf@toke.dk> Date: Mon, 16 Jul 2018 11:30:51 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87o9f77cj8.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Cake] Backporting 'tc class' support 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: Mon, 16 Jul 2018 09:30:56 -0000 Jonathan Morton writes: >> On 16 Jul, 2018, at 1:41 am, Kevin Darbyshire-Bryant wrote: >> >> AFAICT the tin order makes no difference whatsoever these days, >> indeed the dequeue mechanism picks up from the last tin and spins >> around rather than starting at either 0 or highest tin each time. > > While it might not be entirely apparent from the code, the tin > selector has two-phase behaviour, and this makes the tin ordering > important. > > If *any* tin contains traffic *and* meets its local schedule, the > *highest* such tin is selected unconditionally. Only if *no* such tin > can be found does the search revert to finding the tin with traffic > and with the most-nearly-satisfied schedule. Both conditions are > resolved on a single pass through the tin array. > > In diffserv3/4, the Best Effort tin is set at the same rate as the > global shaper. Therefore, its local schedule is always met whenever > the global schedule is. Therefore, if it were placed higher in the tin > list than Bulk, it would be able to strictly starve out Bulk traffic, > which is not what I want. Instead I give Bulk the next higher tin and > a very restrictive schedule. Right, this makes sense. Still doesn't give an obvious answer to what the semantics for a filter should be, though. On the one hand, everywhere else we expose tins to userspace, we obey tin_order. On the other hand, the "first tin is the default (best effort)" semantic is used for the internal matching, such as diffserv. I'm leaning towards making tc filter classification obey tin_order; opinions? :) -Toke