[ovs-dev] 答复: Re: 答复: Re: [PATCH] ovn-controller: Support vxlan tunnel in ovn

Mickey Spiegel mickeys.dev at gmail.com
Sun May 7 20:58:44 UTC 2017


There are some assumptions that you are making which need to be called out.
These assumptions may not hold going forward. In fact I refer to two
different patches below that are currently under review, that break your
assumptions.

On Fri, May 5, 2017 at 7:18 PM, <xu.rong at zte.com.cn> wrote:

> Hi,Russell
>
> We think vxlan is the most commonly used tunnel encapsulation in the
> overlay network openstack,ovn should better consider it.
>
> As my workmate wang qianyu said,we would consider computer node connect
> with existing hardware switches which associates with SR-IOV as VTEP.
>
> After discussion, we feel that as long as the following changes for vxlan
> tunnel in the table0:
>
> 1.For local switch, move MFF_TUN_ID to MFF_LOG_DATAPATH, resubmit to
> OFTABLE_ETH_UCAST(table29)
>

It looks like you are overloading OFTABLE_ETH_UCAST that you define here
with S_SWITCH_IN_L2_LKUP in ovn/northd/ovn-northd.c. Hardcoding the value
to 29 in ovn/controller/lflow.h is not the way to do this. This pipeline
stage does move back as new features are added. In fact it is now table 31
due to the recent addition of 2 tables for DNS lookup.


> //---In table29, we can find out dst port based on dst mac
>

You are assuming that outport determination is only based on
S_SWITCH_IN_L2_LKUP with no impact from any other ingress pipeline stages.
This may not always be true, which I think is the point of Ben's complaint.
For example the SFC patch that is currently under review (
http://patchwork.ozlabs.org/patch/754427/) may set outport and then do
"output" in the ingress pipeline, in a pipeline stage other than
S_SWITCH_IN_L2_LKUP.

The alternative is to go through the entire ingress pipeline, but here you
have a problem since you do not know the inport. The current VTEP-centric
VXLAN code assumes that there is only one port binding per datapath from
the VTEP chassis. For the general case that you are trying to address, this
assumption does not hold, so you cannot properly determine the inport. The
inport may affect the ultimate decision on outport. This is certainly the
case for the SFC patch currently under review.

You are also assuming that inport does not affect anything in the egress
pipeline. This seems to be true at the moment, but this might not always be
true as features are added.

The existing VTEP functionality does not rely on the assumptions that you
made, but since you changed the logic to determine inport in case of VXLAN,
you are changing existing functionality.


> 2.For local chassisredirect port, move MFF_TUN_ID to MFF_LOG_DATAPATH, set
> port tunnel_key to MFF_LOG_OUTPORT and then resubmit to
> OFTABLE_LOCAL_OUTPUT.
> //---In table 33, we can find out dst local sw and sw patch port based on
> the local chassisredirect port,and then follow the exsiting flows.
>

At the moment, the only case where a tunnel is used for a datapath
representing a logical router is when the outport is a chassisredirect
port. Your code assumes that will always be the case. If we do what you are
suggesting, then that becomes a restriction for all logical router features
going forward.

This code also assumes that there can only be one chassisredirect port per
datapath per chassis. There is a patch that has not yet been reviewed (
http://patchwork.ozlabs.org/patch/732815/) that proposes multiple
distributed gateway ports (and correspondingly chassisredirect ports) on
one datapath. I am not sure what the use case is, but if that feature were
added and more than one distributed gateway port on one datapath specified
the same redirect-chassis, it would break this code.

This version of the code is better than the original version, which was
based on a hack that used table 29 on a datapath for a logical router
(!!!), adding contrived flows that matched VXLAN tunnel bit, metadata ==
datapath->tunnel_key, and MAC address from the SB MAC_Binding table in
order to set the outport to a chassisredirect port, based on the assumption
that tunnels are only used for logical routers when the outport is a
chassisredirect port.

Mickey



> Next step, we will consider how ovn-controller-hw manages SR-IOV as well.
>
> Waiting for your suggestions,Thanks.
>
> ---
>  ovn/controller/lflow.h    |  1 +
>  ovn/controller/physical.c | 17 +++++++++++++----
>  2 files changed, 14 insertions(+), 4 deletions(-)
>
> diff --git a/ovn/controller/lflow.h b/ovn/controller/lflow.h
> index 4f284a0..418f59e 100644
> --- a/ovn/controller/lflow.h
> +++ b/ovn/controller/lflow.h
> @@ -50,6 +50,7 @@ struct uuid;
>   * you make any changes. */
>  #define OFTABLE_PHY_TO_LOG            0
>  #define OFTABLE_LOG_INGRESS_PIPELINE 16 /* First of LOG_PIPELINE_LEN
> tables. */
> +#define OFTABLE_ETH_UCAST            29
>  #define OFTABLE_REMOTE_OUTPUT        32
>  #define OFTABLE_LOCAL_OUTPUT         33
>  #define OFTABLE_CHECK_LOOPBACK       34
> diff --git a/ovn/controller/physical.c b/ovn/controller/physical.c
> index 0f1aa63..d34140f 100644
> --- a/ovn/controller/physical.c
> +++ b/ovn/controller/physical.c
> @@ -963,9 +963,9 @@ physical_run(struct controller_ctx *ctx, enum
> mf_field_id mff_ovn_geneve,
>
>          SBREC_PORT_BINDING_FOR_EACH (binding, ctx->ovnsb_idl) {
>              struct match match = MATCH_CATCHALL_INITIALIZER;
> -
> +            /* here need to optimize to do only once for every datapath
> */
>              if (!binding->chassis ||
> -                strcmp(tun->chassis_id, binding->chassis->name)) {
> +                binding->chassis != chassis) {
>                  continue;
>              }
>
> @@ -974,11 +974,20 @@ physical_run(struct controller_ctx *ctx, enum
> mf_field_id mff_ovn_geneve,
>
>              ofpbuf_clear(&ofpacts);
>              put_move(MFF_TUN_ID, 0,  MFF_LOG_DATAPATH, 0, 24, &ofpacts);
> -            put_load(binding->tunnel_key, MFF_LOG_INPORT, 0, 15,
> &ofpacts);
>              /* For packets received from a vxlan tunnel, set a flag to
> that
>               * effect. */
>              put_load(1, MFF_LOG_FLAGS, MLF_RCV_FROM_VXLAN_BIT, 1,
> &ofpacts);
> -            put_resubmit(OFTABLE_LOG_INGRESS_PIPELINE, &ofpacts);
> +            if (!strcmp(binding->type, "chassisredirect"))
> +            {
> +                put_load(binding->tunnel_key, MFF_LOG_OUTPORT, 0, 16,
> &ofpacts);
> +                put_resubmit(OFTABLE_LOCAL_OUTPUT, &ofpacts);
> +            }
> +            else
> +            {
> +                put_resubmit(OFTABLE_ETH_UCAST, &ofpacts);
> +            }
>
>              ofctrl_add_flow(flow_table, OFTABLE_PHY_TO_LOG, 100, 0,
> &match,
>                              &ofpacts);
> --
>
>
>
>
>
> 发件人:         王前宇10110202/user/zte_ltd
> 收件人:         Russell Bryant <russell at ovn.org>,
> 抄送:   Ben Pfaff <blp at ovn.org>, ovs dev <dev at openvswitch.org>,
> ovs-dev-bounces at openvswitch.org, xurong00037997 <xu.rong at zte.com.cn>
> 日期:   2017/05/05 09:30
> 主题:   答复: Re: [ovs-dev] 答复: Re: [PATCH] ovn-controller: Support
> vxlan tunnel in ovn
>
>
> We want to use ovn in the scenary that ovs-computer node and sriov
> computer node all managed by openstack.
> However, in our analysis that ovn-controller-vtep could only be used to
> forwards traffic between  networks managed by openstack and physical
> network openstack not managed.
> Do we misunderstand of the use of ovn-controller-vtep?
> Thanks,
>
>
>
>
>
>
> Russell Bryant <russell at ovn.org>
> 2017/05/05 02:12
>
>         收件人:        Ben Pfaff <blp at ovn.org>,
>         抄送:  wang.qianyu at zte.com.cn, ovs dev <dev at openvswitch.org>,
> xurong00037997 <xu.rong at zte.com.cn>, ovs-dev-bounces at openvswitch.org
>         主题:  Re: [ovs-dev] 答复: Re: [PATCH] ovn-controller: Support
> vxlan tunnel in ovn
>
>
> ovn-controller-vtep is discussed in the "Life Cycle of a VTEP Gateway"
> section in ovn-architecture(7).
>
> http://openvswitch.org/support/dist-docs/ovn-architecture.7.html
>
> On Thu, May 4, 2017 at 12:41 PM, Ben Pfaff <blp at ovn.org> wrote:
> > OVS already has a VXLAN hardware switch story via ovn-controller-vtep.
> >
> > On Thu, May 04, 2017 at 07:51:01PM +0800, wang.qianyu at zte.com.cn wrote:
> >> In most telecom carriers network architecture, they may demand hardware
> >> switches for performance consideration.
> >> The network architecture is as follow:
> >>
> >>         ---------------
> >>         |  ovn-sb     |
> >>         ---------------
> >>          |            |
> >>          |            |
> >> --------------     -----------------
> >> |ovn-controller|  |ovn-controller-hw|
> >> ---------------    ------------------
> >>    |   |                     |
> >> ----------------      ------------------
> >> |              |      |  hardware switch |
> >> |              |      -------------------
> >> |    ovs       |             |
> >> |computer node |      |----------------|
> >> |              |      |   sriov        |
> >> |              |      |                |
> >> |--------------|      | computer node  |
> >>                       ------------------
> >> Now, most hardware switches only support vxlan encapsulation. So we
> think
> >> if ovn could support vxlan
> >> encapsulation will be better. this is the reason that why we do the
> modify
> >> as the patch.
> >> Now, ovn used for the scenary of hardware-switches link to sriov
> >> network-card is very difficult,
> >> and we want do more works for ovn-controller-hw to support hardware
> >> switch.
> >> Do have some good idea about this scenary?
> >> Thanks
> >>
> >>
> >>
> >>
> >>
> >> Russell Bryant <russell at ovn.org>
> >> 发件人: ovs-dev-bounces at openvswitch.org
> >> 2017/05/04 10:57
> >>
> >>         收件人:        xurong00037997 <xu.rong at zte.com.cn>,
> >>         抄送:  ovs dev <dev at openvswitch.org>
> >>         主题:  Re: [ovs-dev] [PATCH] ovn-controller: Support vxlan
> tunnel
> >> in ovn
> >>
> >>
> >> On Wed, May 3, 2017 at 10:17 PM, xurong00037997 <xu.rong at zte.com.cn>
> >> wrote:
> >> > Because vxlan envelope have no enough fields to carry pipeline
> >> information
> >> > between ovs, so current ovn version do not support vxlan tunnel.
> >> > However, may only vxlan tunnel can be used in some special scenario.
> so
> >> we
> >> > think it is necessary to implement the function of vxlan. For this
> >> > purpose, we do the modifications as follow:
> >> >     1. packets received from vxlan jump to table 29 for outport
> finding
> >> >     2. add mac-binding information to table 29
> >> > ---
> >> >  ovn/controller/lflow.c    | 51
> >> +++++++++++++++++++++++++++++++++++++++++++++++
> >> >  ovn/controller/lflow.h    |  1 +
> >> >  ovn/controller/physical.c |  9 +++++----
> >> >  3 files changed, 57 insertions(+), 4 deletions(-)
> >> >  mode change 100644 => 100755 ovn/controller/lflow.c
> >> >  mode change 100644 => 100755 ovn/controller/lflow.h
> >> >  mode change 100644 => 100755 ovn/controller/physical.c
> >> >
> >>
> >> I'm interested in how you concluded that VXLAN support was needed.
> >> I've been looking at this question pretty extensively and have not
> >> been able to find any good justification for why VXLAN support should
> >> be added to OVN.
> >>
> >> Can you expand on what special scenarios you have in mind?
> >>
> >> Thanks,
> >>
> >> --
> >> Russell Bryant
> >> _______________________________________________
> >> dev mailing list
> >> dev at openvswitch.org
> >> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
> >>
> >>
> >>
> >> _______________________________________________
> >> dev mailing list
> >> dev at openvswitch.org
> >> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
> > _______________________________________________
> > dev mailing list
> > dev at openvswitch.org
> > https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>
>
>
> --
> Russell Bryant
>
>
>
> _______________________________________________
> dev mailing list
> dev at openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>


More information about the dev mailing list