Question on beacon-miss handling.

Question on beacon-miss handling.

[Ben Greear]

While poking around in the firmware, I notice that ath10k
driver only requests a few vdevs to be supported by
the beacon-miss firmware logic, though the driver
supposedly supports more vdevs than that...

Any idea how this is supposed to work with more vdevs
than bmiss_offload_max_vdev?

Maybe it is best to just disable beacon-miss logic in
firmware entirely and let the driver/host handle it?

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

Re: Question on beacon-miss handling.

[Adrian Chadd]

Where is it in the firmware again?

The beacon miss stuff is a little .. odd. Mostly because there's only
one (and maybe two) timers for it and they're a pain in the ass to
configure correctly. Having it scale (correctly) to more than two
vdevs may be a little challenging.



-a


On 5 July 2014 07:16, Ben Greear <greearb@candelatech.com> wrote:
> While poking around in the firmware, I notice that ath10k
> driver only requests a few vdevs to be supported by
> the beacon-miss firmware logic, though the driver
> supposedly supports more vdevs than that...
>
> Any idea how this is supposed to work with more vdevs
> than bmiss_offload_max_vdev?
>
> Maybe it is best to just disable beacon-miss logic in
> firmware entirely and let the driver/host handle it?
>
> 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

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

Re: Question on beacon-miss handling.

[Ben Greear]

On 07/05/2014 07:14 PM, Adrian Chadd wrote:
> Where is it in the firmware again?

wlan_swbmiss_offload.c

> The beacon miss stuff is a little .. odd. Mostly because there's only
> one (and maybe two) timers for it and they're a pain in the ass to
> configure correctly. Having it scale (correctly) to more than two
> vdevs may be a little challenging.

I've seen other funny stuff where an AP will crash hard(-ish?) and the associated stations
take a long time to figure out their AP is dead.  Could be related to this
maybe..or maybe was something else.  I have not investigated closely.

I'd be happy to have all the beacon miss stuff move to the driver..seems
a waste of limited resources in the firmware.

Thanks,
Ben

>
>
>
> -a
>
>
> On 5 July 2014 07:16, Ben Greear <greearb@candelatech.com> wrote:
>> While poking around in the firmware, I notice that ath10k
>> driver only requests a few vdevs to be supported by
>> the beacon-miss firmware logic, though the driver
>> supposedly supports more vdevs than that...
>>
>> Any idea how this is supposed to work with more vdevs
>> than bmiss_offload_max_vdev?
>>
>> Maybe it is best to just disable beacon-miss logic in
>> firmware entirely and let the driver/host handle it?
>>
>> 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
>
> _______________________________________________
> 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

Re: Question on beacon-miss handling.

[Adrian Chadd]

On 5 July 2014 20:39, Ben Greear <greearb@candelatech.com> wrote:
> On 07/05/2014 07:14 PM, Adrian Chadd wrote:
>>
>> Where is it in the firmware again?
>
>
> wlan_swbmiss_offload.c
>
>
>> The beacon miss stuff is a little .. odd. Mostly because there's only
>> one (and maybe two) timers for it and they're a pain in the ass to
>> configure correctly. Having it scale (correctly) to more than two
>> vdevs may be a little challenging.
>
>
> I've seen other funny stuff where an AP will crash hard(-ish?) and the
> associated stations
> take a long time to figure out their AP is dead.  Could be related to this
> maybe..or maybe was something else.  I have not investigated closely.
>
> I'd be happy to have all the beacon miss stuff move to the driver..seems
> a waste of limited resources in the firmware.

Think about it in terms of "minimising how much the host is woken up."

That's what the target market of the STA firmware for this chip is
thinking about.


-a

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

Re: Question on beacon-miss handling.

[Sujith Manoharan]

Adrian Chadd wrote:
> Think about it in terms of "minimising how much the host is woken up."
> 
> That's what the target market of the STA firmware for this chip is
> thinking about.

I don't think beacon filtering is enabled for ath10k, which means
all beacons are sent to mac80211 anyway. HW/FW connection monitoring
(in STA mode) is also not enabled in ath10k, so mac80211's beacon loss/miss
infrastructure is already used, no ?

Sujith

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

Re: Question on beacon-miss handling.

[Adrian Chadd]

On 5 July 2014 23:01, Sujith Manoharan <sujith@msujith.org> wrote:
> Adrian Chadd wrote:
>> Think about it in terms of "minimising how much the host is woken up."
>>
>> That's what the target market of the STA firmware for this chip is
>> thinking about.
>
> I don't think beacon filtering is enabled for ath10k, which means
> all beacons are sent to mac80211 anyway. HW/FW connection monitoring
> (in STA mode) is also not enabled in ath10k, so mac80211's beacon loss/miss
> infrastructure is already used, no ?

Sure, but my response was just describing the "why" behind why the
firmware would want to be doing beacon offload processing.


-a

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

Re: Question on beacon-miss handling.

[Ben Greear]

On 07/05/2014 11:01 PM, Sujith Manoharan wrote:
> Adrian Chadd wrote:
>> Think about it in terms of "minimising how much the host is woken up."
>>
>> That's what the target market of the STA firmware for this chip is
>> thinking about.
>
> I don't think beacon filtering is enabled for ath10k, which means
> all beacons are sent to mac80211 anyway. HW/FW connection monitoring
> (in STA mode) is also not enabled in ath10k, so mac80211's beacon loss/miss
> infrastructure is already used, no ?

Maybe the driver should make this 0 instead of 2 then?

hw.h:#define TARGET_10X_BMISS_OFFLOAD_MAX_VDEV	2

That would save resources in the firmware.

Thanks,
Ben

>
> Sujith
>


-- 
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

Re: Question on beacon-miss handling.

[Sujith Manoharan]

Ben Greear wrote:
> Maybe the driver should make this 0 instead of 2 then?
> hw.h:#define TARGET_10X_BMISS_OFFLOAD_MAX_VDEV	2
> That would save resources in the firmware.

Yes, it would. ath10k doesn't seem to be handling roam
events too, so maybe that can be set to 0 - not sure if
there are plans to properly enable and use roaming functionality
that is already in the firmware.

Sujith

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

Re: Question on beacon-miss handling.

[Ben Greear]

On 07/06/2014 08:37 PM, Sujith Manoharan wrote:
> Ben Greear wrote:
>> Maybe the driver should make this 0 instead of 2 then?
>> hw.h:#define TARGET_10X_BMISS_OFFLOAD_MAX_VDEV	2
>> That would save resources in the firmware.
>
> Yes, it would. ath10k doesn't seem to be handling roam
> events too, so maybe that can be set to 0 - not sure if
> there are plans to properly enable and use roaming functionality
> that is already in the firmware.

I have set both to zero when using my firmware, and so far, everything
seems to be working fine.

I am tempted to just compile the roaming and beacon-miss code entirely
out of the firmware to save a bit of memory, but I guess that might
possibly break some driver, so if I do, I will have to add a new
firmware image variant...

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

Re: Question on beacon-miss handling.

[Bartosz Markowski]

On 7 July 2014 05:37, Sujith Manoharan <sujith@msujith.org> wrote:
> Ben Greear wrote:
>> Maybe the driver should make this 0 instead of 2 then?
>> hw.h:#define TARGET_10X_BMISS_OFFLOAD_MAX_VDEV        2
>> That would save resources in the firmware.
>
> Yes, it would. ath10k doesn't seem to be handling roam
> events too, so maybe that can be set to 0 - not sure if
> there are plans to properly enable and use roaming functionality
> that is already in the firmware.

That is correct. ath10k does not currently support hw/fw conn
monitoring. Things may change in future as we upgrade to support 10.2
firmware, but AFAIK there's no direct plan to use this offloads. And
regarding the initialization of BMISS/ROAM_OFFLOADs, yes looks like
this can be erased to save some firmware memory.

-Bartosz

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