[ovs-dev] [PATCH RFC v3 1/1] netdev-dpdk: Add support for DPDK 16.07

[Daniele Di Proietto]

2016-07-24 11:06 GMT-07:00 Ben Pfaff <blp at ovn.org>:

> On Sun, Jul 24, 2016 at 10:17:13AM -0400, Aaron Conole wrote:
> > Daniele Di Proietto <diproiettod at 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.
>

I think by using atomics and making sure that we follow the C11 memory
model, it should work on every architecture supported by the compiler.

I agree that using atomics is not always straightforward, but we had a
pretty good experience so far with RCU.  The approach I'm proposing uses
atomics in the same way they're used for pointers.

It'd be the same as using an RCU pointer to an malloc'd int (the vid
index), but I'd prefer avoiding the extra indirection in the fast path and
the extra allocation in the slow path.

Thanks,

Daniele