From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ben Greear Date: Thu, 12 Jan 2012 15:11:01 -0800 Subject: [ath9k-devel] Question on keycache size. In-Reply-To: <4F0F43BE.3080108@candelatech.com> References: <4F0E0537.2000509@candelatech.com> <4F0F041F.4020300@candelatech.com> <4F0F3F0B.1010101@candelatech.com> <4F0F43BE.3080108@candelatech.com> Message-ID: <4F0F6885.7010506@candelatech.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: ath9k-devel@lists.ath9k.org On 01/12/2012 12:34 PM, Ben Greear wrote: > Here's a bit that looks questionable to me. This is from > ath9k_rx_skb_postprocess > > I'm thinking maybe that else clause should not re-assign > keyix if keyix is RXKEYIX_INVALID (and never set the RX_FLAG_DECRYPTED > flag in rxs->flag? > > if (!(keyix == ATH9K_RXKEYIX_INVALID)&& !decrypt_error&& > ieee80211_has_protected(fc)) { > rxs->flag |= RX_FLAG_DECRYPTED; > } else if (ieee80211_has_protected(fc) > && !decrypt_error&& skb->len>= hdrlen + 4) { > keyix = skb->data[hdrlen + 3]>> 6; > > if (test_bit(keyix, common->keymap)) > rxs->flag |= RX_FLAG_DECRYPTED; > } Well, after some more testing, I'm not sure there is any real problem, at least when nohwaccel is enabled. I think that I am just getting really bad throughput when there are 400+ stations transmitting and receiving, and tcp was basically just unable to make progress. It does appear that we could skip all of the key setup and teardown logic if we have nohwaccel enabled, at least if I understand the code properly. That should get rid of the keycache warning message. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com