* Reporting firmware stats to ethtool @ 2014-08-07 21:57 ` Ben Greear 0 siblings, 0 replies; 24+ messages in thread From: Ben Greear @ 2014-08-07 21:57 UTC (permalink / raw) To: ath10k, linux-wireless@vger.kernel.org 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 <greearb@candelatech.com> Candela Technologies Inc http://www.candelatech.com _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 24+ messages in thread
* Reporting firmware stats to ethtool @ 2014-08-07 21:57 ` Ben Greear 0 siblings, 0 replies; 24+ messages in thread From: Ben Greear @ 2014-08-07 21:57 UTC (permalink / raw) To: ath10k, linux-wireless@vger.kernel.org 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 <greearb@candelatech.com> Candela Technologies Inc http://www.candelatech.com ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Reporting firmware stats to ethtool 2014-08-07 21:57 ` Ben Greear @ 2014-08-08 9:06 ` Kalle Valo -1 siblings, 0 replies; 24+ messages in thread From: Kalle Valo @ 2014-08-08 9:06 UTC (permalink / raw) To: Ben Greear; +Cc: linux-wireless@vger.kernel.org, ath10k 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? -- Kalle Valo _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Reporting firmware stats to ethtool @ 2014-08-08 9:06 ` Kalle Valo 0 siblings, 0 replies; 24+ messages in thread From: Kalle Valo @ 2014-08-08 9:06 UTC (permalink / raw) To: Ben Greear; +Cc: ath10k, linux-wireless@vger.kernel.org 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? -- Kalle Valo ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Reporting firmware stats to ethtool 2014-08-08 9:06 ` Kalle Valo @ 2014-08-08 15:42 ` Ben Greear -1 siblings, 0 replies; 24+ messages in thread From: Ben Greear @ 2014-08-08 15:42 UTC (permalink / raw) To: Kalle Valo; +Cc: linux-wireless@vger.kernel.org, ath10k 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. 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Reporting firmware stats to ethtool @ 2014-08-08 15:42 ` Ben Greear 0 siblings, 0 replies; 24+ messages in thread From: Ben Greear @ 2014-08-08 15:42 UTC (permalink / raw) To: Kalle Valo; +Cc: ath10k, linux-wireless@vger.kernel.org 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. 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Reporting firmware stats to ethtool 2014-08-08 15:42 ` Ben Greear @ 2014-08-08 15:55 ` Dave Taht -1 siblings, 0 replies; 24+ messages in thread From: Dave Taht @ 2014-08-08 15:55 UTC (permalink / raw) To: Ben Greear; +Cc: Kalle Valo, linux-wireless@vger.kernel.org, ath10k 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. > 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 -- Dave Täht NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Reporting firmware stats to ethtool @ 2014-08-08 15:55 ` Dave Taht 0 siblings, 0 replies; 24+ messages in thread From: Dave Taht @ 2014-08-08 15:55 UTC (permalink / raw) To: Ben Greear; +Cc: Kalle Valo, linux-wireless@vger.kernel.org, ath10k 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. > 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 -- Dave Täht NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Reporting firmware stats to ethtool 2014-08-08 15:55 ` Dave Taht @ 2014-08-08 16:11 ` Ben Greear -1 siblings, 0 replies; 24+ messages in thread From: Ben Greear @ 2014-08-08 16:11 UTC (permalink / raw) To: Dave Taht; +Cc: Kalle Valo, linux-wireless@vger.kernel.org, ath10k 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... 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 > > > -- 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Reporting firmware stats to ethtool @ 2014-08-08 16:11 ` Ben Greear 0 siblings, 0 replies; 24+ messages in thread From: Ben Greear @ 2014-08-08 16:11 UTC (permalink / raw) To: Dave Taht; +Cc: Kalle Valo, linux-wireless@vger.kernel.org, ath10k 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... 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 > > > -- Ben Greear <greearb@candelatech.com> Candela Technologies Inc http://www.candelatech.com ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Reporting firmware stats to ethtool 2014-08-08 16:11 ` Ben Greear @ 2014-08-08 16:45 ` Arend van Spriel -1 siblings, 0 replies; 24+ messages in thread From: Arend van Spriel @ 2014-08-08 16:45 UTC (permalink / raw) To: Ben Greear, Dave Taht; +Cc: Kalle Valo, linux-wireless@vger.kernel.org, ath10k 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Reporting firmware stats to ethtool @ 2014-08-08 16:45 ` Arend van Spriel 0 siblings, 0 replies; 24+ messages in thread From: Arend van Spriel @ 2014-08-08 16:45 UTC (permalink / raw) To: Ben Greear, Dave Taht; +Cc: Kalle Valo, linux-wireless@vger.kernel.org, ath10k 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 >> >> >> > > ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Reporting firmware stats to ethtool 2014-08-08 16:45 ` Arend van Spriel @ 2014-08-08 17:24 ` Ben Greear -1 siblings, 0 replies; 24+ messages in thread From: Ben Greear @ 2014-08-08 17:24 UTC (permalink / raw) To: Arend van Spriel Cc: Kalle Valo, linux-wireless@vger.kernel.org, Dave Taht, ath10k 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@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. 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@candelatech.com> Candela Technologies Inc http://www.candelatech.com _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Reporting firmware stats to ethtool @ 2014-08-08 17:24 ` Ben Greear 0 siblings, 0 replies; 24+ messages in thread From: Ben Greear @ 2014-08-08 17:24 UTC (permalink / raw) To: Arend van Spriel Cc: Dave Taht, Kalle Valo, linux-wireless@vger.kernel.org, ath10k 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@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. 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@candelatech.com> Candela Technologies Inc http://www.candelatech.com ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Reporting firmware stats to ethtool 2014-08-08 17:24 ` Ben Greear @ 2014-08-09 6:32 ` Kalle Valo -1 siblings, 0 replies; 24+ messages in thread From: Kalle Valo @ 2014-08-09 6:32 UTC (permalink / raw) To: Ben Greear Cc: Arend van Spriel, linux-wireless@vger.kernel.org, Dave Taht, ath10k Ben Greear <greearb@candelatech.com> 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 _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Reporting firmware stats to ethtool @ 2014-08-09 6:32 ` Kalle Valo 0 siblings, 0 replies; 24+ messages in thread From: Kalle Valo @ 2014-08-09 6:32 UTC (permalink / raw) To: Ben Greear Cc: Arend van Spriel, Dave Taht, linux-wireless@vger.kernel.org, ath10k Ben Greear <greearb@candelatech.com> 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Reporting firmware stats to ethtool 2014-08-08 16:45 ` Arend van Spriel @ 2014-08-09 6:30 ` Kalle Valo -1 siblings, 0 replies; 24+ messages in thread From: Kalle Valo @ 2014-08-09 6:30 UTC (permalink / raw) To: Arend van Spriel Cc: Ben Greear, linux-wireless@vger.kernel.org, Dave Taht, ath10k Arend van Spriel <arend@broadcom.com> 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 _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Reporting firmware stats to ethtool @ 2014-08-09 6:30 ` Kalle Valo 0 siblings, 0 replies; 24+ messages in thread From: Kalle Valo @ 2014-08-09 6:30 UTC (permalink / raw) To: Arend van Spriel Cc: Ben Greear, Dave Taht, linux-wireless@vger.kernel.org, ath10k Arend van Spriel <arend@broadcom.com> 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Reporting firmware stats to ethtool 2014-08-09 6:30 ` Kalle Valo @ 2014-08-09 7:30 ` Arend van Spriel -1 siblings, 0 replies; 24+ messages in thread From: Arend van Spriel @ 2014-08-09 7:30 UTC (permalink / raw) To: Kalle Valo Cc: Ben Greear, linux-wireless@vger.kernel.org, Dave Taht, ath10k, Franky Lin On 08/09/2014 08:30 AM, Kalle Valo wrote: > Arend van Spriel <arend@broadcom.com> 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 _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Reporting firmware stats to ethtool @ 2014-08-09 7:30 ` Arend van Spriel 0 siblings, 0 replies; 24+ messages in thread From: Arend van Spriel @ 2014-08-09 7:30 UTC (permalink / raw) To: Kalle Valo Cc: Ben Greear, Dave Taht, linux-wireless@vger.kernel.org, ath10k, Franky Lin On 08/09/2014 08:30 AM, Kalle Valo wrote: > Arend van Spriel <arend@broadcom.com> 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Reporting firmware stats to ethtool 2014-08-09 7:30 ` Arend van Spriel @ 2014-08-09 15:56 ` Kalle Valo -1 siblings, 0 replies; 24+ messages in thread From: Kalle Valo @ 2014-08-09 15:56 UTC (permalink / raw) To: Arend van Spriel Cc: Ben Greear, linux-wireless@vger.kernel.org, Dave Taht, ath10k, Franky Lin Arend van Spriel <arend@broadcom.com> 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 _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Reporting firmware stats to ethtool @ 2014-08-09 15:56 ` Kalle Valo 0 siblings, 0 replies; 24+ messages in thread From: Kalle Valo @ 2014-08-09 15:56 UTC (permalink / raw) To: Arend van Spriel Cc: Ben Greear, Dave Taht, linux-wireless@vger.kernel.org, ath10k, Franky Lin Arend van Spriel <arend@broadcom.com> 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Reporting firmware stats to ethtool 2014-08-08 15:42 ` Ben Greear @ 2014-08-09 6:27 ` Kalle Valo -1 siblings, 0 replies; 24+ messages in thread From: Kalle Valo @ 2014-08-09 6:27 UTC (permalink / raw) To: Ben Greear; +Cc: linux-wireless@vger.kernel.org, ath10k Ben Greear <greearb@candelatech.com> writes: > 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. 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 _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Reporting firmware stats to ethtool @ 2014-08-09 6:27 ` Kalle Valo 0 siblings, 0 replies; 24+ messages in thread From: Kalle Valo @ 2014-08-09 6:27 UTC (permalink / raw) To: Ben Greear; +Cc: ath10k, linux-wireless@vger.kernel.org Ben Greear <greearb@candelatech.com> writes: > 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. 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2014-08-09 15:57 UTC | newest] Thread overview: 24+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 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 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
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.