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? 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. Thanks, Jakub _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
