Hui Kang/Watson/IBM wrote on 06/27/2016 02:51:54 PM: > From: Hui Kang/Watson/IBM > To: Ryan Moats/Omaha/IBM@IBMUS > Cc: Ben Pfaff <b...@ovn.org>, dev@openvswitch.org > Date: 06/27/2016 02:51 PM > Subject: Re: [ovs-dev] [OVN] Potential scalability bug in ovn-northd > on creating and binding large number of lports > > 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 bracketsabove, 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?
I mean update whatever information comes from the SB port, because it may have just changed - as I'm not looking at the code, I can't quote chapter and verse. > > > > - 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. No, there is a bunch of code that goes through ports known via the nb db, I'm talking about keeping that code and modifying based on the below. IIRC, that is pretty much the code that is already there. Ryan > > - Hui > > > > > - if the entry is found in the both list, update the nb datacontained > > > > 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
