From: "Luis R. Rodriguez" <lrodriguez@atheros.com>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: Luis Rodriguez <Luis.Rodriguez@Atheros.com>,
Jouni Malinen <j@w1.fi>,
"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
Kalle Valo <kvalo@adurom.com>,
Amod Bodas <Amod.Bodas@Atheros.com>
Subject: Re: [RFT] mac80211: fix broadcast/multicast data drop on scan
Date: Fri, 27 Aug 2010 11:30:31 -0700 [thread overview]
Message-ID: <20100827183031.GB7317@tux> (raw)
In-Reply-To: <1282924722.4377.17.camel@jlt3.sipsolutions.net>
On Fri, Aug 27, 2010 at 08:58:42AM -0700, Johannes Berg wrote:
> On Fri, 2010-08-27 at 08:55 -0700, Luis R. Rodriguez wrote:
> > On Fri, Aug 27, 2010 at 8:51 AM, Johannes Berg
> > <johannes@sipsolutions.net> wrote:
> > > On Fri, 2010-08-27 at 08:48 -0700, Luis R. Rodriguez wrote:
> > >
> > >> > Well, there's no way we can reliably wake up exactly before a beacon by
> > >> > implementing that in software, hard real-time hasn't been achieved in
> > >> > Linux yet :-)
> > >>
> > >> Keyword here is *exactly*. I don't want to wake up *exactly* at DTIM,
> > >> only ensure we don't sleep during it and the send buffered frames and
> > >> multicast traffic data. Why can we not implement this on mac80211?
> > >
> > > Well, how long before the beacon do you want to wake up to catch it?
> > > 1ms? 10ms? 100ms? 1000ms? What if the system is busy?
> >
> > I cannot say what would work best, how about half a beacon interval early?
>
> Why are we even discussing this anyway? It doesn't matter for a power
> save implementation since you better offload it to the device so you get
> as exact timing as you can?
ath9k hardware does not have a CPU to offload this. I just noticed we do
however already wait for the dtim count to go to 0 and also all RX'd buffered
data through ath_rx_ps() but even if then it seems we need and API to enable
drivers to flag when they want to disallow scanning (dynamic power save can be
disabled already by the driver at will I think). Otherwise we would have to
use something like the patch I'm going to send, which is fine for now.
Luis
prev parent reply other threads:[~2010-08-27 18:30 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-27 5:38 [RFT] mac80211: fix broadcast/multicast data drop on scan Luis R. Rodriguez
2010-08-27 9:06 ` Jouni Malinen
2010-08-27 15:28 ` Luis R. Rodriguez
2010-08-27 15:37 ` Johannes Berg
2010-08-27 15:40 ` Luis R. Rodriguez
2010-08-27 15:43 ` Johannes Berg
2010-08-27 15:48 ` Luis R. Rodriguez
2010-08-27 15:51 ` Johannes Berg
2010-08-27 15:55 ` Luis R. Rodriguez
2010-08-27 15:58 ` Johannes Berg
2010-08-27 18:30 ` Luis R. Rodriguez [this message]
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=20100827183031.GB7317@tux \
--to=lrodriguez@atheros.com \
--cc=Amod.Bodas@Atheros.com \
--cc=Luis.Rodriguez@Atheros.com \
--cc=j@w1.fi \
--cc=johannes@sipsolutions.net \
--cc=kvalo@adurom.com \
--cc=linux-wireless@vger.kernel.org \
/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