Re: [RFC/T][PATCH 1/3] rc80211-pid: introduce rate behaviour learning algorithm

[Mattias Nissler <mattias.nissler@gmx.de>]

On Tue, 2007-12-11 at 15:52 +0100, Johannes Berg wrote:
> > > 2) that can be changed in userspace, but we couldn't figure out a scenario
> > > where it would make any sense. Johannes, any comments? Wouldn't it make
> > > sense to just forbid to change this in userspace?
> > 
> > I don't agree. For example, what if you have some broken 802.11b only
> > hardware that you desperately need to get going, but it freaks out on
> > 802.11g encoded frames. Now if your AP is hostapd on a Linux machine,
> > you'll want to change the mode. Hence, also the number of available
> > rates change.
> > 
> > Moreover, I think we can do better than just disallowing changes to the
> > rate set, don't you think?
> 
> All of this is going to change anyway, but disallowing mode/rateset
> changes while associated is definitely the right thing to do.

Just to sum up the issue for Johannes: Stefano's patch adds per-rate
information to the PID algorithm state. This is fine, however we need to
make sure the rate control algorithm gets reinitialized when the number
of rates changes (i.e. due to a mode change, what about about regulatory
domain changes?), as otherwise we might be indexing array entries we
don't have allocated. Now this spawned the more general discussion about
when the stack should allow changing modes etc.

So let's go back to the original issue: Johannes, can we assume rate
control always gets reinitialized when the number of rates or even the
hardware mode is changed?

Mattias