Reporting firmware stats to ethtool

[Ben Greear]

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 <greearb at candelatech.com> wrote:
>>>> On 08/08/2014 02:06 AM, Kalle Valo wrote:
>>>>> Ben Greear <greearb at candelatech.com> 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 <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com