[ovs-dev] [PATCH 4/4] ovn-controller: Use separate thread for packet-in processing.

[Ben Pfaff]

On Thu, Jun 08, 2017 at 04:21:17PM -0700, Han Zhou wrote:
> On Thu, Jun 8, 2017 at 4:14 PM, Ben Pfaff <blp at ovn.org> wrote:
> >
> > On Tue, Jun 06, 2017 at 05:24:19PM -0700, Han Zhou wrote:
> > > On Tue, Jun 6, 2017 at 3:56 PM, Ben Pfaff <blp at ovn.org> wrote:
> > > >
> > > > On Thu, May 25, 2017 at 05:26:47PM -0700, Han Zhou wrote:
> > > > > This patch introduces multi-threading for ovn-controller and use
> > > > > dedicated thread for packet-in processing as a start. It decouples
> > > > > packet-in processing and ovs flow computing, so that packet-in
> inputs
> > > > > won't trigger flow recomputing, and flow computing won't block
> > > > > packet-in processing. In large scale environment this largely
> reduces
> > > > > CPU cost and improves performance.
> > > >
> > > > Won't this double the load on the southbound database server, as well
> as
> > > > the bandwidth to and from it?  We already have a bottleneck there.
> > >
> > > Ben, yes this is the trade-off. Here are the considerations:
> > >
> > > 1. The bottle-neck in ovn-controller is easier to hit (you don't even
> need
> > > many number of HVs to hit it)
> > > 2. The bottle-neck of southbound DB do exist when number of HV increases
> > > but since you are already working on the ovsdb clustering I suppose it
> will
> > > be resolved.
> > >
> > > However I agree that this is not ideal. Alternatively we can spin-up a
> > > dedicated thread for SB IDL processing and other "worker" thread just
> read
> > > the data with proper locking. This will be more complicated but should
> be
> > > doable, what do you think?
> >
> > I spent a little time thinking about this.  I think that the approach
> > that you're proposing is probably practical.  Do you want to try to
> > experiment with it and see whether it's reasonably possible?
> 
> It basically needs to separate reads and writes for SB IDL from the
> xxx_run() functions, which may be tricky. But if there is no other way
> around I'll go down this path.

I thought you were proposing some very coarse-grained locking.  Maybe
you should describe what you mean in a little more detail.