From: Jan Kiszka <jan.kiszka@web.de>
To: Christian Lamparter <chunkeey@googlemail.com>
Cc: linux-wireless@vger.kernel.org
Subject: Re: [RFT] ar9170: AP broadcast buffering
Date: Sun, 06 Dec 2009 19:23:09 +0100 [thread overview]
Message-ID: <4B1BF68D.8060907@web.de> (raw)
In-Reply-To: <200911290206.07784.chunkeey@googlemail.com>
[-- Attachment #1: Type: text/plain, Size: 3987 bytes --]
Christian Lamparter wrote:
> This patch should fix "broadcast traffic before DTIM beacon",
> But there is a downside: the broadcast (e.g arp) frames
> might get delayed and won't make it in time.
>
> let me know, if this patch does any good, or not...
Mmm, how is this supposed to work? I still haven't started hacking on
this as well, but I read a bit about DTIM. One thing I think to have
understood is that the DTIM interval is typically larger than the beacon
interval. There is even some interrupt on ar9170 indicating this event,
it's just not enabled yet.
Moreover, I do not yet understand how deferring multicast frames works
in this patch. How are they filtered out from normal frames and queued
until the beacon event? (But that misunderstanding might be due to the
fact that I haven't read the whole driver code yet.)
Jan
> ---
> diff --git a/drivers/net/wireless/ath/ar9170/ar9170.h b/drivers/net/wireless/ath/ar9170/ar9170.h
> index b99a8c2..c3d1349 100644
> --- a/drivers/net/wireless/ath/ar9170/ar9170.h
> +++ b/drivers/net/wireless/ath/ar9170/ar9170.h
> @@ -176,6 +176,7 @@ struct ar9170 {
> /* beaconing */
> struct sk_buff *beacon;
> struct work_struct beacon_work;
> + struct work_struct cab_work;
> bool enable_beacon;
>
> /* cryptographic engine */
> @@ -278,6 +279,7 @@ int ar9170_set_basic_rates(struct ar9170 *ar);
> int ar9170_set_hwretry_limit(struct ar9170 *ar, u32 max_retry);
> int ar9170_update_beacon(struct ar9170 *ar);
> void ar9170_new_beacon(struct work_struct *work);
> +void ar9170_send_buffered(struct work_struct *work);
> int ar9170_upload_key(struct ar9170 *ar, u8 id, const u8 *mac, u8 ktype,
> u8 keyidx, u8 *keydata, int keylen);
> int ar9170_disable_key(struct ar9170 *ar, u8 id);
> diff --git a/drivers/net/wireless/ath/ar9170/mac.c b/drivers/net/wireless/ath/ar9170/mac.c
> index 857e861..805b4f4 100644
> --- a/drivers/net/wireless/ath/ar9170/mac.c
> +++ b/drivers/net/wireless/ath/ar9170/mac.c
> @@ -463,7 +463,6 @@ void ar9170_new_beacon(struct work_struct *work)
> {
> struct ar9170 *ar = container_of(work, struct ar9170,
> beacon_work);
> - struct sk_buff *skb;
>
> if (unlikely(!IS_STARTED(ar)))
> return ;
> @@ -475,6 +474,24 @@ void ar9170_new_beacon(struct work_struct *work)
>
> ar9170_update_beacon(ar);
>
> + out:
> + mutex_unlock(&ar->mutex);
> +}
> +
> +void ar9170_send_buffered(struct work_struct *work)
> +{
> + struct ar9170 *ar = container_of(work, struct ar9170,
> + cab_work);
> + struct sk_buff *skb;
> +
> + if (unlikely(!IS_STARTED(ar)))
> + return ;
> +
> + mutex_lock(&ar->mutex);
> +
> + if (!ar->vif)
> + goto out;
> +
> rcu_read_lock();
> while ((skb = ieee80211_get_buffered_bc(ar->hw, ar->vif)))
> ar9170_op_tx(ar->hw, skb);
> diff --git a/drivers/net/wireless/ath/ar9170/main.c b/drivers/net/wireless/ath/ar9170/main.c
> index 20f04ab..f027d74 100644
> --- a/drivers/net/wireless/ath/ar9170/main.c
> +++ b/drivers/net/wireless/ath/ar9170/main.c
> @@ -660,6 +660,10 @@ void ar9170_handle_command_response(struct ar9170 *ar, void *buf, u32 len)
> * YY always 00
> * B1-B4 "should" be the number of send out beacons.
> */
> +
> + if (ar->vif && ar->vif->type == NL80211_IFTYPE_AP)
> + ieee80211_queue_work(ar->hw, &ar->cab_work);
> +
> break;
>
> case 0xc3:
> @@ -1294,6 +1298,7 @@ static void ar9170_op_stop(struct ieee80211_hw *hw)
> cancel_delayed_work_sync(&ar->led_work);
> #endif
> cancel_work_sync(&ar->beacon_work);
> + cancel_work_sync(&ar->cab_work);
>
> mutex_lock(&ar->mutex);
>
> @@ -2549,6 +2554,7 @@ void *ar9170_alloc(size_t priv_size)
> }
> ar9170_rx_reset_rx_mpdu(ar);
> INIT_WORK(&ar->beacon_work, ar9170_new_beacon);
> + INIT_WORK(&ar->cab_work, ar9170_send_buffered);
> INIT_DELAYED_WORK(&ar->tx_janitor, ar9170_tx_janitor);
> INIT_LIST_HEAD(&ar->tx_ampdu_list);
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]
next prev parent reply other threads:[~2009-12-06 18:27 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-29 1:06 [RFT] ar9170: AP broadcast buffering Christian Lamparter
2009-12-06 18:23 ` Jan Kiszka [this message]
2009-12-07 16:36 ` Christian Lamparter
2009-12-07 20:08 ` Kalle Valo
2009-12-07 21:31 ` Christian Lamparter
2009-12-08 7:23 ` Kalle Valo
2009-12-08 21:51 ` Jan Kiszka
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=4B1BF68D.8060907@web.de \
--to=jan.kiszka@web.de \
--cc=chunkeey@googlemail.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;
as well as URLs for NNTP newsgroup(s).