netdev - Re: [RFC] ethtool: Support ETHTOOL

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CALLGbRKU_PCk-3ZMBRu6CC-QyaEEPTAOavGVzPpQUdEMQ+s9BQ@mail.gmail.com>
Date:   Tue, 20 Mar 2018 09:11:21 -0700
From:   Steve deRosier <derosier@...il.com>
To:     Ben Greear <greearb@...delatech.com>
Cc:     Michal Kubecek <mkubecek@...e.cz>,
        linux-wireless <linux-wireless@...r.kernel.org>,
        ath10k@...ts.infradead.org, netdev@...r.kernel.org
Subject: Re: [RFC] ethtool: Support ETHTOOL_GSTATS2 command.

On Tue, Mar 20, 2018 at 8:39 AM, Ben Greear <greearb@...delatech.com> wrote:
> On 03/20/2018 03:37 AM, Michal Kubecek wrote:
>>
>> On Wed, Mar 07, 2018 at 11:51:29AM -0800, greearb@...delatech.com wrote:
>>>
>>> From: Ben Greear <greearb@...delatech.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@...delatech.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?

- Steve