netdev - Re: [PATCH iproute2 net-next] ifstat: move to new RTM

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]

Date:	Tue, 10 May 2016 09:25:14 -0700
From:	Roopa Prabhu <roopa@...ulusnetworks.com>
To:	Jamal Hadi Salim <jhs@...atatu.com>
CC:	stephen@...workplumber.org, netdev@...r.kernel.org,
	davem@...emloft.net, edumazet@...gle.com, tgraf@...g.ch,
	nicolas.dichtel@...nd.com, nikolay@...ulusnetworks.com
Subject: Re: [PATCH iproute2 net-next] ifstat: move to new RTM_GETSTATS api

On 5/9/16, 5:38 AM, Jamal Hadi Salim wrote:
> On 16-05-09 12:49 AM, Roopa Prabhu wrote:
>> On 4/30/16, 8:15 AM, Roopa Prabhu wrote:
>>> On 4/30/16, 3:21 AM, Jamal Hadi Salim wrote:
>
>> AFAICS ifstat history file handling today assumes all 32 bit stats.
>
> Indeed it does.
>
>> And to preserve backward compatibility, new ifstat should work with old and
>> new history files with 32bit and 64 bit stats.
>
> True.
> It may be ok to just provide a conversion tool maybe for taking 32b
> history into 64b? I dont know if someone is going to "migrate" their
> history files so even that may not be worth it.
>
>> The file format cannot be changed because of the same backward compat issues.
>> So, I am leaning towards a new history file with a new option (maybe ifstat -64) to
>> save/query 64 bit stats using the new api when available.
>>
>> I see some previous brief discussions on moving ifstat to 64 bit.
>>
>> The other option is to only change 'ip -s link show' to use the new stats api.
>>
>> let me know if there are other thoughts.
>>
>
> Is it not possible to convert to 64b - and IFLA_STAT
> becomes available just store it still in 64b?
> i.e 32b will fit in 64b space.

The only problem is again if the last saved history file had 32 bit
and 32bit counters may roll over earlier.

One more thing i am looking at right now which might work is using
 the existing history file and use the info_source (aka header) in ifstat history file to indicate
32bit or 64bit stats. For 32 bit it is currently "#kernel".
For 64 bit i plan to use "#kernel64".

If we are starting a new history file, i will always use 64bit and when using an existing history file,
it will use 32bit.

And 64bit stats will be queried with RTM_GETSTATS if available or will use IFLA_STATS64 when
RTM_NEWLINK Is used.

will see if i can get this working for all cases,

thanks,
Roopa