From: Jouni Malinen <j@w1.fi>
To: "Luis R. Rodriguez" <mcgrof@gmail.com>
Cc: Bob Copeland <me@bobcopeland.com>,
"Jouni.Malinen" <Jouni.Malinen@atheros.com>,
Johannes Berg <johannes@sipsolutions.net>,
linux-wireless <linux-wireless@vger.kernel.org>
Subject: Re: Flush TX - wireless summit topic
Date: Wed, 23 Sep 2009 15:58:53 -0700 [thread overview]
Message-ID: <20090923225853.GA14625@jm.kir.nu> (raw)
In-Reply-To: <43e72e890909221541u67fa291fq353327d1d55841f2@mail.gmail.com>
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
next prev parent reply other threads:[~2009-09-23 22:59 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-22 22:41 Flush TX - wireless summit topic Luis R. Rodriguez
2009-09-23 11:59 ` Bob Copeland
2009-09-23 22:58 ` Jouni Malinen [this message]
2009-09-23 23:28 ` Luis R. Rodriguez
2009-09-24 0:38 ` Luis R. Rodriguez
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090923225853.GA14625@jm.kir.nu \
--to=j@w1.fi \
--cc=Jouni.Malinen@atheros.com \
--cc=johannes@sipsolutions.net \
--cc=linux-wireless@vger.kernel.org \
--cc=mcgrof@gmail.com \
--cc=me@bobcopeland.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).