All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ben Greear <greearb@candelatech.com>
To: Steve deRosier <derosier@gmail.com>
Cc: Michal Kubecek <mkubecek@suse.cz>,
	linux-wireless <linux-wireless@vger.kernel.org>,
	ath10k@lists.infradead.org, netdev@vger.kernel.org
Subject: Re: [RFC] ethtool: Support ETHTOOL_GSTATS2 command.
Date: Tue, 20 Mar 2018 09:24:52 -0700	[thread overview]
Message-ID: <1db22103-4f4c-18e9-e03c-6f8b69b9f74f@candelatech.com> (raw)
In-Reply-To: <CALLGbRKU_PCk-3ZMBRu6CC-QyaEEPTAOavGVzPpQUdEMQ+s9BQ@mail.gmail.com>

On 03/20/2018 09:11 AM, Steve deRosier wrote:
> On Tue, Mar 20, 2018 at 8:39 AM, Ben Greear <greearb@candelatech.com> wrote:
>> On 03/20/2018 03:37 AM, Michal Kubecek wrote:
>>>
>>> On Wed, Mar 07, 2018 at 11:51:29AM -0800, greearb@candelatech.com wrote:
>>>>
>>>> From: Ben Greear <greearb@candelatech.com>
>>>>
>>>> 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@candelatech.com>
>>>> ---
>>>>
>>>> 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@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

WARNING: multiple messages have this Message-ID (diff)
From: Ben Greear <greearb-my8/4N5VtI7c+919tysfdA@public.gmane.org>
To: Steve deRosier <derosier-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Michal Kubecek <mkubecek-AlSwsSmVLrQ@public.gmane.org>,
	linux-wireless
	<linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	ath10k-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [RFC] ethtool: Support ETHTOOL_GSTATS2 command.
Date: Tue, 20 Mar 2018 09:24:52 -0700	[thread overview]
Message-ID: <1db22103-4f4c-18e9-e03c-6f8b69b9f74f@candelatech.com> (raw)
In-Reply-To: <CALLGbRKU_PCk-3ZMBRu6CC-QyaEEPTAOavGVzPpQUdEMQ+s9BQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

On 03/20/2018 09:11 AM, Steve deRosier wrote:
> On Tue, Mar 20, 2018 at 8:39 AM, Ben Greear <greearb-my8/4N5VtI7c+919tysfdA@public.gmane.org> wrote:
>> On 03/20/2018 03:37 AM, Michal Kubecek wrote:
>>>
>>> On Wed, Mar 07, 2018 at 11:51:29AM -0800, greearb-my8/4N5VtI7c+919tysfdA@public.gmane.org wrote:
>>>>
>>>> From: Ben Greear <greearb-my8/4N5VtI7c+919tysfdA@public.gmane.org>
>>>>
>>>> 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-my8/4N5VtI7c+919tysfdA@public.gmane.org>
>>>> ---
>>>>
>>>> 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-my8/4N5VtI7c+919tysfdA@public.gmane.org>
Candela Technologies Inc  http://www.candelatech.com

WARNING: multiple messages have this Message-ID (diff)
From: Ben Greear <greearb@candelatech.com>
To: Steve deRosier <derosier@gmail.com>
Cc: Michal Kubecek <mkubecek@suse.cz>,
	netdev@vger.kernel.org,
	linux-wireless <linux-wireless@vger.kernel.org>,
	ath10k@lists.infradead.org
Subject: Re: [RFC] ethtool: Support ETHTOOL_GSTATS2 command.
Date: Tue, 20 Mar 2018 09:24:52 -0700	[thread overview]
Message-ID: <1db22103-4f4c-18e9-e03c-6f8b69b9f74f@candelatech.com> (raw)
In-Reply-To: <CALLGbRKU_PCk-3ZMBRu6CC-QyaEEPTAOavGVzPpQUdEMQ+s9BQ@mail.gmail.com>

On 03/20/2018 09:11 AM, Steve deRosier wrote:
> On Tue, Mar 20, 2018 at 8:39 AM, Ben Greear <greearb@candelatech.com> wrote:
>> On 03/20/2018 03:37 AM, Michal Kubecek wrote:
>>>
>>> On Wed, Mar 07, 2018 at 11:51:29AM -0800, greearb@candelatech.com wrote:
>>>>
>>>> From: Ben Greear <greearb@candelatech.com>
>>>>
>>>> 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@candelatech.com>
>>>> ---
>>>>
>>>> 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@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

  reply	other threads:[~2018-03-20 16:24 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-07 19:51 [RFC] ethtool: Support ETHTOOL_GSTATS2 command greearb
2018-03-07 19:51 ` greearb
2018-03-07 19:51 ` greearb
2018-03-20 10:37 ` Michal Kubecek
2018-03-20 10:37   ` Michal Kubecek
2018-03-20 10:37   ` Michal Kubecek
2018-03-20 15:39   ` Ben Greear
2018-03-20 15:39     ` Ben Greear
2018-03-20 15:39     ` Ben Greear
2018-03-20 16:11     ` Steve deRosier
2018-03-20 16:11       ` Steve deRosier
2018-03-20 16:11       ` Steve deRosier
2018-03-20 16:24       ` Ben Greear [this message]
2018-03-20 16:24         ` Ben Greear
2018-03-20 16:24         ` Ben Greear
2018-03-20 18:24     ` Michal Kubecek
2018-03-20 18:24       ` Michal Kubecek
2018-03-20 18:24       ` Michal Kubecek
2018-03-20 18:29       ` Ben Greear
2018-03-20 18:29         ` Ben Greear
2018-03-20 18:29         ` Ben Greear

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=1db22103-4f4c-18e9-e03c-6f8b69b9f74f@candelatech.com \
    --to=greearb@candelatech.com \
    --cc=ath10k@lists.infradead.org \
    --cc=derosier@gmail.com \
    --cc=linux-wireless@vger.kernel.org \
    --cc=mkubecek@suse.cz \
    --cc=netdev@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.