[ovs-dev] [PATCH] sflow: Expose ethernet and vlan stats via sFlow

Neil McKee neil.mckee at inmon.com
Wed Nov 16 15:40:42 UTC 2016


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 <
robertx.wojciechowicz at intel.com> 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
>
>


More information about the dev mailing list