From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ben Greear Date: Thu, 12 Jan 2012 12:14:03 -0800 Subject: [ath9k-devel] Question on keycache size. In-Reply-To: References: <4F0E0537.2000509@candelatech.com> <4F0F041F.4020300@candelatech.com> Message-ID: <4F0F3F0B.1010101@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 11:46 AM, Adrian Chadd wrote: > .. well, nohwcrypt still populates the keycache, just with no-crypt entries. > > I just wonder what other state is being kept in the keycache (eg > filtered frame handling lives there IIRC, I don't recall where the > aggregation state cache sits, but it shouldn't be required - it just > means the bitmap would be "right" instead of "very right" (ie, keeping > track of the previously-sent frames..)) > > Ben: just verify that nohwcrypt still populates keycache entries? Just starting to take a look. First thing I found is this in ath9k/init.c. The comments make it seem like the limit is much lower than 128, but perhaps that is only if hwcrypt is used... /* * Check whether the separate key cache entries * are required to handle both tx+rx MIC keys. * With split mic keys the number of stations is limited * to 27 otherwise 59. */ if (sc->sc_ah->misc_mode & AR_PCU_MIC_NEW_LOC_ENA) common->crypt_caps |= ATH_CRYPT_CAP_MIC_COMBINED; Will continue digging. Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com