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

Ryan Moats rmoats at us.ibm.com
Tue Jun 28 04:36:38 UTC 2016


Hui Kang/Watson/IBM wrote on 06/27/2016 02:51:54 PM:

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



More information about the dev mailing list