netdev - Re: [patch net-next v6_repost 2/3] net: core: add SW stats to if_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] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 23 Aug 2016 09:26:51 +0200
From:   Jiri Pirko <jiri@...nulli.us>
To:     David Miller <davem@...emloft.net>
Cc:     roopa@...ulusnetworks.com, netdev@...r.kernel.org,
        nogahf@...lanox.com, idosch@...lanox.com, eladr@...lanox.com,
        yotamg@...lanox.com, ogerlitz@...lanox.com,
        nikolay@...ulusnetworks.com, linville@...driver.com, tgraf@...g.ch,
        gospo@...ulusnetworks.com, sfeldma@...il.com, sd@...asysnail.net,
        eranbe@...lanox.com, ast@...mgrid.com, edumazet@...gle.com,
        hannes@...essinduktion.org, f.fainelli@...il.com,
        dsa@...ulusnetworks.com
Subject: Re: [patch net-next v6_repost 2/3] net: core: add SW stats to
 if_stats_msg

Tue, Aug 23, 2016 at 09:04:15AM CEST, davem@...emloft.net wrote:
>From: Jiri Pirko <jiri@...nulli.us>
>Date: Tue, 23 Aug 2016 08:53:18 +0200
>
>> Anyway I think that next level of nesting is not necessary. On
>> contrary, it is wrong. The current level is extensible, mixed and
>> flagged already. I don't see any reason why not to add whatever kind of
>> stats here. What makes IFLA_STATS_LINK_SW_64 or for example
>> IFLA_STATS_LINK_HW_ACL so special it has to be nested in some other
>> attr? I would understand it it would be values of one family, but that
>> is not the case.
>
>First, I agree with Roopa.  If we want to put this stuff out
>there is should be bucketed together in a nested attribute with
>other similar stats specifications.

Well I still don't think that IFLA_STATS_LINK_SW_64 and
IFLA_STATS_LINK_HW_ACL are related. You cannot put it under *DRIVER*
nest as IFLA_STATS_LINK_SW_64 are core stats. So we can put them under
*MISC* nest attr. But that is exactly purpose of the top-level here.
/me confused


>
>Second, the more I think about this what you're providing isn't
>actually a new statistic type.
>
>It's a filter.
>
>So why don't we just provide a filter specification that gets passed
>down into the driver.  And the user can ask for "SW stats" or whatever
>using that.

for this particular stats (sw stats) you can look at it that way. The
question is that in case we handle it the filter way instead of
multiattr way. Is it convenient for user to do 2 netlink calls instead
of one? I tend to like the one-call-flag-what-you-want approach better.