[ovs-dev] [PATCH ovn] Don't suppress localport traffic directed to external port

Dumitru Ceara dceara at redhat.com
Wed Jul 7 08:16:41 UTC 2021


On 7/7/21 5:20 AM, Ihar Hrachyshka wrote:
> Recently, we stopped leaking localport traffic through localnet ports
> into fabric to avoid unnecessary flipping between chassis hosting the
> same localport.
> 
> Despite the type name, in some scenarios localports are supposed to talk
> outside the hosting chassis. Specifically, in OpenStack [1] metadata
> service for SR-IOV ports is implemented as a localport hosted on another
> chassis that is exposed to the chassis owning the SR-IOV port through an
> "external" port. In this case, "leaking" localport traffic into fabric
> is desirable.
> 
> This patch inserts a higher priority flow per external port on the
> same datapath that avoids dropping localport traffic.
> 
> Fixes: 96959e56d634 ("physical: do not forward traffic from localport to
> a localnet one")
> 
> [1] https://docs.openstack.org/neutron/latest/admin/ovn/sriov.html
> 
> Signed-off-by: Ihar Hrachyshka <ihrachys at redhat.com>
> ---

Hi Ihar,

Thanks for working on this!

I just had a glance at the change so this is not a full review.

>  controller/physical.c | 48 ++++++++++++++++++++++++++++++++++++++
>  tests/ovn.at          | 54 +++++++++++++++++++++++++++++++++++++++++++
>  2 files changed, 102 insertions(+)
> 
> diff --git a/controller/physical.c b/controller/physical.c
> index 17ca5afbb..c2de30941 100644
> --- a/controller/physical.c
> +++ b/controller/physical.c
> @@ -920,6 +920,7 @@ get_binding_peer(struct ovsdb_idl_index *sbrec_port_binding_by_name,
>  
>  static void
>  consider_port_binding(struct ovsdb_idl_index *sbrec_port_binding_by_name,
> +                      const struct sbrec_port_binding_table *pb_table,
>                        enum mf_field_id mff_ovn_geneve,
>                        const struct simap *ct_zones,
>                        const struct sset *active_tunnels,
> @@ -1281,6 +1282,49 @@ consider_port_binding(struct ovsdb_idl_index *sbrec_port_binding_by_name,
>              ofctrl_add_flow(flow_table, OFTABLE_CHECK_LOOPBACK, 160,
>                              binding->header_.uuid.parts[0], &match,
>                              ofpacts_p, &binding->header_.uuid);
> +
> +            /* Localport traffic directed to external is *not* local. */
> +            const struct sbrec_port_binding *peer;
> +            SBREC_PORT_BINDING_TABLE_FOR_EACH (peer, pb_table) {
> +                if (strcmp(peer->type, "external")) {
> +                    continue;
> +                }
> +                if (peer->datapath->tunnel_key != dp_key) {
> +                    continue;
> +                }
> +                if (strcmp(peer->chassis->name, chassis->name)) {
> +                    continue;
> +                }

Won't this create a scalability issue?  If I'm reading this correctly,
every time consider_port_binding() is called for a localnet port we'll
be walking all port_bindings in the SB DB table (there can be a lot of
them in scaled scenarios) and skip most of them because they're not of
type external or they're not owned by the local chassis or they're on a
different datapath.

One option would be to use an IDL index instead (although that's still
log(n) complexity for every localnet port, I think).  Another option
would be to precompute the set of external ports for each datapath so we
don't have to walk all ports every time.

> +
> +                ofpbuf_clear(ofpacts_p);
> +                for (int i = 0; i < MFF_N_LOG_REGS; i++) {
> +                    put_load(0, MFF_REG0 + i, 0, 32, ofpacts_p);
> +                }
> +                put_resubmit(OFTABLE_LOG_EGRESS_PIPELINE, ofpacts_p);
> +
> +                for (int i = 0; i < peer->n_mac; i++) {
> +                    char *err_str;
> +                    struct eth_addr peer_mac;
> +                    if ((err_str = str_to_mac(peer->mac[i], &peer_mac))) {
> +                        VLOG_WARN("Parsing MAC failed for external port: %s, "
> +                                "with error: %s", peer->logical_port, err_str);

This probably needs rate limiting.

Regards,
Dumitru



More information about the dev mailing list