[ath9k-devel] Question on keycache size.

[ath9k-devel] Question on keycache size.

[Ben Greear]

I have an ath9k AP, running 3.0.8 kernel (with a few tweaks).
nohwcrypt is enabled.

I set up some other machines with virtual stations, a total of
around 450 and had them associate with the AP.

It seems to have worked, at least for a while, but then I started
seeing loss of station communication, and in the AP logs I see
things like this:

Jan 11 13:47:03 localhost kernel: ath: keycache entry 228 out of range

It appears the keycache max is always 128.  Any idea what this
message really means?  Is there a hard upper limit of 128 stations
for ath9k NICs?

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

[ath9k-devel] Question on keycache size.

[Mohammed Shafi]

Hi Ben,

On Thu, Jan 12, 2012 at 3:25 AM, Ben Greear <greearb@candelatech.com> wrote:
> I have an ath9k AP, running 3.0.8 kernel (with a few tweaks).
> nohwcrypt is enabled.
>
> I set up some other machines with virtual stations, a total of
> around 450 and had them associate with the AP.
>
> It seems to have worked, at least for a while, but then I started
> seeing loss of station communication, and in the AP logs I see
> things like this:
>
> Jan 11 13:47:03 localhost kernel: ath: keycache entry 228 out of range

may be we should put 'nohwcrypt' check in ath9k_sta_add and
ath9k_sta_remove before doing ath_key_config & ath9k_del_ps_key? i
will try to analyze the code

>
> It appears the keycache max is always 128. ?Any idea what this
> message really means? ?Is there a hard upper limit of 128 stations
> for ath9k NICs?
>
> Thanks,
> Ben
>
> --
> Ben Greear <greearb@candelatech.com>
> Candela Technologies Inc ?http://www.candelatech.com
>
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel



-- 
shafi

[ath9k-devel] Question on keycache size.

[Ben Greear]

On 01/12/2012 12:27 AM, Mohammed Shafi wrote:
> Hi Ben,
>
> On Thu, Jan 12, 2012 at 3:25 AM, Ben Greear<greearb@candelatech.com>  wrote:
>> I have an ath9k AP, running 3.0.8 kernel (with a few tweaks).
>> nohwcrypt is enabled.
>>
>> I set up some other machines with virtual stations, a total of
>> around 450 and had them associate with the AP.
>>
>> It seems to have worked, at least for a while, but then I started
>> seeing loss of station communication, and in the AP logs I see
>> things like this:
>>
>> Jan 11 13:47:03 localhost kernel: ath: keycache entry 228 out of range
>
> may be we should put 'nohwcrypt' check in ath9k_sta_add and
> ath9k_sta_remove before doing ath_key_config&  ath9k_del_ps_key? i
> will try to analyze the code

Ok, I will be happy to test patches..I can easily associate 128+ stations
with an AP and drive traffic.

 From some private email responses, it would appear that packet aggregation
may be part of the problem.  I could associate 400+ stations, and drive low-level
traffic (one pkt every second or so per station).  The problem started when I
created a 100 pkt per second traffic flow (142 byte pkts if that matters).

If it does turn out that 128+ stations requires nohwcrypt, we should
fail the add of the 129th if using hwcrypt so that folks don't have to
debug tricky problems....

Thanks,
Ben


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

[ath9k-devel] Question on keycache size.

[Adrian Chadd]

.. 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?


adrian

[ath9k-devel] Question on keycache size.

[Ben Greear]

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 <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

[ath9k-devel] Question on keycache size.

[Ben Greear]

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;
	}

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

[ath9k-devel] Question on keycache size.

[Ben Greear]

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 <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

[ath9k-devel] Question on keycache size.

[Adrian Chadd]

Let me go and hit up the MAC guys and find exactly what the heck is
being kept in the keycache. There may be some good reasons it's being
done that I'm not yet aware of.

At least the (legacy, but not sure for Kite/similar) fast diversity
stuff is kept in the keycache? As well as the filtered frame bits.


Adrian

[ath9k-devel] Question on keycache size.

[Ben Greear]

On 01/12/2012 03:53 PM, Adrian Chadd wrote:
> Let me go and hit up the MAC guys and find exactly what the heck is
> being kept in the keycache. There may be some good reasons it's being
> done that I'm not yet aware of.
>
> At least the (legacy, but not sure for Kite/similar) fast diversity
> stuff is kept in the keycache? As well as the filtered frame bits.

There is lots being kept there, but the code appears to deal with
invalid key caches just fine (and this appears to be the expected
code path when nohwcrypt is enabled.)

You can see what it pokes into the chip in the ath/key.c file.

Grepping for ath_key in the ath/ath9k/ dir shows the calling
code..and so forth.

Eventually the rx and tx logic has checks for
keyix == ATH9K_RXKEYIX_INVALID, and appears to deal with
things OK if that is the case.

I still look forward to hearing about anything you learn on
this topic, however!

Thanks,
Ben

>
>
> Adrian


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com