Re: off- & multi-channel operation

[Johannes Berg <johannes@sipsolutions.net>]

On Sat, 2011-11-12 at 14:46 -0800, Adrian Chadd wrote:
> I'm looking at this in FreeBSD's net80211, primarily to be able to
> bring sanity to tx/rx aggregation handling so things like active, high
> throughput traffic doesn't get annoyed when off-channel mode occurs.
> 
> So when you decide to start scanning, there may be frames already in
> the TX queue. If you simply called "start scanning now!", hardware
> like say ath9k would have to do this (and i haven't looked to see if
> it does, I bet it does. :-)
> 
> * the TX queue would have to be paused in its entirety, so the higher
> layers both stop sending frames, _and_ any existing call to
> if_transmit/if_start (and the linux equivalents) have entirely
> completed;
> * that doesn't guarantee the hardware-queued TXes have completed, so
> you either have to wait for those to complete before you start
> off-channel operation, or ..
> * .. you tell the driver "i'm about to start scanning, please get ready";
> * where the driver (eg ath9k) would then stop RX/TX DMA, with frames
> still in the RX completion queue and TX pending/completion state;

I have no idea what ath9k does, but we do tell it about start/stop
scanning and flush queues explicitly (the latter may not be the best
thing to do with multi-channel)

> * .. which have to be handled at some point;
> * .. since the hardware may hvae multiple TX queues, but you typically
> use the same for on-channel and off-channel, you have to then handle
> those frames then, OR set them aside and handle them once you go
> on-channel again;

I'm thinking that since the hardware has enough queues, you might use a
set per channel to switch more quickly, but that's up to the driver
implementation :-)

[snip]

> I do think you need the stack to be able to do the frame buffering;
> the driver could exert a little more control so it's not forced to
> simply drop all the frames on the floor, but be given time to complete
> what it's doing before scanning begins.

Yes, well, the driver can always start & stop queues, and for software
scan we do already stop queues (not for hardware scan for obvious
reasons).

johannes