[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