From: Arend van Spriel <arend@broadcom.com>
To: Ben Greear <greearb@candelatech.com>, Dave Taht <dave.taht@gmail.com>
Cc: Kalle Valo <kvalo@qca.qualcomm.com>,
"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
ath10k <ath10k@lists.infradead.org>
Subject: Re: Reporting firmware stats to ethtool
Date: Fri, 8 Aug 2014 18:45:29 +0200 [thread overview]
Message-ID: <53E4FEA9.80803@broadcom.com> (raw)
In-Reply-To: <53E4F6B8.50009@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 <greearb@candelatech.com> wrote:
>>> On 08/08/2014 02:06 AM, Kalle Valo wrote:
>>>> Ben Greear <greearb@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.
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 <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
WARNING: multiple messages have this Message-ID (diff)
From: Arend van Spriel <arend@broadcom.com>
To: Ben Greear <greearb@candelatech.com>, Dave Taht <dave.taht@gmail.com>
Cc: Kalle Valo <kvalo@qca.qualcomm.com>,
"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
ath10k <ath10k@lists.infradead.org>
Subject: Re: Reporting firmware stats to ethtool
Date: Fri, 8 Aug 2014 18:45:29 +0200 [thread overview]
Message-ID: <53E4FEA9.80803@broadcom.com> (raw)
In-Reply-To: <53E4F6B8.50009@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 <greearb@candelatech.com> wrote:
>>> On 08/08/2014 02:06 AM, Kalle Valo wrote:
>>>> Ben Greear <greearb@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.
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 <greearb@candelatech.com>
>>> Candela Technologies Inc http://www.candelatech.com
>>>
>>>
>>> _______________________________________________
>>> ath10k mailing list
>>> ath10k@lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/ath10k
>>
>>
>>
>
>
next prev parent reply other threads:[~2014-08-08 16:45 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-07 21:57 Reporting firmware stats to ethtool Ben Greear
2014-08-07 21:57 ` Ben Greear
2014-08-08 9:06 ` Kalle Valo
2014-08-08 9:06 ` Kalle Valo
2014-08-08 15:42 ` Ben Greear
2014-08-08 15:42 ` Ben Greear
2014-08-08 15:55 ` Dave Taht
2014-08-08 15:55 ` Dave Taht
2014-08-08 16:11 ` Ben Greear
2014-08-08 16:11 ` Ben Greear
2014-08-08 16:45 ` Arend van Spriel [this message]
2014-08-08 16:45 ` Arend van Spriel
2014-08-08 17:24 ` Ben Greear
2014-08-08 17:24 ` Ben Greear
2014-08-09 6:32 ` Kalle Valo
2014-08-09 6:32 ` Kalle Valo
2014-08-09 6:30 ` Kalle Valo
2014-08-09 6:30 ` Kalle Valo
2014-08-09 7:30 ` Arend van Spriel
2014-08-09 7:30 ` Arend van Spriel
2014-08-09 15:56 ` Kalle Valo
2014-08-09 15:56 ` Kalle Valo
2014-08-09 6:27 ` Kalle Valo
2014-08-09 6:27 ` Kalle Valo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53E4FEA9.80803@broadcom.com \
--to=arend@broadcom.com \
--cc=ath10k@lists.infradead.org \
--cc=dave.taht@gmail.com \
--cc=greearb@candelatech.com \
--cc=kvalo@qca.qualcomm.com \
--cc=linux-wireless@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.