Jonathan Morton <[email protected]> writes: >> On 16 Jul, 2018, at 1:41 am, Kevin Darbyshire-Bryant >> <[email protected]> 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 _______________________________________________ Cake mailing list [email protected] https://lists.bufferbloat.net/listinfo/cake
