* Why does the driver configure only 2 keys per peer?
@ 2016-03-18 20:25 Ben Greear
[not found] ` <CAJ-Vmo=C2Y+E4kELzHaAEYtxa3YZyy84cctvo+Rj_ndk1ixznQ@mail.gmail.com>
0 siblings, 1 reply; 2+ messages in thread
From: Ben Greear @ 2016-03-18 20:25 UTC (permalink / raw)
To: ath10k
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
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: Why does the driver configure only 2 keys per peer?
[not found] ` <CAJ-Vmo=C2Y+E4kELzHaAEYtxa3YZyy84cctvo+Rj_ndk1ixznQ@mail.gmail.com>
@ 2016-03-19 15:42 ` Ben Greear
0 siblings, 0 replies; 2+ messages in thread
From: Ben Greear @ 2016-03-19 15:42 UTC (permalink / raw)
To: Adrian Chadd; +Cc: ath10k
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
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2016-03-19 15:44 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-03-18 20:25 Why does the driver configure only 2 keys per peer? Ben Greear
[not found] ` <CAJ-Vmo=C2Y+E4kELzHaAEYtxa3YZyy84cctvo+Rj_ndk1ixznQ@mail.gmail.com>
2016-03-19 15:42 ` Ben Greear
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.