On 05.06.22 19:18, Toke Høiland-Jørgensen wrote:
Felix Fietkau <nbd@xxxxxxxx> writes:
The airtime weight calculation overflows with a default weight value of 256
whenever more than 8ms worth of airtime is reported.
Bigger weight values impose even smaller limits on maximum airtime values.
This can mess up airtime based calculations for drivers that don't report
per-PPDU airtime values, but batch up values instead.
Fix this by reordering multiplications/shifts and by reducing unnecessary
intermediate precision (which was lost in a later stage anyway).
The new shift value limits the maximum weight to 4096, which should be more
than enough. Any values bigger than that will be clamped to the upper limit.
Signed-off-by: Felix Fietkau <nbd@xxxxxxxx>
The weights are UAPI, so I guess we could run into applications that
expect to be able to set a weight higher than 4096? I don't think this
is too likely, but maybe it is better to reject such attempts instead of
silently clamping the value, to flush out any breakage if it does occur?
Will do this in v2.
Thanks,
- Felix
