Re: rework on .flush() callback

[Johannes Berg <johannes@sipsolutions.net>]

On Fri, 2012-11-16 at 18:08 +0100, Arend van Spriel wrote:
> On 11/16/2012 02:34 PM, Johannes Berg wrote:
> >> The problem here is that in brcmsmac the flush does the
> >> >ieee80211_wake_queues() call, because that could also wakeup the netif
> >> >queues. So doing it in the driver seems a bad idea. Any suggestion on
> >> >how to solve this?
> > Yeah so .. I actually thought about this at some point, it's tricky. For
> > the global queues we check what reasons we had for stopping them, but we
> > don't do that for the netif queues. Maybe we should? I also think flush
> > should at least have the option to be per queue, so that we could do
> > something per sdata in mac80211 if the driver uses different HW queues
> > for different interfaces.
> 
> To me so from driver perspective, it was not clear what 
> ieee80211_stop/wake_queues was operating on. Somehow the knowledge that 
> the netif queues are already stopped upon calling 
> ieee80211_stop_queues() should be retained.

Yes. From the driver perspective, those calls operate on the HW queues
(which you can modify now, using the IEEE80211_HW_QUEUE_CONTROL flag and
associated APIs). But we don't retain the netif queue state separately,
which I agree is a bug.

> Regarding the flush do you mean flush per queue or flush per vif? Per 
> vif could have its perks, I guess.

Not sure. With the IEEE80211_HW_QUEUE_CONTROL per queue might make
sense, and would actually make more sense than per vif in most cases.
However, it'd have to be a bitmap so the flush can happen in parallel.

> > However, I'm not sure I'll have time to work on corner cases with
> > software scanning since we don't use that. I might work on the flush
> > thing though, that could be interesting.
> 
> ok. The drv_flush() call is done in several places so not only scanning. 
> All with the drop flag set to false. Is that just to be prepared or do 
> you foresee an actual use-case?

I think at some point I thought we would use it, but if somebody is
going to change the flush callback (e.g. by passing a hw queue bitmap) I
would suggest to remove the drop flag.

johannes