Ryan Moats/Omaha/IBM wrote on 06/25/2016 09:07:39 PM:
> From: Ryan Moats/Omaha/IBM > To: Hui Kang/Watson/IBM@IBMUS > Cc: Ben Pfaff <b...@ovn.org>, dev@openvswitch.org > Date: 06/25/2016 09:07 PM > Subject: Re: [ovs-dev] [OVN] Potential scalability bug in ovn-northd > on creating and binding large number of lports > > > > > > > > I *think* if I were to consider persisting the sb_only, nb_only, and both > > > lists and follow the extra logic I've added in square brackets above, I'd > > > only have entries in the both list at the end of the calculationset, so I > > > should only need to persist the both table. > > > > What do you mean by "persisting"? A global linked list to store the elements > > of struct ovn_ports? > > That's exactly what I mean. I'm looking at trading memory for execution time. > > > > Further, I *think* if I were to then apply change tracking to the first > > > part of the process above, the logic changes to: > > > > Which step of the above pseudo-code should the following code be > > embedded into ? > > The following replaces the entire list above. The good thing about writing > this down is that I can come back to it later and realize where I goofed - > see below. > > > > > > > - For each tracked entry in the port bindings table > > > - if it is a deleted entry, remove from the both list (if there is still > > > a nb entry, we'll recreate it further on) > > > - if it is a new entry, add it to the sb_only list > > The above isn't quite right - since we create port binding entries ourself > in response to unmatched ports in the nb_only list, we need to check that > there isn't already a port in the both list. So the above changes to: > > - if it is a new entry, check for it in the both list > - if it is not there, then add it to the sb_only list > > > > - if it is a modified entry, find it in the both list and update the > > > sb information contained in the entry Do you mean updating the struct ovn_port in the both list? > > > - For each port known via the nb db: Should this be "For the port in each changed entry in nb db" due to the persisted both list? Thanks. - Hui > > > - if the entry is found in the both list, update the nb data contained > > > in the entry > > > - if the entry is not in the both list, but is in the sb_only list, > > > move the entry from the sb_list to the both list > > > - if the entry is not in either the both or the sb_only list, create > > > a new entry in the nb_only list > > > - For each entry in the both list, do modifications to align the port > > > binding with nb information. > > > - For each entry in the nb_only list, create port_binding information in > > > the sb db and move the entry from the nb_only to the both list > > > - For each entry in the sb_only list, remove from the port_binding table. > > > > > > Now, I'm pretty sure this will cut down the number of cycles, but before > > > I go off and code it [and potentially break something ala yesterday's > > > excitement], I'm looking for some verification of both my conclusion of > > > persisting just the both list and the modified logic incorporating the > > > persisted both list and port binding change tracking adjustments). Do > > > these make sense or have I missed something? > > Ryan _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev