From: Felix Fietkau <nbd@openwrt.org>
To: Ben Greear <greearb@candelatech.com>
Cc: "ath9k-devel@lists.ath9k.org" <ath9k-devel@venema.h4ckr.net>,
"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
Johannes Berg <johannes@sipsolutions.net>
Subject: Re: [ath9k-devel] ath9k, multiple stations, and AMPDUs
Date: Tue, 21 Sep 2010 20:06:01 +0200 [thread overview]
Message-ID: <4C98F409.9030905@openwrt.org> (raw)
In-Reply-To: <4C98F3AB.20206@candelatech.com>
On 2010-09-21 8:04 PM, Ben Greear wrote:
> On 09/21/2010 11:00 AM, Felix Fietkau wrote:
>> On 2010-09-21 7:25 PM, Ben Greear wrote:
>>> On 09/21/2010 05:19 AM, Felix Fietkau wrote:
>>>> On 2010-09-21 2:08 PM, Ben Greear wrote:
>>>
>>>>> If you have any more details on this, please let me know. I'm going to
>>>>> attempt to fix it...I certainly have a good test case :)
>>>> ath_tx_complete_aggr completes an A-MPDU frame, which typically triggers
>>>> the release of the next A-MPDU to the hw queue.
>>>> To keep track of the Block ACK window, it needs to look up the TID, for
>>>> which it needs a STA pointer. At that level, the driver typically
>>>> doesn't have access to the vif.
>>>>
>>>> It might be possible to fix this by adding another sta lookup helper
>>>> function in mac80211 that takes another address argument for the BSSID,
>>>> so that it can get the sta entry for the correct vif. I don't know if
>>>> Johannes wants something like that though.
>>>
>>> Could we just poke a pointer to the STA into the ath_buf structure?
>> No, that doesn't work because of RCU.
>
> Would it also be bad to use skb->dev to find an STA?
It would be bad to keep a STA pointer around anywhere in the skb or the
ath_buf. You can only use it within a rcu_read_lock()/rcu_read_unlock()
pair.
- Felix
next prev parent reply other threads:[~2010-09-21 18:06 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-21 5:25 ath9k, multiple stations, and AMPDUs Ben Greear
2010-09-21 10:10 ` [ath9k-devel] " Felix Fietkau
2010-09-21 12:08 ` Ben Greear
2010-09-21 12:19 ` Felix Fietkau
2010-09-21 12:24 ` Johannes Berg
2010-09-21 12:31 ` Johannes Berg
2010-09-21 17:25 ` Ben Greear
2010-09-21 18:00 ` Felix Fietkau
2010-09-21 18:04 ` Ben Greear
2010-09-21 18:06 ` Felix Fietkau [this message]
2010-09-21 19:28 ` Johannes Berg
2010-09-21 19:32 ` Felix Fietkau
2010-09-21 20:19 ` Ben Greear
2010-09-21 22:41 ` Felix Fietkau
2010-09-22 4:33 ` Ben Greear
2010-09-22 8:31 ` Felix Fietkau
2010-09-23 4:58 ` Ben Greear
2010-09-23 8:33 ` Johannes Berg
2010-09-23 13:56 ` Ben Greear
2010-09-23 14:05 ` Johannes Berg
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=4C98F409.9030905@openwrt.org \
--to=nbd@openwrt.org \
--cc=ath9k-devel@venema.h4ckr.net \
--cc=greearb@candelatech.com \
--cc=johannes@sipsolutions.net \
--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).