netdev - Re: [RFC 00/14] netlink/hierarchical stats

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] [day] [month] [year] [list]

Date:   Thu, 7 Feb 2019 08:23:11 -0800
From:   Jakub Kicinski <jakub.kicinski@...ronome.com>
To:     Florian Fainelli <f.fainelli@...il.com>
Cc:     davem@...emloft.net, oss-drivers@...ronome.com,
        netdev@...r.kernel.org, jiri@...nulli.us, andrew@...n.ch,
        mkubecek@...e.cz, dsahern@...il.com, simon.horman@...ronome.com,
        jesse.brandeburg@...el.com, maciejromanfijalkowski@...il.com,
        vasundhara-v.volam@...adcom.com, michael.chan@...adcom.com,
        shalomt@...lanox.com, idosch@...lanox.com
Subject: Re: [RFC 00/14] netlink/hierarchical stats

On Wed, 6 Feb 2019 12:12:39 -0800, Florian Fainelli wrote:
> > By refresh control I mean the ability for user space to indicate how
> > "fresh" values it expects.  Sometimes reading the HW counters requires
> > slow register reads or FW communication, in such cases drivers may cache
> > the result.  (Privileged) user space should be able to add a "not older
> > than" timestamp to indicate how fresh statistics it expects.  And vice
> > versa, drivers can then also put the timestamp of when the statistics
> > were last refreshed in the dump for more precise bandwidth estimation.  
> 
> Another thing that we cannot quite do with ethtool right now, at least
> not easily, is something like the following use case.
> 
> You have some filtering/classification capable hardware, and the HW can
> count the number of times a rule has been hit/missed. The number of
> rules programmed into the HW is dynamic and depends on use case so
> dumping them all is not convenient for e.g.: hundreds/thousands of rules.

That raises the inevitable question of what is the source of the rules
i.e. which API has been used to configure them?

> You would want to return only the rules that are active/enabled, and not
> the full possible range of rules. With ethtool, this is not possible
> because you have to define the strings first, and in a second call, you
> are going to get the dump and fill in the data returned to user-space...

Interesting, if the driver is caching the stats it can remember both
last refresh and last change and return only the statistics which
changed since time X.  Would the "last changed" time stamp be of any
use to user space?  Probably not, right?

> I will review more in depth, but the idea looks great so far.

Thanks!