On 12 July 2014 00:55, Thomas Graf <tg...@noironetworks.com> wrote: > On 07/11/14 at 11:29pm, Joe Stringer wrote: > > I'm skeptical of taking the ovs_lock(). The current patch performs this > > key/mask cache construction inside ovs_lock() as part of the critical > > section for flow install. If we perform this during flow_dump, but extend > > the ovs_lock to the entire flow dump operation, that has the potential to > > make things worse due to the added contention. If I follow correctly, the > > mspin_lock() bottleneck after the current patch is applied is already > > measuring contention on the ovs_mutex when revalidators attempt to delete > > flows. That's with flow_dump as RCU. > > We would actually only hold the lock while constructing each > individual message but it is probably not worth it. A cmpxchg will > be expensive as well. It seems like your idea of fixing up the > original flow as provided by the user would be the most optimal > solution.
FWIW, I tried this out briefly. Using ovs_mutex to regulate cache construction made performance similar to master, we seemed to spend more time revalidating but also spent more time contending on the lock. I tried swapping out ovs_mutex for a new mutex that is only used during flow_dump for cache construction. This seemed to remove the contention, bringing the flow limit improvement of around 15% compared against master. Memcpy and memset are still quite expensive with this code. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
