On 05/29/2014 07:42 AM, Bartosz Markowski wrote: > On 29 May 2014 16:10, Bartosz Markowski <bartosz.markowski@xxxxxxxxx> wrote: >> On 29 May 2014 15:47, Ben Greear <greearb@xxxxxxxxxxxxxxx> wrote: >>> >>> >>> On 05/29/2014 06:36 AM, Bartosz Markowski wrote: >>>> >>>> Firmware 10.x supports up to 8 virtual AP interfaces >>>> (comparing to 7 for main firmware). Previous vdev map >>>> initialization was missing enough space for 8 + 1 vdevs >>>> (we may spent one for mac monitor), due to wrong define used. >>>> >>>> Use correct one - TARGET_10X_NUM_VDEVS - for 10.x firmware. >>> >>> >>> You are bumping total vdevs up to 16 with that patch...have you >>> actually tested that many? The stock firmware has quite a bit of >>> deficiencies in the concurrency handling, at least for stations. >> >> No, I have never tested it with so many. I'm running tests with 8 at >> most. And by this patch I just aimed to support 8 VAPS we advertise in >> iface_combinations to mac80211 (.max_interfaces = 8). I was managed to >> get only 7 before, since 1 vdev was being allocated as monitor. > > FYI: I quickly tried to extend the .max_interfaces + > interface_combinations limit in ath10k and check with 15 VAPs (using > hostapd, open network; on MIPS platform) and it just worked.. I did > not perform any exploratory testing, but managed to connect a couple > of clients to various bssids + run some sane iperf traffic etc. Good to know that many VAPs can work... If the OS limits are going to remain at 8, then maybe only set the vdev mask to support 9 instead of 16 vifs to handle the monitor interface? That should make it easier (or at least safer) to support my firmware on un-patched kernels... Some of the problems with running out of resources in the firmware (which generally just asserts or crashes in that case) are only seen under load and/or random-ish cases in my experience. I'm all for pushing the firmware to the max, but I suspect 16 vifs may not be that stable. That said, I have only been testing multiple stations, so maybe it will just work fine. Thanks, Ben -- Ben Greear <greearb@xxxxxxxxxxxxxxx> Candela Technologies Inc http://www.candelatech.com -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
