On Sat, Aug 20, 2011 at 2:36 AM, Neil McKee <neil.mc...@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. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
