[ovs-dev] 答复: Re: ?答复: Re: 答复: Re: [PATCH] ovn-controller: Support vxlan tunnel in ovn
Ben Pfaff
blp at ovn.org
Tue May 9 19:27:25 UTC 2017
The solution presented so far breaks OVN current and planned features.
If you have a solution that doesn't break OVN current or planned
features, let's talk about it. Until then, it is not interesting.
On Tue, May 09, 2017 at 09:29:07AM +0800, wang.qianyu at zte.com.cn wrote:
> Hi Ben and Mikey, thank you for your review and analysis.
>
> As we discribed below, vxlan is used very common, and the use case that we
> mentioned below is typical architecture of telecom operators' networks.
> So, we think it is very necessary to support vxlan between ovs and HW
> switch. If ovn does not support the use case we discribed before, we think
> the the
> ovn features may be imperfect. For this reason, we do the changes as this
> patch.
>
> Because vxlan tunnel can not carry enough information like genev to
> fulfill ovn current pipeline, so we do some assumptions. As Michkey and
> Ben said,
> these assumptions may not hold going forward, such as S_SWITCH_IN_L2_LKUP
> and more than one chassisredirect ports and so on.
>
> We think these incompatibles are not impossibly hard problems. If we have
> the consensus of the necessity to support vxlan, we think we could
> together
> to talk over a blueprint that less influence of current planning features
> and more effective to solve the problem we mentioned.
>
> Waiting for your suggestions,Thanks
>
>
>
>
>
>
> Mickey Spiegel <mickeys.dev at gmail.com>
> 发件人： ovs-dev-bounces at openvswitch.org
> 2017/05/08 04:58
>
> 收件人： xu.rong at zte.com.cn,
> 抄送： ovs dev <dev at openvswitch.org>,
> ovs-dev-bounces at openvswitch.org
> 主题： Re: [ovs-dev] 答复: Re: 答复: Re: [PATCH]
> ovn-controller: Support vxlan tunnel in ovn
>
>
> 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
> >
> _______________________________________________
> dev mailing list
> dev at openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>
>
More information about the dev
mailing list