Re: Max clients on wifi access point with 7265

[Kalle Valo <kvalo@codeaurora.org>]

Steve deRosier <derosier@gmail.com> writes:

> On Tue, Feb 27, 2018 at 12:33 AM, Kalle Valo <kvalo@codeaurora.org> wrote:
>> Luca Coelho <luca@coelho.fi> writes:
>>
>>>> > We do have wiphy::max_ap_assoc_sta, but I see only ath10k, qtnfmac
>>>> > and
>>>> > rsi_91x setting it. I wish all drivers would use that.
>>>> >
>>>> >  * @max_ap_assoc_sta: maximum number of associated stations
>>>> > supported in AP mode
>>>> >  * (including P2P GO) or 0 to indicate no such limit is advertised.
>>>> > The
>>>> >  * driver is allowed to advertise a theoretical limit that it can
>>>> > reach in
>>>> >  * some cases, but may not always reach.
>>>>
>>>> Cool, I hadn't noticed this before.  I'll add a patch to iwlwifi to
>>>> add it.
>>>
>>> Actually this is not so straightforward, because every time we add a
>>> p2p vif, we lose one more station.  So the max_ap_assoc_sta value must
>>> be dynamic (or we can state the theoretical lowest number to start
>>> with, which would not be very nice).
>>>
>>> I don't think this feature is worth the trouble, so I'll skip it for
>>> now.
>>
>> I think the documentation answers that part pretty well:
>>
>>   "The driver is allowed to advertise a theoretical limit that it can
>>    reach in some cases, but may not always reach."
>>
>> So I still thank having the drivers to advertise the theoretical maximum
>> numbers of client is useful, even if it would not be always 100%
>> correct. For example, an average user most likely will not have any clue
>> if the limit is 10, 50 or 100 clients. And besides, very few people use
>> P2P anyway ;)
>>
>> But of course this is just nice-to-have category cand we have far more
>> important things to fix first.
>>
>
> From a practical point-of-view, many chipsets don't advertise this
> information. Luca was able to look the limit up or knew it for his
> chip. For example, on the ath6kl chips I most commonly have worked
> with, the number is not specified by QCA and was only determined by us
> via experimentation. And even on the same chip, it'll change with
> firmware version as the necessary resources get consumed by new
> features or fixes. If the firmware can send that number up to the
> driver (or the driver can reliably know it because it can't change),
> then expose it, but otherwise I'd advise publishing a value of 0. I'd
> rather see the unknown flag rather than relying on a number that may
> or may not be accurate.

Yeah, definitely. The value needs to be based on facts, not guesses.

-- 
Kalle Valo