On Mon, Feb 26, 2018 at 11:47:08AM +0100, Jakub Sitnicki wrote: > On Fri, Feb 23, 2018 at 09:05 PM GMT, Ben Pfaff wrote: > > On Thu, Feb 22, 2018 at 10:54:05PM +0100, Jakub Sitnicki wrote: > >> Use the logical switch/router UUID as hash input, instead of the UUID of > >> the Datapath_Binding row, when calculating the hash value for lflows in > >> the SBDB. > >> > >> Otherwise the hash value will never match the one computed from NBDB > >> contents, which will force ovn-northd to constantly drop and attempt to > >> re-insert all the lflows. > > > > Thanks a lot for analyzing the problem and fixing it. > > > > There are basically two options here: use Datapath_Binding UUID > > consistently or use Logical_Switch/Logical_Router UUID consistently. > > This patch takes the latter approach. I'd prefer to take the former > > approach because it is less dependent on the structure of the northbound > > database (which seems desirable for something that is in the southbound > > database) and because it doesn't rely on the external-ids being correct. > > > > I sent a commit that takes the Datapath_Binding UUID approach: > > https://patchwork.ozlabs.org/patch/877306/ > > > > What do you think? > > In general - works for me. I'm wondering about a couple of things: > > 1) build_datapaths() -> join_datapaths() detects and removes duplicated > datapath bindings, AFAIU. I'm not sure how we can end up with > duplicated bindings but if it happens, can it lead to removal and > re-insertion of logical flows for a datapath?
I guess it would, if there were duplicate datpath bindings. It's ovn-northd that actually creates the datapath bindings, though, so we would want to fix the problem in ovn-northd in that case. > 2) If I wanted to precalculate an lflow hash and cache it in a synthetic > column in NB DB, ACLs being the potential candidate for that, then it > won't be possible with this approach. That said, I don't know ATM if > this would give a significant gain. If this turns out to be important to performance, I'm more than willing to reconsider the approach. For now, I applied my patch to master. Thanks a lot! _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
