On 6/9/25 7:35 PM, Mark Michelson via dev wrote: > The ovn_datapaths structure maintains an array of datapaths, allowing > for bitmaps to be used to indicate the relevant datapaths associated > with an entity, such as a logical flow. > > Logical flow syncing is attempting to rid itself of dependencies on > ovn_datapaths, but the logical flow creation hinges on the datapath > indices. > > This commit addresses the issue by introducing a type-agnostic > ovn_datapath_binding_hashvec structure that can be used to store > southbound Datapath_Bindings in both a hashmap and an array. This allows > for us to correlate a southbound Datapath_Binding with a specific index > into its corresponding vector. The ovn_datapaths array is created based > on this vector, meaning that an ovn_datapath's index corresponds to the > same southbound Datapath_Binding's ovn_datapath_binding index. > > In order to maintain consistency of indices, this commit also changes > synced datapath bindings to be a vector instead of a list, and sorts the > vector with each run. This ensures that synced datapaths will contain > the same indices as long as new datapaths are not added or removed from > the database. If datapaths are added or removed, then northd has to > recompute, meaning that the ovn_datapaths will recreate their arrays and > indices.
Hmm. I haven't read the code, but this sounds scary. IIUC, we'll trigger a full recompute every time new datapath is added or removed. This may cause significant issues for high-scale OpenStack setups. I've seen OpenStack setups used for CI where networks are created automatically per CI job having a few VMs inside. This doesn't cause any problems today, but it sounds like northd will become a bottleneck and will be stuck constantly recomputing all the logical flows with this change. Or am I missing something? Best regards, Ilya Maximets. _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
