Re: Why does the driver configure only 2 keys per peer?

[Ben Greear <greearb@candelatech.com>]

No, the hardware can handle plenty of slots...looks to me like no one
actually tested to the configured limits and/or they got lucky while
testing.  As long as it is possible for user-space to (temporarily?)
configure 4 keys per peer, then the firmware can assert.  I'll just
increase the keys per peer.  Uses a bit more firmware memory, but
better than crashing.

Thanks,
Ben

On 03/18/2016 08:25 PM, Adrian Chadd wrote:
> I'm guessing it's because there were customers who er, "needed" more
> STAs, and there's only a fixed number of hardware slots in the MAC.
>
>
> -a
>
>
> On 18 March 2016 at 13:25, Ben Greear <greearb@candelatech.com> wrote:
>> For instance:
>>
>> #define TARGET_10_4_NUM_PEER_KEYS               2
>>
>> But, there are 4 key-ids, and so the driver can attempt to allocate 3 per
>> peer.
>>
>> Now, the self-peer probably only has one key ever (and that is blank key),
>> but that still averages to 5 per vdev (when vdev has 2 peers), and if AP
>> peers can have more than 2
>> keys, then the average is even worse for them.
>>
>> In 10.1, I ended up using '4' instead of 2.
>>
>> I guess I'm about to repeat that change for 10.4 firmware.
>>
>> But, I'm curious why someone thought 2 was OK to begin with?
>>
>> Thanks,
>> Ben
>>
>> --
>> Ben Greear <greearb@candelatech.com>
>> Candela Technologies Inc  http://www.candelatech.com
>>
>>
>> _______________________________________________
>> ath10k mailing list
>> ath10k@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/ath10k
>

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

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k