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  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]
Date:   Sun, 27 Nov 2016 10:00:18 -0800
From:   Roopa Prabhu <roopa@...ulusnetworks.com>
To:     Nogah Frankel <nogahf@...lanox.com>
CC:     netdev@...r.kernel.org, eladr@...lanox.com, yotamg@...lanox.com,
        jiri@...lanox.com, idosch@...lanox.com, ogerlitz@...lanox.com,
        Nikolay Aleksandrov <nikolay@...ulusnetworks.com>
Subject: Re: [PATCH iproute2 0/3] update ifstat for new stats

(resending ...failed to send it to the list earlier)

On 11/24/16, 6:12 AM, Nogah Frankel wrote:
> Previously stats were gotten by RTM_GETLINK which return 32 bits based
> statistics. It support only one type of stats.
> Lately, a new method to get stats was added - RTM_GETSTATS. It supports
> ability to choose stats type. The basic stats were changed from 32 bits
> based to 64 bits based.
>
> This patchset change ifstat to the new method, add it the ability to
> choose an extended type of statistic, and add the extended type of SW
> stats for packets that hit cpu.
>
>


(please cc me on the GETSTATS patches)

This looks similar to the one I had submitted here: https://www.spinics.net/lists/netdev/msg375546.html <https://www.spinics.net/lists/netdev/msg375546.html>

There are a few issues with this approach.. (unless they have already been looked at by your patch series).
 This fails new ifstat on older kernels. Moving to 64bit also invalidates existing ifstats history file. 
If you follow the discussion on my patch, there is a way to move to a new history file for 64bit
stats file and still be compatible (ie create a new file for 64 bit stats).

I had started work on fixing these limitations..., but then re-thinking all other new stats in one place
in the context of the new stats api, it is better to extend ip link. This work is also in progress.
here is how we think it should be (also CCing nikolay):

ip link stats /* similar to ip -s link for completeness */
ip link xstats [igmp|lacp]  /* depending on link-type */
ip link afstats [inet|inet6|mpls] /* depending on link-family */
ip link offloadstas [cpu|..]

possible future global non-link stats with 'ip stats [tcp]' and so on.

Powered by blists - more mailing lists