Flush TX - wireless summit topic

Flush TX - wireless summit topic

[Luis R. Rodriguez]

Another thing we spoke about at the wireless summit was flushing TX
prior to changing channel / scan. Bob, remember the issue with ath5k
on the band not coinciding on received skbs since we don't do a DMA RX
flush prior to channel change? Well one theory discussed was that we
would see that issue disappear if we actually did a proper TX flush
prior to channel change since we expect we would not see further
incoming frames from our AP if we told it we were going to PS (sending
a null func frame). If we implement a proper TX flush then the theory
goes that we wouldn't need to do any sort of DMA flush as we would not
have any frames pending.

So a plan here would be to give that a shot.

  Luis

Re: Flush TX - wireless summit topic

[Bob Copeland]

On Tue, Sep 22, 2009 at 03:41:50PM -0700, Luis R. Rodriguez wrote:
> flush prior to channel change? Well one theory discussed was that we
> would see that issue disappear if we actually did a proper TX flush
> prior to channel change since we expect we would not see further
> incoming frames from our AP if we told it we were going to PS (sending
> a null func frame).

Yeah, but due to the way ath5k defers frames, there's still a race
condition (queue some packets, flush TX to send out the nullfunc frame,
then RX tasklet runs on unprocessed packets).  I don't think TX flush
would hurt though, then we could probably drop the driver-side code
that tries to do the same.

-- 
Bob Copeland %% www.bobcopeland.com

Re: Flush TX - wireless summit topic

[Jouni Malinen]

On Tue, Sep 22, 2009 at 03:41:50PM -0700, Luis R. Rodriguez wrote:
> Another thing we spoke about at the wireless summit was flushing TX
> prior to changing channel / scan. Bob, remember the issue with ath5k
> on the band not coinciding on received skbs since we don't do a DMA RX
> flush prior to channel change? Well one theory discussed was that we
> would see that issue disappear if we actually did a proper TX flush
> prior to channel change since we expect we would not see further
> incoming frames from our AP if we told it we were going to PS (sending
> a null func frame). If we implement a proper TX flush then the theory
> goes that we wouldn't need to do any sort of DMA flush as we would not
> have any frames pending.

I don't know where this theory is coming from, but I do not subscribe to
it ;-). The AP may very well send broadcast frames even after we
indicate the change to PS mode. In addition, other frames could
potentially be received based on RX filter settings. If we want to make
sure we do not get new pending RX frames, we need to stop the receiver
first or be prepared to handle the received frames somehow.

The number of pending RX frames would hopefully be relatively small,
though, in this kind of case. In order to process these frames
correctly, they would need to be taken care of prior to the channel
change or alternatively, with the channel parameters cached in the
driver so that they could be sent up with all the correct information
even after the channel change.

-- 
Jouni Malinen                                            PGP id EFC895FA

Re: Flush TX - wireless summit topic

[Luis R. Rodriguez]

On Wed, Sep 23, 2009 at 3:58 PM, Jouni Malinen <j@w1.fi> wrote:
> On Tue, Sep 22, 2009 at 03:41:50PM -0700, Luis R. Rodriguez wrote:
>> Another thing we spoke about at the wireless summit was flushing TX
>> prior to changing channel / scan. Bob, remember the issue with ath5k
>> on the band not coinciding on received skbs since we don't do a DMA RX
>> flush prior to channel change? Well one theory discussed was that we
>> would see that issue disappear if we actually did a proper TX flush
>> prior to channel change since we expect we would not see further
>> incoming frames from our AP if we told it we were going to PS (sending
>> a null func frame). If we implement a proper TX flush then the theory
>> goes that we wouldn't need to do any sort of DMA flush as we would not
>> have any frames pending.
>
> I don't know where this theory is coming from, but I do not subscribe to
> it ;-).

I misunderstood you then, sorry about that.

> The AP may very well send broadcast frames even after we
> indicate the change to PS mode. In addition, other frames could
> potentially be received based on RX filter settings. If we want to make
> sure we do not get new pending RX frames, we need to stop the receiver
> first or be prepared to handle the received frames somehow.

Thanks for the clarification.

> The number of pending RX frames would hopefully be relatively small,
> though, in this kind of case.

Indeed.

> In order to process these frames
> correctly, they would need to be taken care of prior to the channel
> change or alternatively, with the channel parameters cached in the
> driver so that they could be sent up with all the correct information
> even after the channel change.

I'm inclined for mac80211 to force an rxflush here so that we force
all drivers to do the right thing and we'd document this as such,
instead of having to rely on each driver doing the right thing
(caching the channel for the RX'f frame). The downside to this is
obviously this can create a delay on channel change, however long it
takes to process the pending frames already sitting for us on the
DMA'd memory.

  Luis

Re: Flush TX - wireless summit topic

[Luis R. Rodriguez]

On Wed, Sep 23, 2009 at 4:28 PM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:

> I'm inclined for mac80211 to force an rxflush here so that we force
> all drivers to do the right thing and we'd document this as such,
> instead of having to rely on each driver doing the right thing
> (caching the channel for the RX'f frame). The downside to this is
> obviously this can create a delay on channel change, however long it
> takes to process the pending frames already sitting for us on the
> DMA'd memory.

After reviewing this in great detail with Jouni it seems the advised
path is to implement an RX flush prior to channel change in each
driver. There is some obvious delta created upon channel change if you
force to process all pending DMA'd frames but it remains unproven that
this delta in time will actually create an issue.

  Luis