Re: [Cake] Backporting 'tc class' support

["Toke Høiland-Jørgensen" <toke@toke.dk>]

Jonathan Morton <chromatix99@gmail.com> writes:

>> On 16 Jul, 2018, at 1:41 am, Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk> 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