If there is only one VLAN then the numbers are redundant - already exported in the struct if_counters.
The vlan_counters structure was never intended to be exported by an interface. It was designed for the (rarely used) vlan datasource -- that's why the counters in it are not directional. So I don't think you would be losing anything by leaving it out. Neil ------ Neil McKee InMon Corp. http://www.inmon.com On Wed, Nov 16, 2016 at 6:13 AM, Robert Wojciechowicz < [email protected]> wrote: > On Tue, Nov 15, 2016 at 11:13:10PM -0700, Neil McKee wrote: > > Hi Robert, > > > > (3) adding vlan counters for every vlan that an interface belongs to -- I > > not sure about this one. What if an interface is on a whole set of > vlans? > > This vlan counters structure has hardly ever been used. Certainly not > in > > this per-interface, per-vlan way. I don't think any sFlow collectors > would > > know what to make of it. And since the packet-samples include vlan info > > it is already possible to derive vlan traffic estimates by interface (and > > by src/dst MAC, IP etc.) from them. > > > > So I think I'm voting for (1), maybe (2) but not (3). What do you > think? > > Actually my idea was to report via sFlow only statistics related to VLAN > access ports. This condition: > > if (vlan_id > 0 && vlan_id != UINT32_MAX) { > > checks whether port has been configured as access port like this: > > ovs-vsctl set port dpdk0 tag=10 > > Access port can see only one VLAN, so monitoring it might be valuable > and additional 28 bytes is not a big performance impact I guess. > I agree that exposing VLAN counters for trunk ports might be redundant, > because it can be seen in samples. > > Br, > Robert > > _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
