[ovs-discuss] OpenStack profiling with networking-ovn - port creation is slow

[Lucas Alvares Gomes]

Hi all,

We currently have a problem with Address_Set in networking-ovn (and
potentially other technologies using OVN as backend) which *maybe*
could be fixed together with this idea of a new "port set" (a.k.a
macro set).

The problem is bit tricky but it shows as a race condition between
creating and deleting ports in Neutron. That is, deleting a port in
Neutron will result in the IP address of that port to be removed from
an address set, but at the same time, if another request to create a
port overtaking the same IP address of the port being deleted is
issued, depending on which order things are committed it could result
in the address set to not contain the new port IP address.

Here's a bug ticket describing the problem in more detail:
https://bugs.launchpad.net/networking-ovn/+bug/1611852

The reason why it happens is because we don't have a direct
relationship between the addresses in an address set and the ports
that those addresses belongs to. So, if we create this relation we
might end up having both ports and addresses present in the
Address_Set table which then can be used to fix both of our problems.

Here's some ideas:

# 1. A new map column

We could add a "map" type column called "ports" in the Address_Set
table that would look like this in the database:

"Address_Set": {
  "ports": {"port-1-name": {"ipv4_addresses": [...],
                                     "ipv6_addresses": [...}}
  ...
}

# 2: Add a new way to populate the address set:

Instead of directly populating the addresses in an address set where
the port relationship isn't clear, we could add two list of ports
references (one for each IP version) and have the addresses
automatically populated.

For example:

"Address_Set": {
  "columns": {
    "ipv4_ports": {"type": {"key": {"type": "uuid",
                                    "refTable": "Logical_Switch_Port",
                                    "refType": "weak"},
                            "min": 0,
                            "max": "unlimited"}}
    "ipv6_ports": {"type": {"key": {"type": "uuid",
                                    "refTable": "Logical_Switch_Port",
                                    "refType": "weak"},
                            "min": 0,
                            "max": "unlimited"}}
     ...
}

The problem here is that we would pull all addresses from those ports
into the address set.

The good part is that since it's a weak reference, deleting a port
would automatically remove it from the address set.

# 3: Allow duplicated addresses in the list

If the above options sounds too complicated, maybe we could keep the
idea of this email of creating a "Macro_Set" that could be used for
both ports and addresses types [0]. But, when the type is set to
"address" we could allow duplicated items in the list of elements that
way we won't have a problem if one transaction removes one duplicated
element in the list.

[0] https://mail.openvswitch.org/pipermail/ovs-dev/2016-August/077118.html

Any more ideas?

Cheers,
Lucas

On Thu, Feb 15, 2018 at 12:04 AM, Ben Pfaff <blp at ovn.org> wrote:
> On Thu, Feb 15, 2018 at 12:36:35AM +0100, Daniel Alvarez Sanchez wrote:
>> If we would have the Port_Set we could simply write the match part as
>> "outport == $security_group1 && ip4 && ip4.src == 0.0.0.0/0 && tcp &&
>> tcp.dst == 22"
>> and reduce the number of ACLs to 1 per security group rule instead of 1 per
>> security
>> group rule per port as it is right now. As you can see, we're referencing
>> the relevant security group rule in the CMS through the
>> neutron:security_group_rule_id
>> key in the external_ids column so we would reduce all ACLs which correspond
>> to
>> the same SG rule to just 1.
>
> OK, that matches up with what Han says.  Han is going to rebase the
> "port set" patches, so I think we'll have a solution for this soon after
> that.
> _______________________________________________
> discuss mailing list
> discuss at openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss