I'm working on a patch to report the stats seen in debugfs/...ath10k/fw_stats
as ethtool stats, somewhat similar to how ath9k does it.
I notice that my user-space tool is reporting huge numbers because
the stats are reset to zero when firmware restarts, and so my tool
thinks the stats wrapped.
I can fix my tool easily enough, but I first wanted to see if
anyone had strong feelings about keeping the stats from resetting
to zero by storing history and calculating diffs in the driver.
I think my preference is to punt this to user-space, but if
someone feels otherwise, please let me know sooner than later.
Thanks,
Ben
--
Ben Greear <[email protected]>
Candela Technologies Inc http://www.candelatech.com
On 08/08/2014 06:11 PM, Ben Greear wrote:
> On 08/08/2014 08:55 AM, Dave Taht wrote:
>> On Fri, Aug 8, 2014 at 8:42 AM, Ben Greear <[email protected]> wrote:
>>> On 08/08/2014 02:06 AM, Kalle Valo wrote:
>>>> Ben Greear <[email protected]> writes:
>>>>
>>>>> I'm working on a patch to report the stats seen in debugfs/...ath10k/fw_stats
>>>>> as ethtool stats, somewhat similar to how ath9k does it.
>>>>>
>>>>> I notice that my user-space tool is reporting huge numbers because
>>>>> the stats are reset to zero when firmware restarts, and so my tool
>>>>> thinks the stats wrapped.
>>>>>
>>>>> I can fix my tool easily enough, but I first wanted to see if
>>>>> anyone had strong feelings about keeping the stats from resetting
>>>>> to zero by storing history and calculating diffs in the driver.
>>>>>
>>>>> I think my preference is to punt this to user-space, but if
>>>>> someone feels otherwise, please let me know sooner than later.
>>>>
>>>> I also prefer to have this in user space, but how does user space know
>>>> when the stats have been zeroed?
>>>
>>> Poll often enough that it cannot increment more than 2 billion (or other large number)
>>> between polls, and then if polled value is less than previous (and difference is > 2 billion),
>>> we know we had a reset and not a wrap.
>>
>> I do kind of prefer 64 bit counters in the general case. Nuke it from
>> orbit, it's the only way to be sure.
>
> It's 64-bit to user-space, but that means nothing because firmware
> uses 32-bit (or even 16 bit in some cases, probably) internally.
> A great deal of counters are the same, so be very careful when
> trying to keep long term counters grabbed from firmware/drivers/hardware.
>
> And, stations come and go when you re-associate, so all sorts of wifi counters
> reset themselves all the time...
Does ath driver notify mac80211 about firmware restart, ie. through
ieee80211_restart_hw(). If only user-space could get that info.
Gr. AvS
> Thanks,
> Ben
>
>>
>>> User-space stats will not be perfect in the case of firmware resets, or resets
>>> after the 'large number', but nothing is going to make it perfect, and in
>>> practice, this seems good enough.
>>>
>>> Thanks,
>>> Ben
>>>
>>> --
>>> Ben Greear <[email protected]>
>>> Candela Technologies Inc http://www.candelatech.com
>>>
>>>
>>> _______________________________________________
>>> ath10k mailing list
>>> [email protected]
>>> http://lists.infradead.org/mailman/listinfo/ath10k
>>
>>
>>
>
>
On 08/08/2014 08:55 AM, Dave Taht wrote:
> On Fri, Aug 8, 2014 at 8:42 AM, Ben Greear <[email protected]> wrote:
>> On 08/08/2014 02:06 AM, Kalle Valo wrote:
>>> Ben Greear <[email protected]> writes:
>>>
>>>> I'm working on a patch to report the stats seen in debugfs/...ath10k/fw_stats
>>>> as ethtool stats, somewhat similar to how ath9k does it.
>>>>
>>>> I notice that my user-space tool is reporting huge numbers because
>>>> the stats are reset to zero when firmware restarts, and so my tool
>>>> thinks the stats wrapped.
>>>>
>>>> I can fix my tool easily enough, but I first wanted to see if
>>>> anyone had strong feelings about keeping the stats from resetting
>>>> to zero by storing history and calculating diffs in the driver.
>>>>
>>>> I think my preference is to punt this to user-space, but if
>>>> someone feels otherwise, please let me know sooner than later.
>>>
>>> I also prefer to have this in user space, but how does user space know
>>> when the stats have been zeroed?
>>
>> Poll often enough that it cannot increment more than 2 billion (or other large number)
>> between polls, and then if polled value is less than previous (and difference is > 2 billion),
>> we know we had a reset and not a wrap.
>
> I do kind of prefer 64 bit counters in the general case. Nuke it from
> orbit, it's the only way to be sure.
It's 64-bit to user-space, but that means nothing because firmware
uses 32-bit (or even 16 bit in some cases, probably) internally.
A great deal of counters are the same, so be very careful when
trying to keep long term counters grabbed from firmware/drivers/hardware.
And, stations come and go when you re-associate, so all sorts of wifi counters
reset themselves all the time...
Thanks,
Ben
>
>> User-space stats will not be perfect in the case of firmware resets, or resets
>> after the 'large number', but nothing is going to make it perfect, and in
>> practice, this seems good enough.
>>
>> Thanks,
>> Ben
>>
>> --
>> Ben Greear <[email protected]>
>> Candela Technologies Inc http://www.candelatech.com
>>
>>
>> _______________________________________________
>> ath10k mailing list
>> [email protected]
>> http://lists.infradead.org/mailman/listinfo/ath10k
>
>
>
--
Ben Greear <[email protected]>
Candela Technologies Inc http://www.candelatech.com
On 08/08/2014 09:45 AM, Arend van Spriel wrote:
> On 08/08/2014 06:11 PM, Ben Greear wrote:
>> On 08/08/2014 08:55 AM, Dave Taht wrote:
>>> On Fri, Aug 8, 2014 at 8:42 AM, Ben Greear <[email protected]> wrote:
>>>> On 08/08/2014 02:06 AM, Kalle Valo wrote:
>>>>> Ben Greear <[email protected]> writes:
>>>>>
>>>>>> I'm working on a patch to report the stats seen in debugfs/...ath10k/fw_stats
>>>>>> as ethtool stats, somewhat similar to how ath9k does it.
>>>>>>
>>>>>> I notice that my user-space tool is reporting huge numbers because
>>>>>> the stats are reset to zero when firmware restarts, and so my tool
>>>>>> thinks the stats wrapped.
>>>>>>
>>>>>> I can fix my tool easily enough, but I first wanted to see if
>>>>>> anyone had strong feelings about keeping the stats from resetting
>>>>>> to zero by storing history and calculating diffs in the driver.
>>>>>>
>>>>>> I think my preference is to punt this to user-space, but if
>>>>>> someone feels otherwise, please let me know sooner than later.
>>>>>
>>>>> I also prefer to have this in user space, but how does user space know
>>>>> when the stats have been zeroed?
>>>>
>>>> Poll often enough that it cannot increment more than 2 billion (or other large number)
>>>> between polls, and then if polled value is less than previous (and difference is > 2 billion),
>>>> we know we had a reset and not a wrap.
>>>
>>> I do kind of prefer 64 bit counters in the general case. Nuke it from
>>> orbit, it's the only way to be sure.
>>
>> It's 64-bit to user-space, but that means nothing because firmware
>> uses 32-bit (or even 16 bit in some cases, probably) internally.
>> A great deal of counters are the same, so be very careful when
>> trying to keep long term counters grabbed from firmware/drivers/hardware.
>>
>> And, stations come and go when you re-associate, so all sorts of wifi counters
>> reset themselves all the time...
>
> Does ath driver notify mac80211 about firmware restart, ie. through ieee80211_restart_hw(). If only user-space could get that info.
We should soon have a udev event on firmware crash (and a way to read that crash log out of
debugfs). A simple restart (w/out crash) might not be so interesting?
Might be nice to have a fw restart and fw crash counter in ethtool stats in case something
wants to poll that instead of dealing with uevents. I will add those counters.
Thanks,
Ben
--
Ben Greear <[email protected]>
Candela Technologies Inc http://www.candelatech.com
On 08/08/2014 02:06 AM, Kalle Valo wrote:
> Ben Greear <[email protected]> writes:
>
>> I'm working on a patch to report the stats seen in debugfs/...ath10k/fw_stats
>> as ethtool stats, somewhat similar to how ath9k does it.
>>
>> I notice that my user-space tool is reporting huge numbers because
>> the stats are reset to zero when firmware restarts, and so my tool
>> thinks the stats wrapped.
>>
>> I can fix my tool easily enough, but I first wanted to see if
>> anyone had strong feelings about keeping the stats from resetting
>> to zero by storing history and calculating diffs in the driver.
>>
>> I think my preference is to punt this to user-space, but if
>> someone feels otherwise, please let me know sooner than later.
>
> I also prefer to have this in user space, but how does user space know
> when the stats have been zeroed?
Poll often enough that it cannot increment more than 2 billion (or other large number)
between polls, and then if polled value is less than previous (and difference is > 2 billion),
we know we had a reset and not a wrap.
User-space stats will not be perfect in the case of firmware resets, or resets
after the 'large number', but nothing is going to make it perfect, and in
practice, this seems good enough.
Thanks,
Ben
--
Ben Greear <[email protected]>
Candela Technologies Inc http://www.candelatech.com
On Fri, Aug 8, 2014 at 8:42 AM, Ben Greear <[email protected]> wrote:
> On 08/08/2014 02:06 AM, Kalle Valo wrote:
>> Ben Greear <[email protected]> writes:
>>
>>> I'm working on a patch to report the stats seen in debugfs/...ath10k/fw_stats
>>> as ethtool stats, somewhat similar to how ath9k does it.
>>>
>>> I notice that my user-space tool is reporting huge numbers because
>>> the stats are reset to zero when firmware restarts, and so my tool
>>> thinks the stats wrapped.
>>>
>>> I can fix my tool easily enough, but I first wanted to see if
>>> anyone had strong feelings about keeping the stats from resetting
>>> to zero by storing history and calculating diffs in the driver.
>>>
>>> I think my preference is to punt this to user-space, but if
>>> someone feels otherwise, please let me know sooner than later.
>>
>> I also prefer to have this in user space, but how does user space know
>> when the stats have been zeroed?
>
> Poll often enough that it cannot increment more than 2 billion (or other large number)
> between polls, and then if polled value is less than previous (and difference is > 2 billion),
> we know we had a reset and not a wrap.
I do kind of prefer 64 bit counters in the general case. Nuke it from
orbit, it's the only way to be sure.
> User-space stats will not be perfect in the case of firmware resets, or resets
> after the 'large number', but nothing is going to make it perfect, and in
> practice, this seems good enough.
>
> Thanks,
> Ben
>
> --
> Ben Greear <[email protected]>
> Candela Technologies Inc http://www.candelatech.com
>
>
> _______________________________________________
> ath10k mailing list
> [email protected]
> http://lists.infradead.org/mailman/listinfo/ath10k
--
Dave Täht
NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article
Ben Greear <[email protected]> writes:
>> Does ath driver notify mac80211 about firmware restart, ie. through
>> ieee80211_restart_hw(). If only user-space could get that info.
>
> We should soon have a udev event on firmware crash
Who should send the event, the driver or mac80211? I'm not very familiar
with udev stuff, what kind of rules there are for udev events?
> A simple restart (w/out crash) might not be so interesting?
Yeah, we should not report that. ath10k stops the firmware on interface
down and starts it again on interface up which is business as usual.
> Might be nice to have a fw restart and fw crash counter in ethtool
> stats in case something wants to poll that instead of dealing with
> uevents. I will add those counters.
Yeah, those would be great to have.
--
Kalle Valo
Ben Greear <[email protected]> writes:
> On 08/08/2014 02:06 AM, Kalle Valo wrote:
>> Ben Greear <[email protected]> writes:
>>
>>> I'm working on a patch to report the stats seen in debugfs/...ath10k/fw_stats
>>> as ethtool stats, somewhat similar to how ath9k does it.
>>>
>>> I notice that my user-space tool is reporting huge numbers because
>>> the stats are reset to zero when firmware restarts, and so my tool
>>> thinks the stats wrapped.
>>>
>>> I can fix my tool easily enough, but I first wanted to see if
>>> anyone had strong feelings about keeping the stats from resetting
>>> to zero by storing history and calculating diffs in the driver.
>>>
>>> I think my preference is to punt this to user-space, but if
>>> someone feels otherwise, please let me know sooner than later.
>>
>> I also prefer to have this in user space, but how does user space know
>> when the stats have been zeroed?
>
> Poll often enough that it cannot increment more than 2 billion (or
> other large number) between polls, and then if polled value is less
> than previous (and difference is > 2 billion), we know we had a reset
> and not a wrap.
That's not very reliable as "less than previous" assumption is not
always true.
> User-space stats will not be perfect in the case of firmware resets, or resets
> after the 'large number', but nothing is going to make it perfect, and in
> practice, this seems good enough.
Yeah, and we can always fix this later if there's a sudden need to get
reliable numbers.
--
Kalle Valo
Arend van Spriel <[email protected]> writes:
>>> I do kind of prefer 64 bit counters in the general case. Nuke it from
>>> orbit, it's the only way to be sure.
>>
>> It's 64-bit to user-space, but that means nothing because firmware
>> uses 32-bit (or even 16 bit in some cases, probably) internally.
>> A great deal of counters are the same, so be very careful when
>> trying to keep long term counters grabbed from firmware/drivers/hardware.
>>
>> And, stations come and go when you re-associate, so all sorts of wifi counters
>> reset themselves all the time...
>
> Does ath driver notify mac80211 about firmware restart, ie. through
> ieee80211_restart_hw().
ath10k does use ieee80211_restart_hw().
> If only user-space could get that info.
Yeah, that would be nice to have for ath10k firmware crash dump
functionality. And doesn't Android also need something similar?
--
Kalle Valo
Arend van Spriel <[email protected]> writes:
>>> Does ath driver notify mac80211 about firmware restart, ie. through
>>> ieee80211_restart_hw().
>>
>> ath10k does use ieee80211_restart_hw().
>>
>>> If only user-space could get that info.
>>
>> Yeah, that would be nice to have for ath10k firmware crash dump
>> functionality. And doesn't Android also need something similar?
>
> Probably. bcmdhd seems to send a "firmware hang" event up to wpa_supp,
> which probably ends up in the android wifi framework through the
> control interface. Currently, this is a driver private event handled
> by wpa_supplicant_lib, but it seems trivial to me to add a nl80211
> event to trigger that.
>
> I am not sure what infrastructure your "ath10k firmware crash dump" is
> going to use.
Currently we are planning to just provide a debugfs file to retrieve the
latest dump.
> I have seen similar thing from Marvell recently [1] which relies on
> udev and ethtool to do the work. I guess aligning the solutions is why
> this topic is listed for the wireless breakout session at kernel
> summit in Chicago.
Yeah, we did talk about that a bit in the mailing list few months back.
--
Kalle Valo
On 08/09/2014 08:30 AM, Kalle Valo wrote:
> Arend van Spriel <[email protected]> writes:
>
>>>> I do kind of prefer 64 bit counters in the general case. Nuke it from
>>>> orbit, it's the only way to be sure.
>>>
>>> It's 64-bit to user-space, but that means nothing because firmware
>>> uses 32-bit (or even 16 bit in some cases, probably) internally.
>>> A great deal of counters are the same, so be very careful when
>>> trying to keep long term counters grabbed from firmware/drivers/hardware.
>>>
>>> And, stations come and go when you re-associate, so all sorts of wifi counters
>>> reset themselves all the time...
>>
>> Does ath driver notify mac80211 about firmware restart, ie. through
>> ieee80211_restart_hw().
>
> ath10k does use ieee80211_restart_hw().
>
>> If only user-space could get that info.
>
> Yeah, that would be nice to have for ath10k firmware crash dump
> functionality. And doesn't Android also need something similar?
Probably. bcmdhd seems to send a "firmware hang" event up to wpa_supp,
which probably ends up in the android wifi framework through the control
interface. Currently, this is a driver private event handled by
wpa_supplicant_lib, but it seems trivial to me to add a nl80211 event to
trigger that.
I am not sure what infrastructure your "ath10k firmware crash dump" is
going to use. I have seen similar thing from Marvell recently [1] which
relies on udev and ethtool to do the work. I guess aligning the
solutions is why this topic is listed for the wireless breakout session
at kernel summit in Chicago.
Regards,
Arend
[1] http://www.spinics.net/lists/linux-wireless/msg123943.html
Ben Greear <[email protected]> writes:
> I'm working on a patch to report the stats seen in debugfs/...ath10k/fw_stats
> as ethtool stats, somewhat similar to how ath9k does it.
>
> I notice that my user-space tool is reporting huge numbers because
> the stats are reset to zero when firmware restarts, and so my tool
> thinks the stats wrapped.
>
> I can fix my tool easily enough, but I first wanted to see if
> anyone had strong feelings about keeping the stats from resetting
> to zero by storing history and calculating diffs in the driver.
>
> I think my preference is to punt this to user-space, but if
> someone feels otherwise, please let me know sooner than later.
I also prefer to have this in user space, but how does user space know
when the stats have been zeroed?
--
Kalle Valo