[ovs-dev] [OVN] Potential scalability bug in ovn-northd on creating and binding large number of lports

[Hui Kang]

Ryan Moats/Omaha/IBM wrote on 06/25/2016 09:07:39 PM:

> From: Ryan Moats/Omaha/IBM
> To: Hui Kang/Watson/IBM at IBMUS
> Cc: Ben Pfaff <blp at ovn.org>, dev at 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