From: Kalle Valo <kalle.valo@iki.fi>
To: "Luis R. Rodriguez" <mcgrof@gmail.com>
Cc: linux-wireless@vger.kernel.org,
Johannes Berg <johannes@sipsolutions.net>
Subject: Re: [RFC PATCH v1 3/3] mac80211: add beacon filtering support
Date: Mon, 23 Feb 2009 21:06:13 +0200 [thread overview]
Message-ID: <87prh9ht22.fsf@litku.valot.fi> (raw)
In-Reply-To: <43e72e890902230947x6e55bf36ve715295f43f74fbb@mail.gmail.com> (Luis R. Rodriguez's message of "Mon\, 23 Feb 2009 09\:47\:15 -0800")
"Luis R. Rodriguez" <mcgrof@gmail.com> writes:
> On Mon, Feb 23, 2009 at 8:37 AM, Kalle Valo <kalle.valo@nokia.com> wrote:
>> --- a/include/net/mac80211.h
>> +++ b/include/net/mac80211.h
>> @@ -903,6 +903,7 @@ enum ieee80211_hw_flags {
>> IEEE80211_HW_PS_NULLFUNC_STACK = 1<<11,
>> IEEE80211_HW_SUPPORTS_DYNAMIC_PS = 1<<12,
>> IEEE80211_HW_MFP_CAPABLE = 1<<13,
>> + IEEE80211_HW_BEACON_FILTERING = 1<<14,
>
> Not sure this conveys what it means, how about BEACON_MISS ?
To me the name "beacon filtering" sounds better. The idea of the
feature is to avoid sending beacons to the host, that is "filter
beacons" in firmware. Beacon miss is an action of that feature. Am I
making any sense? :)
Also my assumption here is that ieee80211_beacon_loss() should be
called only after certain number of consecutive beacon misses. While
testing these patches on stlc45xx I used number 10. Can ath9k handle
anything like this? Or will it just report each beacon miss
individually?
>> +void ieee80211_beacon_loss(struct ieee80211_hw *hw);
>>
>> /* Rate control API */
>>
>
> Some kdoc would be nice for this.
Definitely. It's on my TODO list.
> Also I suspect you designed this with 2 GHz legacy (802.11bg) single
> band cards in mind.
Good guess :) Yes, I haven't thought about 5 GHz band.
> For the case or cards capable of 5 GHz or of HT I believe we should
> consider the cases of dealing with DFS or HT channel switch both of
> which can occur dynamically while the STAs are associated. If
> hardware is capable of differentiating this (through beacon
> checksums) then that's an enhancement but for now I suspect that is
> not the case for most hardware that implements this and as such for
> the case when on DFS or using HT we can simply have mac80211 disable
> this. Not sure... Thoughts?
I don't see a problem. Like you said, such hardware should have beacon
checksumming support. Whenever the checksum has changed, the hardware
should pass the beacon to the host and mac80211 would receive the
beacon just like without beacon filtering.
Beacon filtering can be thought like filtering unrelevant beacons, but
passing through the beacons which have new information. For example,
stlc45xx already has beacon checksum support even though it doesn't
support 5 GHz band. Unfortunately I haven't managed to find the time
to test it yet.
If there is hardware using 5 GHz band and does not support beacon
checksumming, then the driver should not even enable beacon filtering.
--
Kalle Valo
next prev parent reply other threads:[~2009-02-23 19:06 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-23 16:37 [RFC PATCH v1 0/3] mac80211: beacon filtering Kalle Valo
2009-02-23 16:37 ` [RFC PATCH v1 1/3] mac80211: decrease execution of the associated timer Kalle Valo
2009-02-24 2:13 ` Johannes Berg
2009-02-24 18:40 ` Kalle Valo
2009-02-23 16:37 ` [RFC PATCH v1 2/3] mac80211: track beacons separately from the rx path activity Kalle Valo
2009-02-24 2:15 ` Johannes Berg
2009-02-24 18:52 ` Kalle Valo
2009-02-23 16:37 ` [RFC PATCH v1 3/3] mac80211: add beacon filtering support Kalle Valo
2009-02-23 17:47 ` Luis R. Rodriguez
2009-02-23 19:06 ` Kalle Valo [this message]
2009-02-23 19:11 ` Luis R. Rodriguez
2009-02-23 19:31 ` Kalle Valo
2009-02-23 19:58 ` Luis R. Rodriguez
2009-02-24 4:46 ` Luis R. Rodriguez
2009-02-24 5:17 ` Johannes Berg
2009-02-24 8:58 ` Jouni Malinen
2009-02-24 2:18 ` Johannes Berg
2009-02-24 20:34 ` Kalle Valo
2009-02-24 2:20 ` Johannes Berg
2009-02-24 9:01 ` Jouni Malinen
2009-02-24 18:36 ` Kalle Valo
2009-02-24 18:43 ` Jouni Malinen
2009-02-24 19:02 ` Kalle Valo
2009-02-24 18:30 ` Kalle Valo
2009-02-23 17:15 ` [PATCH] stlc45xx: " Kalle Valo
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=87prh9ht22.fsf@litku.valot.fi \
--to=kalle.valo@iki.fi \
--cc=johannes@sipsolutions.net \
--cc=linux-wireless@vger.kernel.org \
--cc=mcgrof@gmail.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).