On Sun, Jul 24, 2016 at 10:17:13AM -0400, Aaron Conole wrote: > Daniele Di Proietto <diproiet...@ovn.org> writes: > > > Thanks for the patch. > > > > I have another concern with this. If we're still going to rely on RCU to > > protect the vhost device (and as pointed out by Ilya, I think we should) we > > need to use RCU-like semantics on the vid array index. I'm not sure a > > boolean flag is going to be enough. > > > > CCing Jarno: > > > > We have this int, which is an index into an array of vhost devices (the > > array is inside the DPDK library). We want to make sure that when > > ovsrcu_synchronize() returns nobody is using the old index anymore. > > > > Should we introduce an RCU type for indexing into arrays? I found some > > negative opinions here: > > > > https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/Documentation/RCU/arrayRCU.txt?id=refs/tags/next-20160722#n13 > > > > but I think using atomics should prevent the compiler from playing tricks > > with the index. > > Is there a reason to prefer atomics over something like a reference > counted array pointer (as described in the linked text)? Are you > afraid of the malloc/memcpy overhead in the worst case? I think > many times side effects of atomics can be difficult to debug, because > of the subtleties of various chip synchronization protocols. Maybe it's > okay if you are only going to support Intel chips, though. Just my > $0.02
We definitely don't support just Intel chips. (We're not etcd!) Thanks, Ben. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
