Search Linux Wireless

Re: Max clients on wifi access point with 7265

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Feb 27, 2018 at 12:33 AM, Kalle Valo <kvalo@xxxxxxxxxxxxxx> wrote:
> Luca Coelho <luca@xxxxxxxxx> 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.

- Steve

--
Steve deRosier
Cal-Sierra Consulting LLC
https://www.cal-sierra.com/



[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Wireless Personal Area Network]     [Linux Bluetooth]     [Wireless Regulations]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite Hiking]     [MIPS Linux]     [ARM Linux]     [Linux RAID]

  Powered by Linux