On 03/20/2018 09:11 AM, Steve deRosier wrote:
On Tue, Mar 20, 2018 at 8:39 AM, Ben Greear <greearb@xxxxxxxxxxxxxxx> wrote:
On 03/20/2018 03:37 AM, Michal Kubecek wrote:
On Wed, Mar 07, 2018 at 11:51:29AM -0800, greearb@xxxxxxxxxxxxxxx wrote:
From: Ben Greear <greearb@xxxxxxxxxxxxxxx>
This is similar to ETHTOOL_GSTATS, but it allows you to specify
a 'level'. This level can be used by the driver to decrease the
amount of stats refreshed. In particular, this helps with ath10k
since getting the firmware stats can be slow.
Signed-off-by: Ben Greear <greearb@xxxxxxxxxxxxxxx>
---
NOTE: I know to make it upstream I would need to split the patch and
remove the #define for 'backporting' that I added. But, is the
feature in general wanted? If so, I'll do the patch split and
other tweaks that might be suggested.
Yes, but that would require changing all drivers at once, and would make
backporting
and out-of-tree drivers harder to manage. I had low hopes that this feature
would
make it upstream, so I didn't want to propose any large changes up front.
Hi Ben,
I find the feature OK, but I'm not thrilled with the arbitrary scale
of "level". Maybe there could be some named values, either on a
spectrum as level already is, similar to the kernel log DEBUG, WARN,
INFO.... type levels. Or named bit flags like the way the ath drivers
do their debug flags for granular results. Thoughts?
Yes, that would be easier to code too. If there are any other drivers
out there that might take advantage of this, maybe they could chime in with
what levels and/or bit-fields they would like to see.
For instance a bit that says 'refresh-stats-from-firmware' would be great for ath10k,
but maybe useless for everyone else....
Thanks,
Ben
- Steve
--
Ben Greear <greearb@xxxxxxxxxxxxxxx>
Candela Technologies Inc http://www.candelatech.com
