On October 12, 2018 6:39:32 PM GMT+03:00, Stephen Hemminger <stephen@xxxxxxxxxxxxxxxxxx> wrote: >On Fri, 12 Oct 2018 13:41:16 +0300 >Nikolay Aleksandrov <nikolay@xxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxxxxx >> CC: Roopa Prabhu <roopa@xxxxxxxxxxxxxxxxxxx> >> Signed-off-by: Nikolay Aleksandrov <nikolay@xxxxxxxxxxxxxxxxxxx> > >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
