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

2017-05-07 Thread Mickey Spiegel 
OOPBACK   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();
>  put_move(MFF_TUN_ID, 0,  MFF_LOG_DATAPATH, 0, 24, );
> -put_load(binding->tunnel_key, MFF_LOG_INPORT, 0, 15,
> );
>  /* 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,
> );
> -put_resubmit(OFTABLE_LOG_INGRESS_PIPELINE, );
> +if (!strcmp(binding->type, "chassisredirect"))
> +{
> +put_load(binding->tunnel_key, MFF_LOG_OUTPORT, 0, 16,
> );
> +put_resubmit(OFTABLE_LOCAL_OUTPUT, );
> +}
> +else
> +{
> +put_resubmit(OFTABLE_ETH_UCAST, );
> +}
>
>  ofctrl_add_flow(flow_table, OFTABLE_PHY_TO_LOG, 100, 0,
> ,
>                  );
> --
>
>
>
>
>
> 发件人: 王前宇10110202/user/zte_ltd
> 收件人: Russell Bryant <russ...@ovn.org>,
> 抄送:   Ben Pfaff <b...@ovn.org>, ovs dev <d...@openvswitch.org>,
> ovs-dev-boun...@openvswitch.org, xurong00037997 <xu.r...@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 <russ...@ovn.org>
> 2017/05/05 02:12
>
> 收件人：Ben Pfaff <b...@ovn.org>,
> 抄送：  wang.qia...@zte.com.cn, ovs dev <d...@openvswitch.org>,
> xurong00037997 <xu.r...@zte.com.cn>, ovs-dev-boun...@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 <b...@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.qia...@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,
>

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

2017-05-07 Thread Ben Pfaff 
On Sat, May 06, 2017 at 10:18:58AM +0800, xu.r...@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)
> //---In table29, we can find out dst port based on dst mac

This breaks the general-purpose nature of OVN, which isn't based on MAC
addresses.  With this change, an "output" to a given port won't
necessarily output to that port.  It will also break output to OVN
multicast groups.

I oppose this change.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

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

2017-05-06 Thread xu . rong 
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)
//---In table29, we can find out dst port based on dst mac

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.

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_LOG0
 #define OFTABLE_LOG_INGRESS_PIPELINE 16 /* First of LOG_PIPELINE_LEN 
tables. */
+#define OFTABLE_ETH_UCAST29
 #define OFTABLE_REMOTE_OUTPUT32
 #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();
 put_move(MFF_TUN_ID, 0,  MFF_LOG_DATAPATH, 0, 24, );
-put_load(binding->tunnel_key, MFF_LOG_INPORT, 0, 15, 
);
 /* 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, 
);
-put_resubmit(OFTABLE_LOG_INGRESS_PIPELINE, );
+if (!strcmp(binding->type, "chassisredirect"))
+{
+put_load(binding->tunnel_key, MFF_LOG_OUTPORT, 0, 16, 
);
+put_resubmit(OFTABLE_LOCAL_OUTPUT, );
+}
+else
+{
+put_resubmit(OFTABLE_ETH_UCAST, );
+}

 ofctrl_add_flow(flow_table, OFTABLE_PHY_TO_LOG, 100, 0, 
,
 );
--





发件人: 王前宇10110202/user/zte_ltd
收件人: Russell Bryant <russ...@ovn.org>, 
抄送:   Ben Pfaff <b...@ovn.org>, ovs dev <d...@openvswitch.org>, 
ovs-dev-boun...@openvswitch.org, xurong00037997 <xu.r...@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 <russ...@ovn.org>
2017/05/05 02:12
 
收件人：Ben Pfaff <b...@ovn.org>, 
抄送：  wang.qia...@zte.com.cn, ovs dev <d...@openvswitch.org>, 
xurong00037997 <xu.r...@zte.com.cn>, ovs-dev-boun...@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 <b...@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.qia...@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 |
>>

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

2017-05-04 Thread wang . qianyu 
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 <russ...@ovn.org>
2017/05/05 02:12
 
收件人：Ben Pfaff <b...@ovn.org>, 
抄送：  wang.qia...@zte.com.cn, ovs dev <d...@openvswitch.org>, 
xurong00037997 <xu.r...@zte.com.cn>, ovs-dev-boun...@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 <b...@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.qia...@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 <russ...@ovn.org>
>> 发件人： ovs-dev-boun...@openvswitch.org
>> 2017/05/04 10:57
>>
>> 收件人：xurong00037997 <xu.r...@zte.com.cn>,
>> 抄送：  ovs dev <d...@openvswitch.org>
>> 主题：  Re: [ovs-dev] [PATCH] ovn-controller: Support vxlan 
tunnel
>> in ovn
>>
>>
>> On Wed, May 3, 2017 at 10:17 PM, xurong00037997 <xu.r...@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
>> d...@openvswitch.org
>> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>>
>>
>>
>> ___
>> dev mailing list
>> d...@openvswitch.org
>> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev



-- 
Russell Bryant



___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev