On Thu, Jun 8, 2017 at 4:14 PM, Ben Pfaff <[email protected]> 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 <[email protected]> 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. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
