[ovs-dev] [PATCH v2] Simplify kernel sFlow implementation

Jesse Gross jesse at nicira.com
Sat Aug 20 03:52:37 UTC 2011


On Sat, Aug 20, 2011 at 2:36 AM, Neil McKee <neil.mckee at inmon.com> wrote:
>
> On Aug 18, 2011, at 6:55 PM, Jesse Gross wrote:
>
> * Atomic operations are quite slow, which means that enabling sFlow results
> in a major performance hit.
>
> I was alarmed to read this.  What is the hit?  (I trust your test had the
> sampling-probability set so that it only take a handful of samples per
> second?).
> Looking at actions.c: sflow_sample(),  is it really just the
> "atomic_inc(&p->sflow_pool);" line that does the damage?

Yes, that's what I was referring to.  If you have multiple CPUs which
are processing different flows (but on the same port), then they're
going to fight over the cacheline that contains sflow_pool.  Since
this code is generally run on multi-core machines, it's an important
use case for us.  Depending on how your other project is expected to
be used, it may or may not be important there.

The only real way to fix this is to have per-CPU counters and then sum
them when you need to read the value, which should be significantly
less common than incrementing it for each packet.  We already do this
for the port counters, which this is nearly the same as sflow_pool.
That's why I was saying that it would be win to build on top of common
infrastructure as it has already been optimized.



More information about the dev mailing list