Re: [RFC] mac80211: Dynamically set CoDel parameters per station.

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

Felix Fietkau <nbd@nbd.name> writes:

> On 2016-09-08 21:59, Toke H=C3=B8iland-J=C3=B8rgensen wrote:
>> CoDel can be too aggressive if a station sends at a very low rate. This
>> gets worse the more stations are present, as each station gets more
>> bursty the longer the round-robin scheduling between stations takes.
>>=20
>> This is an attempt to dynamically adjust CoDel parameters per station.
>> It takes a rather simple approach and uses a simple binary designation
>> of a station as 'slow' if it has expected throughput less than eight
>> Mbps (i.e. the lowest couple of rates). In this case, CoDel is set to be
>> more lenient by adjusting its target to 50 ms and interval to 300 ms.
>> There's a built-in hysteresis so a station cannot flip between slow and
>> fast more than once every two seconds.
>>=20
>> In this version the check is performed every time a packet is enqueued
>> to the intermediate queues; and the overhead of doing this is alleviated
>> a bit by caching the result and by the above-mentioned hysteresis. It
>> can probably be smarter about both when and how to do the scaling, but
>> this seems to alleviate some of the starvation I've seen with very slow
>> stations.
> Since this is not dealing properly with firmware rate control anyway,
> I'd suggest calling the update from rate_control_set_rates in order to
> avoid putting more stuff into the tx hot path.

Yeah, I wasn't expecting that to stay in the TX path, but was not
familiar enough with minstrel to know where a good place would be.
Thanks for the pointer.

> You could add a separate code path to allow firmware rate control
> devices to provide a hint at a convenient point in time.

There's already a get_expected_throughput() driver hook; but no drivers
seem to be using it? But I assume you mean a hook the other way, i.e.
export a function where the driver can tell mac80211 "my expected
throughput changed, please update"?

-Toke