netdev - Re: [PATCH net-next] net: bridge: add support for per-port vlan 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]

Message-ID: <028C9C97-5802-40A8-947C-09C631A2FE05@cumulusnetworks.com>
Date:   Fri, 12 Oct 2018 19:04:33 +0300
From:   Nikolay Aleksandrov <nikolay@...ulusnetworks.com>
To:     Stephen Hemminger <stephen@...workplumber.org>
CC:     netdev@...r.kernel.org, davem@...emloft.net,
        bridge@...ts.linux-foundation.org,
        Roopa Prabhu <roopa@...ulusnetworks.com>
Subject: Re: [PATCH net-next] net: bridge: add support for per-port vlan stats

On October 12, 2018 6:39:32 PM GMT+03:00, Stephen Hemminger <stephen@...workplumber.org> wrote:
>On Fri, 12 Oct 2018 13:41:16 +0300
>Nikolay Aleksandrov <nikolay@...ulusnetworks.com> wrote:
>
>> This patch adds an option to have per-port vlan stats instead of the
>> default global stats. The option can be set only when there are no
>port
>> vlans in the bridge since we need to allocate the stats if it is set
>> when vlans are being added to ports (and respectively free them
>> when being deleted). Also bump RTNL_MAX_TYPE as the bridge is the
>> largest user of options. The current stats design allows us to add
>> these without any changes to the fast-path, it all comes down to
>> the per-vlan stats pointer which, if this option is enabled, will
>> be allocated for each port vlan instead of using the global
>bridge-wide
>> one.
>> 
>> CC: bridge@...ts.linux-foundation.org
>> CC: Roopa Prabhu <roopa@...ulusnetworks.com>
>> Signed-off-by: Nikolay Aleksandrov <nikolay@...ulusnetworks.com>
>
>Yes, per-vlan stats could be quite useful.
>Most cases of statistics in the kernel are always on, and some API's
>get them (and skip others).  Other than the additional memory overhead,
>why
>not make the statistics as always on.
>

The additional overhead can be quite a lot and it also affects performance, besides that currently users expect the same accumulated stats.

>Also, is there any chance of creating too much data in a netlink
>message if there are 4K-1 VLAN's?

No, that's okay because we expose the stats via the xstats API which
continues the dump on filling the current buffer.
We can export as much info as needed.

Cheers,
  Nik