from:"wang . qianyu"

[ovs-dev] [PATCH] ovn: reduce logical flow applied to ovn-controller

2017-09-21 Thread wang . qianyu

>From 80260a2950f10544e307d6f20cb1cfe8c9bb885f Mon Sep 17 00:00:00 2001
From: wang qianyu <wang.qia...@zte.com.cn>
Date: Thu, 21 Sep 2017 18:05:16 +0800
Subject: [PATCH] ovn: reduce logical flow applied to ovn-controller

Add a logical_port column in Logical_Flow table. If logical flow generated 
by
logical_switch_port, set the logical_port of Logical_Flow with value of 
port
name. In ovn-controller, do not do expr_parse for non-local Logical_Flow.
This can reduce the calculation and memory usage of ovn-controller.

Signed-off-by: wang qianyu <wang.qia...@zte.com.cn>
---
 ovn/controller/lflow.c  |  23 +++
 ovn/northd/ovn-northd.c | 165 
+---
 ovn/ovn-sb.ovsschema|   5 +-
 ovn/ovn-sb.xml  |   5 ++
 4 files changed, 130 insertions(+), 68 deletions(-)

diff --git a/ovn/controller/lflow.c b/ovn/controller/lflow.c
index 20a18c2..1798c60 100644
--- a/ovn/controller/lflow.c
+++ b/ovn/controller/lflow.c
@@ -137,6 +137,20 @@ is_gateway_router(const struct sbrec_datapath_binding 
*ldp,
 return ld ? ld->has_local_l3gateway : false;
 }
 
+static bool
+is_local_port(struct controller_ctx *ctx,
+  const char *logical_port_name,
+  const struct sbrec_chassis *chassis)
+{
+const struct sbrec_port_binding *binding_rec =lport_lookup_by_name(
+ctx->ovnsb_idl, logical_port_name);
+return binding_rec? (!strcmp(binding_rec->type, "patch")
+|| !strcmp(binding_rec->type, "localport")
+|| !strcmp(binding_rec->type, "vtep")
+|| !strcmp(binding_rec->type, "localnet")
+|| binding_rec->chassis == chassis) : false;
+}
+
 /* Adds the logical flows from the Logical_Flow table to flow tables. */
 static void
 add_logical_flows(struct controller_ctx *ctx,
@@ -168,6 +182,15 @@ add_logical_flows(struct controller_ctx *ctx,
 }
 
 SBREC_LOGICAL_FLOW_FOR_EACH (lflow, ctx->ovnsb_idl) {
+ if (lflow->logical_port
+&& lflow->logical_port[0]
+&& !is_local_port(ctx, lflow->logical_port, chassis)) {
+VLOG_INFO("flow: table=%"PRIu64", priority=%"PRIu64", %s, "
+"actions=%s not need to add in this chassis",
+lflow->table_id, lflow->priority,
+lflow->match, lflow->actions);
+continue;
+}
 consider_logical_flow(ctx, chassis_index,
   lflow, local_datapaths,
   group_table, chassis,
diff --git a/ovn/northd/ovn-northd.c b/ovn/northd/ovn-northd.c
index 2db2380..e879c43 100644
--- a/ovn/northd/ovn-northd.c
+++ b/ovn/northd/ovn-northd.c
@@ -2236,6 +2236,7 @@ struct ovn_lflow {
 char *match;
 char *actions;
 char *stage_hint;
+struct ovn_port *op;
 const char *where;
 };
 
@@ -2262,7 +2263,7 @@ static void
 ovn_lflow_init(struct ovn_lflow *lflow, struct ovn_datapath *od,
enum ovn_stage stage, uint16_t priority,
char *match, char *actions, char *stage_hint,
-   const char *where)
+   struct ovn_port *op, const char *where)
 {
 lflow->od = od;
 lflow->stage = stage;
@@ -2270,6 +2271,7 @@ ovn_lflow_init(struct ovn_lflow *lflow, struct 
ovn_datapath *od,
 lflow->match = match;
 lflow->actions = actions;
 lflow->stage_hint = stage_hint;
+lflow->op = op;
 lflow->where = where;
 }
 
@@ -2278,14 +2280,15 @@ static void
 ovn_lflow_add_at(struct hmap *lflow_map, struct ovn_datapath *od,
  enum ovn_stage stage, uint16_t priority,
  const char *match, const char *actions,
- const char *stage_hint, const char *where)
+ const char *stage_hint, struct ovn_port *op,
+ const char *where)
 {
 ovs_assert(ovn_stage_to_datapath_type(stage) == 
ovn_datapath_get_type(od));
 
 struct ovn_lflow *lflow = xmalloc(sizeof *lflow);
 ovn_lflow_init(lflow, od, stage, priority,
xstrdup(match), xstrdup(actions),
-   nullable_xstrdup(stage_hint), where);
+   nullable_xstrdup(stage_hint), op, where);
 hmap_insert(lflow_map, >hmap_node, ovn_lflow_hash(lflow));
 }
 
@@ -2293,11 +2296,17 @@ ovn_lflow_add_at(struct hmap *lflow_map, struct 
ovn_datapath *od,
 #define ovn_lflow_add_with_hint(LFLOW_MAP, OD, STAGE, PRIORITY, MATCH, \
 ACTIONS, STAGE_HINT) \
 ovn_lflow_add_at(LFLOW_MAP, OD, STAGE, PRIORITY, MATCH, ACTIONS, \
- STAGE_HINT, OVS_SOURCE_LOCATOR)
+ STAGE_HINT, NULL, OVS_SOURCE_LOCATOR)
+
+/* Adds a row with the port to the Logical_Flow table. */
+#define ovn_lflow_add_with_port(LFLOW_MAP, OD, STAGE, PRIORITY, MATCH, \
+ACTIONS, STAGE_

[ovs-dev] 答复: [PATCH v1 1/3] Add multipath static router in OVN northd and north-db

2017-09-19 Thread wang . qianyu

How to configure multipath_port in static_route? I think the the multipath 
can be figured out from exist data of static_route, may not need to add 
this multipath_port column.

And I think we should add a status column to indicate the nexthop state. 
When some of nexthop in multipath is down, ovn should change the 
correspond flows.

Thanks.





Zhenyu Gao 
发件人： ovs-dev-boun...@openvswitch.org
2017/09/19 19:37
 
收件人：b...@ovn.org, majop...@redhat.com, 
anilvenk...@redhat.com, russ...@ovn.org, d...@openvswitch.org, 
抄送： 
主题：  [ovs-dev] [PATCH v1 1/3] Add multipath static router in 
OVN northd  and north-db


1. ovn-nb.ovsschema was updated to add new field multipath_port.
2. Add multipath feature in ovn-northd part. northd generates multipath
flows to dispatch traffic by using packet's IP dst address if user set
Logical_Router_Static_Route's multipath_port with ports.
3. Add new table(lr_in_multipath) in ovn-northd's router ingress stages
to dispatch traffic to ports.
4. Add multipath flow in Table 5(lr_in_ip_routing) and store hash result
into reg0. reg9[2] was used to indicate packet which need dispatching.
5. Add multipath feature description in ovn/northd/ovn-northd.8.xml
and ovn/ovn-nb.xml

Signed-off-by: Zhenyu Gao 
---
 ovn/northd/ovn-northd.8.xml |  67 +++-
 ovn/northd/ovn-northd.c | 245 
++--
 ovn/ovn-nb.ovsschema|   6 +-
 ovn/ovn-nb.xml  |   9 ++
 4 files changed, 289 insertions(+), 38 deletions(-)

diff --git a/ovn/northd/ovn-northd.8.xml b/ovn/northd/ovn-northd.8.xml
index 0d85ec0..b1ce9a9 100644
--- a/ovn/northd/ovn-northd.8.xml
+++ b/ovn/northd/ovn-northd.8.xml
@@ -1598,6 +1598,9 @@ icmp4 {
   port (ingress table ARP Request will generate an ARP
   request, if needed, with reg0 as the target protocol
   address and reg1 as the source protocol address).
+  A IP route can be configured that it has multipath to next-hop.
+  If a packet has multipath to destination, OVN assign the port
+  index into reg[0] to indicate the packet's output port in table 6.
 
 
 
@@ -1617,6 +1620,28 @@ icmp4 {
 
   
 
+  IPv4/IPV6 multipath routing table. For each route to IPv4/IPv6
+  network N with netmask M, on multipath 
port
+  P with IP address A and Ethernet
+  address E, a logical flow with match
+  ip4.dst ==N/M,whose priority
+  is the number of 1-bits plus 10 in M,
+  has the following actions:
+
+
+
+ip.ttl--;
+multipath (nw_dst, 0, modulo_n, n_links, 0, reg0);
+reg9[2] = 1
+next;
+
+
+  n_links is the number of multipath port.
+
+  
+
+  
+
   IPv4 routing table.  For each route to IPv4 network 
N with
   netmask M, on router port P with IP 
address
   A and Ethernet
@@ -1686,7 +1711,43 @@ next;
   
 
 
-Ingress Table 6: ARP/ND Resolution
+Ingress Table 6: Multipath
+
+  Any packet taht reaches this table is an IP packet and reg9[2]=1
+  using the following flows to route to corresponding port. This 
table
+  implement dispatching by consuming reg0.
+
+
+
+  
+
+  A packet with netmask M, IP address A and
+  reg9[2] = 1, whose priority above 1 has following
+  actions:
+
+
+
+reg0 = G;
+reg1 = A;
+eth.src = E;
+outport = P;
+flags.loopback = 1;
+next;
+
+
+
+  G is the gateway IP address. A, 
E
+  and P are the values that were described in 
multipath
+  routeing in table 5
+
+
+
+  A priority-0 logical flow with match has actions 
next;.
+
+  
+
+
+Ingress Table 7: ARP/ND Resolution
 
 
   Any packet that reaches this table is an IP packet whose next-hop
@@ -1779,7 +1840,7 @@ next;
   
 
 
-Ingress Table 7: Gateway Redirect
+Ingress Table 8: Gateway Redirect
 
 
   For distributed logical routers where one of the logical router
@@ -1836,7 +1897,7 @@ next;
   
 
 
-Ingress Table 8: ARP Request
+Ingress Table 9: ARP Request
 
 
   In the common case where the Ethernet destination has been 
resolved, this
diff --git a/ovn/northd/ovn-northd.c b/ovn/northd/ovn-northd.c
index 49e4ac3..44d1fd4 100644
--- a/ovn/northd/ovn-northd.c
+++ b/ovn/northd/ovn-northd.c
@@ -135,9 +135,10 @@ enum ovn_stage {
 PIPELINE_STAGE(ROUTER, IN,  UNSNAT,  3, "lr_in_unsnat")   \
 PIPELINE_STAGE(ROUTER, IN,  DNAT,4, "lr_in_dnat") \
 PIPELINE_STAGE(ROUTER, IN,  IP_ROUTING,  5, "lr_in_ip_routing")   \
-PIPELINE_STAGE(ROUTER, IN,  ARP_RESOLVE, 6, "lr_in_arp_resolve")  \
-PIPELINE_STAGE(ROUTER, IN,  GW_REDIRECT, 7, "lr_in_gw_redirect")  \
-PIPELINE_STAGE(ROUTER, IN,  ARP_REQUEST, 8, "lr_in_arp_request")  \
+

[ovs-dev] [PATCH] ovn-northd: add chassis nonull check

2017-09-19 Thread wang . qianyu

op->sb->gateway_chassis[0]->chassis may null in some special cases, need 
to add a check to avoid segment fault.

Signed-off-by: wang qianyu <wang.qia...@zte.com.cn>
---
 ovn/northd/ovn-northd.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/ovn/northd/ovn-northd.c b/ovn/northd/ovn-northd.c
index 49e4ac3..9dd159d 100644
--- a/ovn/northd/ovn-northd.c
+++ b/ovn/northd/ovn-northd.c
@@ -1887,8 +1887,10 @@ ovn_port_update_sbrec(struct northd_context *ctx,
 /* If we found the chassis, and the gw chassis on 
record
  * differs from what we expect go ahead and update */
 if (op->sb->n_gateway_chassis != 1
-|| 
strcmp(op->sb->gateway_chassis[0]->chassis->name,
-  chassis->name)
+|| !op->sb->gateway_chassis[0]->chassis
+|| (op->sb->gateway_chassis[0]->chassis &&
+ strcmp(op->sb->gateway_chassis[0]->chassis->name,
+  chassis->name))
 || op->sb->gateway_chassis[0]->priority != 0) {
 /* Construct a single Gateway_Chassis entry on 
the
  * Port_Binding attached to the redirect_chassis
-- 
1.8.3.1
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH v3] ovn: Support for taas(tap-as-a-service) function

2017-09-19 Thread wang . qianyu

To support taas function, this patch add two type of logica_switch_port, 
"mirror" and "taas". port with type "mirror" is used as inport for monitor 
flow in logica_switch, and port with type "taas" is used as outport for 
monitor flow in logica_switch.

The ovn-controller will make the relations of the ports in tap_service and 
tap_flow to mirror port and taas port.

Signed-off-by: wang qianyu <wang.qia...@zte.com.cn>
---
 ovn/controller/binding.c|   3 +
 ovn/controller/ovn-controller.c |   2 +
 ovn/controller/physical.c   | 168 +++-
 ovn/northd/ovn-northd.c | 276 
+++-
 ovn/ovn-nb.xml  |  57 +
 5 files changed, 502 insertions(+), 4 deletions(-)

diff --git a/ovn/controller/binding.c b/ovn/controller/binding.c
index ca1d433..bbd391f 100644
--- a/ovn/controller/binding.c
+++ b/ovn/controller/binding.c
@@ -437,6 +437,9 @@ consider_local_datapath(struct controller_ctx *ctx,
  * for them. */
 sset_add(local_lports, binding_rec->logical_port);
 our_chassis = false;
+} else if (!strcmp(binding_rec->type, "mirror")) {
+add_local_datapath(ctx, binding_rec->datapath,
+   false, local_datapaths);
 }
 
 if (ctx->ovnsb_idl_txn) {
diff --git a/ovn/controller/ovn-controller.c 
b/ovn/controller/ovn-controller.c
index e2c9652..0a148e4 100644
--- a/ovn/controller/ovn-controller.c
+++ b/ovn/controller/ovn-controller.c
@@ -150,6 +150,8 @@ update_sb_monitors(struct ovsdb_idl *ovnsb_idl,
 struct ovsdb_idl_condition mg = OVSDB_IDL_CONDITION_INIT();
 struct ovsdb_idl_condition dns = OVSDB_IDL_CONDITION_INIT();
 sbrec_port_binding_add_clause_type(, OVSDB_F_EQ, "patch");
+sbrec_port_binding_add_clause_type(, OVSDB_F_EQ, "mirror");
+sbrec_port_binding_add_clause_type(, OVSDB_F_EQ, "taas");
 /* XXX: We can optimize this, if we find a way to only monitor
  * ports that have a Gateway_Chassis that point's to our own
  * chassis */
diff --git a/ovn/controller/physical.c b/ovn/controller/physical.c
index df71979..9070459 100644
--- a/ovn/controller/physical.c
+++ b/ovn/controller/physical.c
@@ -291,9 +291,83 @@ load_logical_ingress_metadata(const struct 
sbrec_port_binding *binding,
 }
 
 static void
+taas_port_handle(const struct sbrec_port_binding *binding,
+ struct ofpbuf *ofpacts_p,
+ struct hmap *flow_table,
+ uint32_t dp_key,
+ uint32_t port_key)
+{
+ofp_port_t ofport = u16_to_ofp(simap_get(_to_ofport,
+  binding->logical_port));
+if (!ofport) {
+VLOG_INFO("can not find ofport of %s in this switch",
+binding->logical_port);
+return;
+}
+struct match match;
+
+/* Table 33, priority 100.
+ * ===
+ *
+ * Implements output to local hypervisor.  Each flow matches a
+ * logical output port on the local hypervisor, and resubmits to
+ * table 34.
+ */
+match_init_catchall();
+ofpbuf_clear(ofpacts_p);
+match_set_metadata(, htonll(dp_key));
+match_set_reg(, MFF_LOG_OUTPORT - MFF_REG0, port_key);
+
+/* Resubmit to table 34. */
+put_resubmit(OFTABLE_CHECK_LOOPBACK, ofpacts_p);
+ofctrl_add_flow(flow_table, OFTABLE_LOCAL_OUTPUT, 100, 0,
+, ofpacts_p);
+
+/* Table 65, Priority 100.
+ * ===
+ *
+ * Deliver the packet to the local vif. */
+match_init_catchall();
+ofpbuf_clear(ofpacts_p);
+match_set_metadata(, htonll(dp_key));
+match_set_reg(, MFF_LOG_OUTPORT - MFF_REG0, port_key);
+ofpact_put_OUTPUT(ofpacts_p)->port = ofport;
+ofctrl_add_flow(flow_table, OFTABLE_LOG_TO_PHY, 100, 0,
+, ofpacts_p);
+}
+
+struct mirror_port {
+struct sbrec_port_binding *port;
+struct ovs_list list;
+};
+
+static void
+get_mports_from_lport(struct shash *mports,
+  char *logical_port_name,
+  struct ovs_list *mport_list)
+{
+struct shash_node *node, *next_node;
+SHASH_FOR_EACH_SAFE (node, next_node, mports) {
+struct sbrec_port_binding *binding = node->data;
+const char *source_port_name = smap_get(>options,
+"source-port");
+if (!source_port_name) {
+continue;
+}
+if (strcmp(source_port_name, logical_port_name)) {
+continue;
+}
+struct mirror_port *mport = xzalloc(sizeof *mport);
+mport->port = binding;
+ovs_list_push_back(mport_list, >list);
+ }
+}
+
+static void
 consider_port_binding(struct controller_ctx *ctx,
   enum mf_field_id mff_ovn_geneve,

[ovs-dev] 答复: Re: [PATCH] ovn: Discard flows for non-local ports.

2017-09-18 Thread wang . qianyu

I agree with  Han Zhou, This patch can reduce the flow to vswitchd, but 
can not reduce the flow calculation of ovn-controller. It may be better to 
move the check for
local_lport_ids before the parse happens. Add a lport column in logical 
flow may be more efficient.

Thanks.

Han Zhou 
发件人： ovs-dev-boun...@openvswitch.org
2017/09/19 07:31

收件人：Russell Bryant , 
抄送：  "d...@openvswitch.org" , Miguel Angel 
Ajo Pelayo 
主题：  Re: [ovs-dev] [PATCH] ovn: Discard flows for non-local 
ports.

Thanks Russell for the quick work!

On Mon, Sep 18, 2017 at 8:24 AM, Russell Bryant  wrote:

> @@ -301,6 +305,22 @@ consider_logical_flow(struct controller_ctx *ctx,
>  if (m->match.wc.masks.conj_id) {
>  m->match.flow.conj_id += *conj_id_ofs;
>  }
> +if (is_switch(ldp)) {
> +unsigned int reg_index
> += (ingress ? MFF_LOG_INPORT : MFF_LOG_OUTPORT) -
MFF_REG0;
> +int64_t port_id = m->match.flow.regs[reg_index];
> +if (port_id) {
> +int64_t dp_id = lflow->logical_datapath->tunnel_key;
> +char buf[16];
> +snprintf(buf, sizeof(buf), "%"PRId64"_%"PRId64, dp_id,
port_id);
> +if (!sset_contains(local_lport_ids, buf)) {
> +//VLOG_INFO("Matching on port id %"PRId64" dp
%"PRId64", is NOT local", port_id, dp_id);
> +continue;
> +} else {
> +//VLOG_INFO("Matching on port id %"PRId64" dp
%"PRId64", is local", port_id, dp_id);
> +}
> +}
> +}
>  if (!m->n) {
>  ofctrl_add_flow(flow_table, ptable, lflow->priority,
>  lflow->header_.uuid.parts[0], >match,
);

I remember the expr_parse_string() is one of the biggest cost in
ovn-controller, so I wonder would it be better to move the check for
local_lport_ids before the parse happens, i.e. check against logical flows
instead of ovs flows?

Acked-by: Han Zhou 
___
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

[ovs-dev] 答复: [RFC] Question about ovn-controller performance

2017-09-14 Thread wang . qianyu

Hi everyone,

Whether we could add a port property to logical flow? port property have 
value of "normal" or logical port name. If the port property is "normal" 
means this logical flow should be allocated to all HVs, if port property 
is a name of logical_port, means this logical flow is related to specific 
port, not need allocated to all computer nodes.

I think this manner may reduce a great mount of flows in single HV.

Thanks.






王前宇10110202
2017/09/14 10:39
 
收件人：az...@ovn.org, b...@ovn.org, zhou...@gmail.com, 
抄送：  d...@openvswitch.org, XuRong037997/user/zte_ltd@zte_ltd, 
ZhouHuiJing033341/user/zte_ltd@zte_ltd
主题：  [ovs-dev] [RFC] Question about ovn-controller performance

I configure 5 networks, every network have about 80 ports, the total ports 
is 400, all in same security group.

When I bind some port on HVs, the ovn-controller is always running with 
100% cpu, and the total openflow table entities in ovs is more than 
300,000. Most of the entities is table 52, worked as src ip filter.

Could some one tell me how to reduce the flows or how to make 
ovn-controller work more efficient or do some options to reduce the table 
number of acls?

The attachment is the dump of ovn-sb.

Thanks.



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

[ovs-dev] [RFC] Question about ovn-controller performance

2017-09-13 Thread wang . qianyu

I configure 5 networks, every network have about 80 ports, the total ports 
is 400, all in same security group.

When I bind some port on HVs, the ovn-controller is always running with 
100% cpu, and the total openflow table entities in ovs is more than 
300,000. Most of the entities is table 52, worked as src ip filter.

Could some one tell me how to reduce the flows or how to make 
ovn-controller work more efficient or do some options to reduce the table 
number of acls?

The attachment is the dump of ovn-sb.

Thanks.

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

[ovs-dev] 答复: Re: 答复: Re: 答复: Re: 答复: Re: 答复: Re: [PATCH v2] ovn: Support for taas(tap-as-a-service) function

2017-09-11 Thread wang . qianyu

packet.
>
> When we use inport to indicate the flag, this may need use inport as the
> match field in the egress pipeline, I think this may conflict with the
> egress pipeline.
>
> If use geneve option to deliver the mirror flag, this may be more
> complicated. So, I add a new type of port as the destination of mirror
> flow. The port types of mirror and taas corresponding to configurations 
of
> tap-flow and tap-service.
>
> Thanks.
>
>
>
>
>
> Russell Bryant <*russ...@ovn.org* <russ...@ovn.org>>
> 2017/08/25 04:44
>
> 收件人：*wang.qia...@zte.com.cn* <wang.qia...@zte.com.cn
>,
> 抄送：  ovs dev <*d...@openvswitch.org* <d...@openvswitch.org>>,
> *zhou.huij...@zte.com.cn* <zhou.huij...@zte.com.cn>,
> xurong00037997 <*xu.r...@zte.com.cn* <xu.r...@zte.com.cn>>
> 主题：  Re: [ovs-dev] [PATCH v2] ovn: Support for
> taas(tap-as-a-service) function
>
>
> Sorry for the delay in getting back to this ...
>
> On Tue, Aug 15, 2017 at 4:28 AM,  <*wang.qia...@zte.com.cn*
> <wang.qia...@zte.com.cn>> wrote:
> > Taas was designed to provide tenants and service providers a means of
> > monitoring the traffic flowing in their Neutron provisioned virtual
> > networks. It is useful for network trouble-shooting, security and
> > analytics. The taas presentations could be found from
> >
>
> *
https://github.com/openstack/tap-as-a-service/blob/master/doc/source/presentations.rst*

> <
https://github.com/openstack/tap-as-a-service/blob/master/doc/source/presentations.rst
>
>
> > , and the api reference could be found from
> >
>
> *
https://github.com/openstack/tap-as-a-service/blob/master/API_REFERENCE.rst*

> <
https://github.com/openstack/tap-as-a-service/blob/master/API_REFERENCE.rst
>
>
> >
> > To support taas function, this patch add two type of 
logica_switch_port,
> > "mirror" and "taas". port with type "mirror" is used as inport for
> monitor
> > flow in logica_switch, and port with type "taas" is used as outport 
for
> > monitor flow in logica_switch.
> >
> > The ovn-controller will make the relations of the ports in tap_service
> and
> > tap_flow to mirror port and taas port.
> >
> > Signed-off-by: wang qianyu <*wang.qia...@zte.com.cn* 
> <wang.qia...@zte.com.cn>>
>
> > diff --git a/ovn/ovn-nb.xml b/ovn/ovn-nb.xml
> > index 31303a8..5fdd045 100644
> > --- a/ovn/ovn-nb.xml
> > +++ b/ovn/ovn-nb.xml
> > @@ -301,6 +301,20 @@
> >
> >  A port to a logical switch on a VTEP gateway.
> >
> > +
> > +  mirror
> > +  
> > +A port indicate the inport of mirrored flows. The user 
need
> > to
> > +create this port in the logical_switch. This port should
> one
> > to
> > +one correspondence with the the tap_flows
> > +  
> > +
> > +  taas
> > +  
> > +A port indicate the outport of mirrored flows. The user
> need
> > to
> > +create this port in logical_switch. This port should one 
to
> > +one correspondence with the the tap_service.
> > +  
> >  
> >
> >  
> > @@ -445,6 +459,61 @@
> >interface, in bits.
> >  
> >
> > +
> > +  
> > +
> > +  These options apply when  is
> > +  mirror.
> > +
> > +
> > +
> > +  Required.  The  of the  > +  table="Logical_switch_Port"/> that indicates where the
> > +  cloned flows come from.
> > +
> > +
> > +
> > +  Required.  The  of the  > +  table="Logical_switch_Port"/> with type taas.
> > +
> > +
> > +
> > + 
> > +This option indicates whitch
> direction(from-port/to-port/all)
> > of
> > +packet will be cloned to the taas-port. The directions 
are
> > defined
> > +as follow:
> > +  
> > +  
> > +from-port
> > +
> > +  The packets from this port will be cloned to specified
> > mirror
> > +  port.
> > +
> > +to-port
> > +
> > +  The packets to this port will be cloned to specified
> mirror
> > +  port.
> > +

[ovs-dev] 答复: Re: 答复: Re: 答复: Re: 答复: Re: [PATCH v2] ovn: Support for taas(tap-as-a-service) function

2017-09-08 Thread wang . qianyu

as was designed to provide tenants and service providers a means of
> > monitoring the traffic flowing in their Neutron provisioned virtual
> > networks. It is useful for network trouble-shooting, security and
> > analytics. The taas presentations could be found from
> >
>
> *
https://github.com/openstack/tap-as-a-service/blob/master/doc/source/presentations.rst*

> <
https://github.com/openstack/tap-as-a-service/blob/master/doc/source/presentations.rst
>
>
> > , and the api reference could be found from
> >
>
> *
https://github.com/openstack/tap-as-a-service/blob/master/API_REFERENCE.rst*

> <
https://github.com/openstack/tap-as-a-service/blob/master/API_REFERENCE.rst
>
>
> >
> > To support taas function, this patch add two type of 
logica_switch_port,
> > "mirror" and "taas". port with type "mirror" is used as inport for
> monitor
> > flow in logica_switch, and port with type "taas" is used as outport 
for
> > monitor flow in logica_switch.
> >
> > The ovn-controller will make the relations of the ports in tap_service
> and
> > tap_flow to mirror port and taas port.
> >
> > Signed-off-by: wang qianyu <*wang.qia...@zte.com.cn*
> <wang.qia...@zte.com.cn>>
>
> > diff --git a/ovn/ovn-nb.xml b/ovn/ovn-nb.xml
> > index 31303a8..5fdd045 100644
> > --- a/ovn/ovn-nb.xml
> > +++ b/ovn/ovn-nb.xml
> > @@ -301,6 +301,20 @@
> >
> >  A port to a logical switch on a VTEP gateway.
> >
> > +
> > +  mirror
> > +  
> > +A port indicate the inport of mirrored flows. The user 
need
> > to
> > +create this port in the logical_switch. This port should
> one
> > to
> > +one correspondence with the the tap_flows
> > +  
> > +
> > +  taas
> > +  
> > +A port indicate the outport of mirrored flows. The user
> need
> > to
> > +create this port in logical_switch. This port should one 
to
> > +one correspondence with the the tap_service.
> > +  
> >  
> >
> >  
> > @@ -445,6 +459,61 @@
> >interface, in bits.
> >  
> >
> > +
> > +  
> > +
> > +  These options apply when  is
> > +  mirror.
> > +
> > +
> > +
> > +  Required.  The  of the  > +  table="Logical_switch_Port"/> that indicates where the
> > +  cloned flows come from.
> > +
> > +
> > +
> > +  Required.  The  of the  > +  table="Logical_switch_Port"/> with type taas.
> > +
> > +
> > +
> > + 
> > +This option indicates whitch
> direction(from-port/to-port/all)
> > of
> > +packet will be cloned to the taas-port. The directions 
are
> > defined
> > +as follow:
> > +  
> > +  
> > +from-port
> > +
> > +  The packets from this port will be cloned to specified
> > mirror
> > +  port.
> > +
> > +to-port
> > +
> > +  The packets to this port will be cloned to specified
> mirror
> > +  port.
> > +
> > +both
> > +
> > +  The packets both from and to this port will be cloned 
to
> > +  specified mirror port.
> > +
> > +  
> > +
> > +  
> > +
> > +  
> > +
> > +  These options apply when  is
> > taas.
> > +
> > +
> > +
> > +  Required.  The  of the  > +  table="Logical_switch_Port"/> that indicates where the
> > +  cloned flows come to.
> > +
> > +  
> >  
> >
> >  
>
> I'm having a hard time understanding this schema.  Could you expand on
> why both a "mirror" and "taas" port type was needed?
>
> I was hoping for only a single new port type, "mirror" for example,
> with options to specify what port it is receiving a mirror of traffic
> for.
>
> Does something like that not express everything needed here?
>
> --
> Russell Bryant
>
>
> ___
> dev mailing list
> *d...@openvswitch.org* <d...@openvswitch.org>
> *https://mail.openvswitch.org/mailman/listinfo/ovs-dev*
> <https://mail.openvswitch.org/mailman/listinfo/ovs-dev>
>
>
>


--
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

[ovs-dev] 答复: Re: 答复: Re: 答复: Re: 答复: Re: [PATCH v2] ovn: Support for taas(tap-as-a-service) function

2017-09-05 Thread wang . qianyu

Mirror port only receives mirrored packets. I would remove the flag, and 
uses inport and outport to mark the mirrored packets.

Thanks.

Russell Bryant <russ...@ovn.org>
2017/09/06 02:57

收件人：wang.qia...@zte.com.cn, 
抄送：  Gao Zhenyu <sysugaozhe...@gmail.com>, ovs dev 
<d...@openvswitch.org>, xurong00037997 <xu.r...@zte.com.cn>, 
zhou.huij...@zte.com.cn
主题：  Re: 答复: Re: 答复: Re: [ovs-dev] 答复: Re: [PATCH v2] 
ovn: Support for taas(tap-as-a-service) function

What if a mirror port *only* receives mirrored packets?  If the only 
packets it ever receives are mirrored packets, a new flag would not be 
necessary.

Do you intend for the port to operate as both a regular port *and* to 
receive a mirror of traffic  for another port?

On Thu, Aug 24, 2017 at 10:31 PM, <wang.qia...@zte.com.cn> wrote:
I know your mean. 
The receiver need to distinguish the traffic is regular or mirror. This 
may need some special flow table to deal with it. 

Thanks 

Gao Zhenyu <sysugaozhe...@gmail.com> 
2017/08/25 10:12 

收件人：wang.qia...@zte.com.cn, 
抄送：ovs dev <d...@openvswitch.org>, Russell Bryant <
russ...@ovn.org>, xurong00037997 <xu.r...@zte.com.cn>, 
zhou.huij...@zte.com.cn 
主题：Re: 答复: Re: [ovs-dev] 答复: Re: [PATCH v2] ovn: 
Support for taas(tap-as-a-service) function

I mean for regular packet, ovs should not add the geneve option,  the new 
geneve option is only for mirror traffic.

Did you meant some mirror traffic has mirror flag and some would not have? 

Thanks 
Zhenyu Gao 

2017-08-25 9:44 GMT+08:00 <wang.qia...@zte.com.cn>: 
Hi zhenyu, 
Thanks for your opinion. 
The mirror flag is not always exist, so I do not think add a new geneve 
option is a good idea. 

Thanks. 

Gao Zhenyu <sysugaozhe...@gmail.com> 
2017/08/25 09:34 

收件人：wang.qia...@zte.com.cn, 
抄送：Russell Bryant <russ...@ovn.org>, ovs dev <
d...@openvswitch.org>, zhou.huij...@zte.com.cn, xurong00037997 <
xu.r...@zte.com.cn> 
主题：Re: [ovs-dev] 答复: Re: [PATCH v2] ovn: Support for 
taas(tap-as-a-service) function

Although adding a new geneve option is more complicate but I think it 
still worth having that. 
Once the destination chassis found that geneve option, it can tag the 
mirror flag on packet. And it make the whole process looks same no matter 
on same chassis or not.

Thanks 
Zhenyu Gao 

2017-08-25 9:15 GMT+08:00 <wang.qia...@zte.com.cn>: 
Hi Russell,

Thanks for your review.

When the mirror destination is in other chassis, the mirror flag which
used to mark the packet need be transmitted to the destination chassis.

We could use the inport, geneve option or new type of out port to indicate
the packet as a mirrored packet.

When we use inport to indicate the flag, this may need use inport as the
match field in the egress pipeline, I think this may conflict with the
egress pipeline.

If use geneve option to deliver the mirror flag, this may be more
complicated. So, I add a new type of port as the destination of mirror
flow. The port types of mirror and taas corresponding to configurations of
tap-flow and tap-service.

Thanks.

Russell Bryant <russ...@ovn.org>
2017/08/25 04:44

收件人：wang.qia...@zte.com.cn,
抄送：  ovs dev <d...@openvswitch.org>, zhou.huij...@zte.com.cn,
xurong00037997 <xu.r...@zte.com.cn>
主题：  Re: [ovs-dev] [PATCH v2] ovn: Support for
taas(tap-as-a-service) function 

Sorry for the delay in getting back to this ...

On Tue, Aug 15, 2017 at 4:28 AM,  <wang.qia...@zte.com.cn> wrote:
> Taas was designed to provide tenants and service providers a means of
> monitoring the traffic flowing in their Neutron provisioned virtual
> networks. It is useful for network trouble-shooting, security and
> analytics. The taas presentations could be found from
>
https://github.com/openstack/tap-as-a-service/blob/master/doc/source/presentations.rst

> , and the api reference could be found from
>
https://github.com/openstack/tap-as-a-service/blob/master/API_REFERENCE.rst

>
> To support taas function, this patch add two type of logica_switch_port,
> "mirror" and "taas". port with type "mirror" is used as inport for
monitor
> flow in logica_switch, and port with type "taas" is used as outport for
> monitor flow in logica_switch.
>
> The ovn-controller will make the relations of the ports in tap_service
and
> tap_flow to mirror port and taas port.
>
> Signed-off-by: wang qianyu <wang.qia...@zte.com.cn>

> diff --git a/ovn/ovn-nb.xml b/ovn/ovn-nb.xml
> index 31303a8..5fdd045 100644
> --- a/ovn/ovn-nb.xml
> +++ b/ovn/ovn-nb.xml
> @@ -301,6 +301,20 @@
>
>  A port to a logical switch on a VTEP gateway.
>

[ovs-dev] [RFC] Deploy HA for Ovn-controller-vtep

2017-08-29 Thread wang . qianyu

Hi everyone

Ovn-controller-vtep is the link of logical switch and pysical switch. 
Whether we should deploy the Ovn-controller-vtep and vtep db with HA?

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

[ovs-dev] 答复: Re: 答复: Re: [PATCH v2] ovn: Support for taas(tap-as-a-service) function

2017-08-24 Thread wang . qianyu

Hi zhenyu,
Thanks for your opinion.
The mirror flag is not always exist, so I do not think add a new geneve 
option is a good idea.

Thanks. 





Gao Zhenyu <sysugaozhe...@gmail.com>
2017/08/25 09:34
 
收件人：wang.qia...@zte.com.cn, 
抄送：  Russell Bryant <russ...@ovn.org>, ovs dev 
<d...@openvswitch.org>, zhou.huij...@zte.com.cn, xurong00037997 
<xu.r...@zte.com.cn>
主题：  Re: [ovs-dev] 答复: Re: [PATCH v2] ovn: Support for 
taas(tap-as-a-service) function


Although adding a new geneve option is more complicate but I think it 
still worth having that.
Once the destination chassis found that geneve option, it can tag the 
mirror flag on packet. And it make the whole process looks same no matter 
on same chassis or not.

Thanks
Zhenyu Gao

2017-08-25 9:15 GMT+08:00 <wang.qia...@zte.com.cn>:
Hi Russell,

Thanks for your review.

When the mirror destination is in other chassis, the mirror flag which
used to mark the packet need be transmitted to the destination chassis.

We could use the inport, geneve option or new type of out port to indicate
the packet as a mirrored packet.

When we use inport to indicate the flag, this may need use inport as the
match field in the egress pipeline, I think this may conflict with the
egress pipeline.

If use geneve option to deliver the mirror flag, this may be more
complicated. So, I add a new type of port as the destination of mirror
flow. The port types of mirror and taas corresponding to configurations of
tap-flow and tap-service.

Thanks.





Russell Bryant <russ...@ovn.org>
2017/08/25 04:44

收件人：wang.qia...@zte.com.cn,
抄送：  ovs dev <d...@openvswitch.org>, zhou.huij...@zte.com.cn,
xurong00037997 <xu.r...@zte.com.cn>
主题：  Re: [ovs-dev] [PATCH v2] ovn: Support for
taas(tap-as-a-service) function


Sorry for the delay in getting back to this ...

On Tue, Aug 15, 2017 at 4:28 AM,  <wang.qia...@zte.com.cn> wrote:
> Taas was designed to provide tenants and service providers a means of
> monitoring the traffic flowing in their Neutron provisioned virtual
> networks. It is useful for network trouble-shooting, security and
> analytics. The taas presentations could be found from
>
https://github.com/openstack/tap-as-a-service/blob/master/doc/source/presentations.rst


> , and the api reference could be found from
>
https://github.com/openstack/tap-as-a-service/blob/master/API_REFERENCE.rst


>
> To support taas function, this patch add two type of logica_switch_port,
> "mirror" and "taas". port with type "mirror" is used as inport for
monitor
> flow in logica_switch, and port with type "taas" is used as outport for
> monitor flow in logica_switch.
>
> The ovn-controller will make the relations of the ports in tap_service
and
> tap_flow to mirror port and taas port.
>
> Signed-off-by: wang qianyu <wang.qia...@zte.com.cn>

> diff --git a/ovn/ovn-nb.xml b/ovn/ovn-nb.xml
> index 31303a8..5fdd045 100644
> --- a/ovn/ovn-nb.xml
> +++ b/ovn/ovn-nb.xml
> @@ -301,6 +301,20 @@
>
>  A port to a logical switch on a VTEP gateway.
>
> +
> +  mirror
> +  
> +A port indicate the inport of mirrored flows. The user need
> to
> +create this port in the logical_switch. This port should
one
> to
> +one correspondence with the the tap_flows
> +  
> +
> +  taas
> +  
> +A port indicate the outport of mirrored flows. The user
need
> to
> +create this port in logical_switch. This port should one to
> +one correspondence with the the tap_service.
> +  
>  
>
>  
> @@ -445,6 +459,61 @@
>interface, in bits.
>  
>
> +
> +  
> +
> +  These options apply when  is
> +  mirror.
> +
> +
> +
> +  Required.  The  of the  +  table="Logical_switch_Port"/> that indicates where the
> +  cloned flows come from.
> +
> +
> +
> +  Required.  The  of the  +  table="Logical_switch_Port"/> with type taas.
> +
> +
> +
> + 
> +This option indicates whitch
direction(from-port/to-port/all)
> of
> +packet will be cloned to the taas-port. The directions are
> defined
> +as follow:
> +  
> +  
> +from-port
> +
> +  The packets from this port will be cloned to specified
> mirror
> +  port.
> +
> +to-port
> +
> +

[ovs-dev] 答复: Re: [PATCH v2] ovn: Support for taas(tap-as-a-service) function

2017-08-24 Thread wang . qianyu

Hi Russell,

Thanks for your review.

When the mirror destination is in other chassis, the mirror flag which 
used to mark the packet need be transmitted to the destination chassis.

We could use the inport, geneve option or new type of out port to indicate 
the packet as a mirrored packet.

When we use inport to indicate the flag, this may need use inport as the 
match field in the egress pipeline, I think this may conflict with the 
egress pipeline.

If use geneve option to deliver the mirror flag, this may be more 
complicated. So, I add a new type of port as the destination of mirror 
flow. The port types of mirror and taas corresponding to configurations of 
tap-flow and tap-service.

Thanks.





Russell Bryant <russ...@ovn.org>
2017/08/25 04:44
 
收件人：wang.qia...@zte.com.cn, 
抄送：  ovs dev <d...@openvswitch.org>, zhou.huij...@zte.com.cn, 
xurong00037997 <xu.r...@zte.com.cn>
主题：  Re: [ovs-dev] [PATCH v2] ovn: Support for 
taas(tap-as-a-service) function


Sorry for the delay in getting back to this ...

On Tue, Aug 15, 2017 at 4:28 AM,  <wang.qia...@zte.com.cn> wrote:
> Taas was designed to provide tenants and service providers a means of
> monitoring the traffic flowing in their Neutron provisioned virtual
> networks. It is useful for network trouble-shooting, security and
> analytics. The taas presentations could be found from
> 
https://github.com/openstack/tap-as-a-service/blob/master/doc/source/presentations.rst

> , and the api reference could be found from
> 
https://github.com/openstack/tap-as-a-service/blob/master/API_REFERENCE.rst

>
> To support taas function, this patch add two type of logica_switch_port,
> "mirror" and "taas". port with type "mirror" is used as inport for 
monitor
> flow in logica_switch, and port with type "taas" is used as outport for
> monitor flow in logica_switch.
>
> The ovn-controller will make the relations of the ports in tap_service 
and
> tap_flow to mirror port and taas port.
>
> Signed-off-by: wang qianyu <wang.qia...@zte.com.cn>

> diff --git a/ovn/ovn-nb.xml b/ovn/ovn-nb.xml
> index 31303a8..5fdd045 100644
> --- a/ovn/ovn-nb.xml
> +++ b/ovn/ovn-nb.xml
> @@ -301,6 +301,20 @@
>
>  A port to a logical switch on a VTEP gateway.
>
> +
> +  mirror
> +  
> +A port indicate the inport of mirrored flows. The user need
> to
> +create this port in the logical_switch. This port should 
one
> to
> +one correspondence with the the tap_flows
> +  
> +
> +  taas
> +  
> +A port indicate the outport of mirrored flows. The user 
need
> to
> +create this port in logical_switch. This port should one to
> +one correspondence with the the tap_service.
> +  
>  
>
>  
> @@ -445,6 +459,61 @@
>interface, in bits.
>  
>
> +
> +  
> +
> +  These options apply when  is
> +  mirror.
> +
> +
> +
> +  Required.  The  of the  +  table="Logical_switch_Port"/> that indicates where the
> +  cloned flows come from.
> +
> +
> +
> +  Required.  The  of the  +  table="Logical_switch_Port"/> with type taas.
> +
> +
> +
> + 
> +This option indicates whitch 
direction(from-port/to-port/all)
> of
> +packet will be cloned to the taas-port. The directions are
> defined
> +as follow:
> +  
> +  
> +from-port
> +
> +  The packets from this port will be cloned to specified
> mirror
> +  port.
> +
> +to-port
> +
> +  The packets to this port will be cloned to specified 
mirror
> +  port.
> +
> +both
> +
> +  The packets both from and to this port will be cloned to
> +  specified mirror port.
> +
> +  
> +
> +  
> +
> +  
> +
> +  These options apply when  is
> taas.
> +
> +
> +
> +  Required.  The  of the  +  table="Logical_switch_Port"/> that indicates where the
> +  cloned flows come to.
> +
> +  
>  
>
>  

I'm having a hard time understanding this schema.  Could you expand on
why both a "mirror" and "taas" port type was needed?

I was hoping for only a single new port type, "mirror" for example,
with options to specify what port it is receiving a mirror of traffic
for.

Does something like that not express everything needed here?

-- 
Russell Bryant


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

[ovs-dev] [PATCH v2] ovn: Support for taas(tap-as-a-service) function

2017-08-15 Thread wang . qianyu

Taas was designed to provide tenants and service providers a means of 
monitoring the traffic flowing in their Neutron provisioned virtual 
networks. It is useful for network trouble-shooting, security and 
analytics. The taas presentations could be found from 
https://github.com/openstack/tap-as-a-service/blob/master/doc/source/presentations.rst
, and the api reference could be found from 
https://github.com/openstack/tap-as-a-service/blob/master/API_REFERENCE.rst

To support taas function, this patch add two type of logica_switch_port, 
"mirror" and "taas". port with type "mirror" is used as inport for monitor 
flow in logica_switch, and port with type "taas" is used as outport for 
monitor flow in logica_switch.

The ovn-controller will make the relations of the ports in tap_service and 
tap_flow to mirror port and taas port.

Signed-off-by: wang qianyu <wang.qia...@zte.com.cn>
---
 ovn/controller/binding.c|  12 ++
 ovn/controller/ovn-controller.c |   2 +
 ovn/controller/physical.c   | 185 +-
 ovn/lib/logical-fields.c|   4 +
 ovn/lib/logical-fields.h|   4 +
 ovn/northd/ovn-northd.c | 329 

 ovn/ovn-nb.xml  |  69 +
 7 files changed, 603 insertions(+), 2 deletions(-)

diff --git a/ovn/controller/binding.c b/ovn/controller/binding.c
index 32309e9..fc74ea0 100644
--- a/ovn/controller/binding.c
+++ b/ovn/controller/binding.c
@@ -437,6 +437,18 @@ consider_local_datapath(struct controller_ctx *ctx,
  * for them. */
 sset_add(local_lports, binding_rec->logical_port);
 our_chassis = false;
+} else if (!strcmp(binding_rec->type, "mirror")) {
+add_local_datapath(ctx, binding_rec->datapath,
+   false, local_datapaths);
+} else if (!strcmp(binding_rec->type, "taas")) {
+const char *target_port_name = smap_get(_rec->options,
+  "target-port");
+if (target_port_name &&
+sset_contains(local_lports, target_port_name)) {
+our_chassis = true;
+}
+add_local_datapath(ctx, binding_rec->datapath,
+   false, local_datapaths);
 }
 
 if (ctx->ovnsb_idl_txn) {
diff --git a/ovn/controller/ovn-controller.c 
b/ovn/controller/ovn-controller.c
index e2c9652..0a148e4 100644
--- a/ovn/controller/ovn-controller.c
+++ b/ovn/controller/ovn-controller.c
@@ -150,6 +150,8 @@ update_sb_monitors(struct ovsdb_idl *ovnsb_idl,
 struct ovsdb_idl_condition mg = OVSDB_IDL_CONDITION_INIT();
 struct ovsdb_idl_condition dns = OVSDB_IDL_CONDITION_INIT();
 sbrec_port_binding_add_clause_type(, OVSDB_F_EQ, "patch");
+sbrec_port_binding_add_clause_type(, OVSDB_F_EQ, "mirror");
+sbrec_port_binding_add_clause_type(, OVSDB_F_EQ, "taas");
 /* XXX: We can optimize this, if we find a way to only monitor
  * ports that have a Gateway_Chassis that point's to our own
  * chassis */
diff --git a/ovn/controller/physical.c b/ovn/controller/physical.c
index df71979..7b55b04 100644
--- a/ovn/controller/physical.c
+++ b/ovn/controller/physical.c
@@ -291,9 +291,100 @@ load_logical_ingress_metadata(const struct 
sbrec_port_binding *binding,
 }
 
 static void
+taas_port_handle(struct controller_ctx *ctx,
+ const struct sbrec_port_binding *binding,
+ struct ofpbuf *ofpacts_p,
+ struct hmap *flow_table,
+ uint32_t dp_key,
+ uint32_t port_key)
+{
+const char *target_port_name = smap_get(>options,
+  "target-port");
+if (!target_port_name) {
+VLOG_INFO("taas port %s not configure target-port",
+ binding->logical_port);
+return;
+}
+const struct sbrec_port_binding *target_port = lport_lookup_by_name(
+ctx->ovnsb_idl, target_port_name);
+if (!target_port) {
+VLOG_INFO("can not find target port %s in this switch",
+target_port_name);
+return;
+}
+
+ofp_port_t ofport = u16_to_ofp(simap_get(_to_ofport,
+  target_port_name));
+if (!ofport) {
+VLOG_INFO("can not find ofport of %s in this switch",
+target_port_name);
+return;
+}
+struct match match;
+
+/* Table 33, priority 100.
+ * ===
+ *
+ * Implements output to local hypervisor.  Each flow matches a
+ * logical output port on the local hypervisor, and resubmits to
+ * table 34.
+ */
+match_init_catchall();
+ofpbuf_clear(ofpacts_p);
+match_set_metadata(, htonll(dp_key));
+match_set_reg(, MFF_LOG_OUTPORT - MFF_REG0, port

[ovs-dev] 答复: Re: 答复: Re: 答复: Re: 答复: Re: [PATCH] ovn: Support for taas(tap-as-a-service) function

2017-08-07 Thread wang . qianyu

Ok, I will make a new version which have no mirror switch. This may need 
some days.

Thanks





Gao Zhenyu 
2017/08/07 22:34
 
收件人：Ben Pfaff , 
抄送：  wang.qia...@zte.com.cn, ovs dev , 
zhou.huij...@zte.com.cn, Miguel Angel Ajo Pelayo , 
xurong00037997 
主题：  Re: [ovs-dev] 答复: Re: 答复: Re: 答复: Re: [PATCH] ovn: 
Support for taas(tap-as-a-service) function


I agree with Ben. I didn't see a strong requirement that we must need to 
create a new type of switch for mirroring.

We may introduce more and more features in future, some of them may get 
same request(handle packet in a special way) as well. But introduceing a 
new type of logcial switch makes the whole logical more complex.
So I prefer to use a bit of reg to mark it and follow same pipline. 

Thanks
Zhenyu Gao

2017-08-07 21:41 GMT+08:00 Ben Pfaff :
You keep mentioning "a new type of switch".  I don't understand this.
Who has proposed adding a new type of switch, and what kind of switch
would this be?

On Mon, Aug 07, 2017 at 01:37:52PM +0800, wang.qia...@zte.com.cn wrote:
> If we do not add a new type of switch, we should write flag to a reg to
> indicate the matched packets which are cloned to monitor.
>
> This reg should add to all the pipeline stages of logical switch(both
> ingress and egress) to distinguish from normal flow. Is this right for
> Russell's point?
>
> If we add a new type of switch, we could define a new pipeline like 
bellow
> for the monitor function, this have no influence on normal pipeline.
>
> /* Logical mirror switch ingress stages. */ \
> PIPELINE_STAGE(MSWITCH, IN,  MIRROR_IN,   0, "lms_in_port")   \
> PIPELINE_STAGE(MSWITCH, IN,  FLOW_FILTER, 1, "lms_in_flow_filter")\
> PIPELINE_STAGE(MSWITCH, IN,  OUT_LK,  2, "lms_in_out_lk") \
>   \
> /* Logical mirror switch egress stages. */\
> PIPELINE_STAGE(MSWITCH, OUT, FLOW_FILTER, 0, "lms_out_flow_filter")\
> PIPELINE_STAGE(MSWITCH, OUT, DELIVERY,1, "lms_out_delivery")
>
> I think the new defined switch is easy to understand.
>
> Thanks
>
>
>
>
>
>
> Ben Pfaff 
> 2017/08/07 11:03
>
> 收件人：wang.qia...@zte.com.cn,
> 抄送：  Russell Bryant , ovs dev
> , zhou.huij...@zte.com.cn, xurong00037997
> , Miguel Angel Ajo Pelayo 
> 主题：  Re: [ovs-dev] 答复: Re: 答复: Re:  [PATCH] ovn: Support
> for taas(tap-as-a-service) function
>
>
> I am having a very hard time understanding what you're writing here.
> Russell's point makes sense to me, but I don't understand your response.
> Can you give some examples?
>
> On Mon, Aug 07, 2017 at 09:40:06AM +0800, wang.qia...@zte.com.cn wrote:
> > Not add new logical_mirror_switch, just use logical_switch of course 
can
>
> > capture the use case. But logical_switch pipeline is complex for flow
> > monitor. Flow monitor should ignore some tables such as port_security,
> lb
> > and so on. And also should consider normal function for normal ports. 
I
> > think add a new type of switch and the corresponding pipeline may be
> more
> > clear in logical.
> >
> > Is there some adverse effect to add new type switch?
> >
> > Thanks.
> >
> >
> >
> >
> > Russell Bryant 
> > 2017/08/04 22:06
> >
> > 收件人：wang.qia...@zte.com.cn,
> > 抄送：  Miguel Angel Ajo Pelayo , ovs dev
> > , xurong00037997 ,
> > zhou.huij...@zte.com.cn
> > 主题：  Re: 答复: Re: [ovs-dev] [PATCH] ovn: Support for
> > taas(tap-as-a-service) function
> >
> >
> >
> >
> > On Thu, Aug 3, 2017 at 8:52 PM,  wrote:
> > Miguel Ángel and Russell
> >
> > Thanks for your reviews.
> >
> > Current taas function just for port monitor, in this situation, we can
> > simplify the design by just add new port type. But we have the plane 
to
> > add flow_classifier to tap_flow to monitor special flows of given 
port.
> > The flow_classifier definition may like as follow:
> > 'flow_classifiers': {
> > 'id': {'allow_post': False, 'allow_put': False,
> >'validate': {'type:uuid': None}, 'is_visible': True,
> >'primary_key': True},
> > 'tenant_id': {'allow_post': True, 'allow_put': False,
> >   'validate': {'type:string': None},
> >   'required_by_policy': True, 'is_visible': True},
> > 'name': {'allow_post': True, 'allow_put': True,
> >  'validate': {'type:string': None},
> >  'is_visible': True, 'default': ''},
> > 'description': {'allow_post': True, 'allow_put': True,
> > 'validate': {'type:string': None},
> >

[ovs-dev] 答复: Re: 答复: Re: 答复: Re: 答复: Re: [PATCH] ovn: Support for taas(tap-as-a-service) function

2017-08-07 Thread wang . qianyu

Hi Zhenyu, Ben and Russell,

Thanks for your review.
I think function of taas is independent, and have no influence with 
logical switch. Similar to logcial switch and logical router, I think 
independent function should use independent pipeline.
Here, is there some constraints or problems to add new pipeline in ovn?
Thanks.

Gao Zhenyu 
2017/08/07 15:33

收件人：wang.qia...@zte.com.cn, 
抄送：  Ben Pfaff , ovs dev , 
zhou.huij...@zte.com.cn, Miguel Angel Ajo Pelayo , 
xurong00037997 
主题：  Re: [ovs-dev] 答复: Re: 答复: Re: 答复: Re: [PATCH] ovn: 
Support for taas(tap-as-a-service) function

I think consuming a bit in reg to indicate if a packet is mirror packet or 
regular packet is doable as well. And it is easy to implement.
Other table like port_security can check if it a mirror packet and do the 
right actions(drop or forwarding to next table).

Thanks
Zhenyu Gao

2017-08-07 13:37 GMT+08:00 :
If we do not add a new type of switch, we should write flag to a reg to
indicate the matched packets which are cloned to monitor.

This reg should add to all the pipeline stages of logical switch(both
ingress and egress) to distinguish from normal flow. Is this right for
Russell's point?

If we add a new type of switch, we could define a new pipeline like bellow
for the monitor function, this have no influence on normal pipeline.

/* Logical mirror switch ingress stages. */ \
PIPELINE_STAGE(MSWITCH, IN,  MIRROR_IN,   0, "lms_in_port")   \
PIPELINE_STAGE(MSWITCH, IN,  FLOW_FILTER, 1, "lms_in_flow_filter")\
PIPELINE_STAGE(MSWITCH, IN,  OUT_LK,  2, "lms_in_out_lk") \
  \
/* Logical mirror switch egress stages. */\
PIPELINE_STAGE(MSWITCH, OUT, FLOW_FILTER, 0, "lms_out_flow_filter")\
PIPELINE_STAGE(MSWITCH, OUT, DELIVERY,1, "lms_out_delivery")

I think the new defined switch is easy to understand.

Thanks

Ben Pfaff 
2017/08/07 11:03

收件人：wang.qia...@zte.com.cn,
抄送：  Russell Bryant , ovs dev
, zhou.huij...@zte.com.cn, xurong00037997
, Miguel Angel Ajo Pelayo 
主题：  Re: [ovs-dev] 答复: Re: 答复: Re:  [PATCH] ovn: Support
for taas(tap-as-a-service) function

I am having a very hard time understanding what you're writing here.
Russell's point makes sense to me, but I don't understand your response.
Can you give some examples?

On Mon, Aug 07, 2017 at 09:40:06AM +0800, wang.qia...@zte.com.cn wrote:
> Not add new logical_mirror_switch, just use logical_switch of course can

> capture the use case. But logical_switch pipeline is complex for flow
> monitor. Flow monitor should ignore some tables such as port_security,
lb
> and so on. And also should consider normal function for normal ports. I
> think add a new type of switch and the corresponding pipeline may be
more
> clear in logical.
>
> Is there some adverse effect to add new type switch?
>
> Thanks.
>
>
>
>
> Russell Bryant 
> 2017/08/04 22:06
>
> 收件人：wang.qia...@zte.com.cn,
> 抄送：  Miguel Angel Ajo Pelayo , ovs dev
> , xurong00037997 ,
> zhou.huij...@zte.com.cn
> 主题：  Re: 答复: Re: [ovs-dev] [PATCH] ovn: Support for
> taas(tap-as-a-service) function
>
>
>
>
> On Thu, Aug 3, 2017 at 8:52 PM,  wrote:
> Miguel Ángel and Russell
>
> Thanks for your reviews.
>
> Current taas function just for port monitor, in this situation, we can
> simplify the design by just add new port type. But we have the plane to
> add flow_classifier to tap_flow to monitor special flows of given port.
> The flow_classifier definition may like as follow:
> 'flow_classifiers': {
> 'id': {'allow_post': False, 'allow_put': False,
>'validate': {'type:uuid': None}, 'is_visible': True,
>'primary_key': True},
> 'tenant_id': {'allow_post': True, 'allow_put': False,
>   'validate': {'type:string': None},
>   'required_by_policy': True, 'is_visible': True},
> 'name': {'allow_post': True, 'allow_put': True,
>  'validate': {'type:string': None},
>  'is_visible': True, 'default': ''},
> 'description': {'allow_post': True, 'allow_put': True,
> 'validate': {'type:string': None},
> 'is_visible': True, 'default': ''},
> 'protocol': {'allow_post': True, 'allow_put': True,
>  'validate': {'type:string': None},
>  'is_visible': True, 'default': ''},
> 'src_port_range_min': {'allow_post': True, 'allow_put': True,
>

[ovs-dev] 答复: Re: 答复: Re: 答复: Re: [PATCH] ovn: Support for taas(tap-as-a-service) function

2017-08-06 Thread wang . qianyu

If we do not add a new type of switch, we should write flag to a reg to 
indicate the matched packets which are cloned to monitor.

This reg should add to all the pipeline stages of logical switch(both 
ingress and egress) to distinguish from normal flow. Is this right for 
Russell's point?

If we add a new type of switch, we could define a new pipeline like bellow 
for the monitor function, this have no influence on normal pipeline.

/* Logical mirror switch ingress stages. */ \
PIPELINE_STAGE(MSWITCH, IN,  MIRROR_IN,   0, "lms_in_port")   \
PIPELINE_STAGE(MSWITCH, IN,  FLOW_FILTER, 1, "lms_in_flow_filter")\
PIPELINE_STAGE(MSWITCH, IN,  OUT_LK,  2, "lms_in_out_lk") \
  \
/* Logical mirror switch egress stages. */\
PIPELINE_STAGE(MSWITCH, OUT, FLOW_FILTER, 0, "lms_out_flow_filter")\
PIPELINE_STAGE(MSWITCH, OUT, DELIVERY,1, "lms_out_delivery")

I think the new defined switch is easy to understand.

Thanks 






Ben Pfaff 
2017/08/07 11:03
 
收件人：wang.qia...@zte.com.cn, 
抄送：  Russell Bryant , ovs dev 
, zhou.huij...@zte.com.cn, xurong00037997 
, Miguel Angel Ajo Pelayo 
主题：  Re: [ovs-dev] 答复: Re: 答复: Re:  [PATCH] ovn: Support 
for taas(tap-as-a-service) function


I am having a very hard time understanding what you're writing here.
Russell's point makes sense to me, but I don't understand your response.
Can you give some examples?

On Mon, Aug 07, 2017 at 09:40:06AM +0800, wang.qia...@zte.com.cn wrote:
> Not add new logical_mirror_switch, just use logical_switch of course can 

> capture the use case. But logical_switch pipeline is complex for flow 
> monitor. Flow monitor should ignore some tables such as port_security, 
lb 
> and so on. And also should consider normal function for normal ports. I 
> think add a new type of switch and the corresponding pipeline may be 
more 
> clear in logical.
> 
> Is there some adverse effect to add new type switch?
> 
> Thanks.
> 
> 
> 
> 
> Russell Bryant 
> 2017/08/04 22:06
> 
> 收件人：wang.qia...@zte.com.cn, 
> 抄送：  Miguel Angel Ajo Pelayo , ovs dev 
> , xurong00037997 , 
> zhou.huij...@zte.com.cn
> 主题：  Re: 答复: Re: [ovs-dev] [PATCH] ovn: Support for 
> taas(tap-as-a-service) function
> 
> 
> 
> 
> On Thu, Aug 3, 2017 at 8:52 PM,  wrote:
> Miguel Ángel and Russell 
> 
> Thanks for your reviews. 
> 
> Current taas function just for port monitor, in this situation, we can 
> simplify the design by just add new port type. But we have the plane to 
> add flow_classifier to tap_flow to monitor special flows of given port. 
> The flow_classifier definition may like as follow: 
> 'flow_classifiers': { 
> 'id': {'allow_post': False, 'allow_put': False, 
>'validate': {'type:uuid': None}, 'is_visible': True, 
>'primary_key': True}, 
> 'tenant_id': {'allow_post': True, 'allow_put': False, 
>   'validate': {'type:string': None}, 
>   'required_by_policy': True, 'is_visible': True}, 
> 'name': {'allow_post': True, 'allow_put': True, 
>  'validate': {'type:string': None}, 
>  'is_visible': True, 'default': ''}, 
> 'description': {'allow_post': True, 'allow_put': True, 
> 'validate': {'type:string': None}, 
> 'is_visible': True, 'default': ''}, 
> 'protocol': {'allow_post': True, 'allow_put': True, 
>  'validate': {'type:string': None}, 
>  'is_visible': True, 'default': ''}, 
> 'src_port_range_min': {'allow_post': True, 'allow_put': True, 
>'convert_to': attr.convert_to_int, 
>'is_visible': True, 'default': 0}, 
> 'src_port_range_max': {'allow_post': True, 'allow_put': True, 
>'convert_to': attr.convert_to_int, 
>'is_visible': True, 'default': 0}, 
> 'dst_port_range_min': {'allow_post': True, 'allow_put': True, 
>'convert_to': attr.convert_to_int, 
>'is_visible': True, 'default': 0}, 
> 'dst_port_range_max': {'allow_post': True, 'allow_put': True, 
>'convert_to': attr.convert_to_int, 
>'is_visible': True, 'default': 0}, 
> 'src_ip_prefix': {'allow_post': True, 'allow_put': True, 
>   'validate': {'type:subnet': 
> attr._validate_subnet}, 
>   'is_visible': True, 'default': '0.0.0.0/0'}, 
> 'dst_ip_prefix': {'allow_post':

[ovs-dev] 答复: Re: 答复: Re: [PATCH] ovn: Support for taas(tap-as-a-service) function

2017-08-06 Thread wang . qianyu

Not add new logical_mirror_switch, just use logical_switch of course can 
capture the use case. But logical_switch pipeline is complex for flow 
monitor. Flow monitor should ignore some tables such as port_security, lb 
and so on. And also should consider normal function for normal ports. I 
think add a new type of switch and the corresponding pipeline may be more 
clear in logical.

Is there some adverse effect to add new type switch?

Thanks.




Russell Bryant 
2017/08/04 22:06
 
收件人：wang.qia...@zte.com.cn, 
抄送：  Miguel Angel Ajo Pelayo , ovs dev 
, xurong00037997 , 
zhou.huij...@zte.com.cn
主题：  Re: 答复: Re: [ovs-dev] [PATCH] ovn: Support for 
taas(tap-as-a-service) function




On Thu, Aug 3, 2017 at 8:52 PM,  wrote:
Miguel Ángel and Russell 

Thanks for your reviews. 

Current taas function just for port monitor, in this situation, we can 
simplify the design by just add new port type. But we have the plane to 
add flow_classifier to tap_flow to monitor special flows of given port. 
The flow_classifier definition may like as follow: 
'flow_classifiers': { 
'id': {'allow_post': False, 'allow_put': False, 
   'validate': {'type:uuid': None}, 'is_visible': True, 
   'primary_key': True}, 
'tenant_id': {'allow_post': True, 'allow_put': False, 
  'validate': {'type:string': None}, 
  'required_by_policy': True, 'is_visible': True}, 
'name': {'allow_post': True, 'allow_put': True, 
 'validate': {'type:string': None}, 
 'is_visible': True, 'default': ''}, 
'description': {'allow_post': True, 'allow_put': True, 
'validate': {'type:string': None}, 
'is_visible': True, 'default': ''}, 
'protocol': {'allow_post': True, 'allow_put': True, 
 'validate': {'type:string': None}, 
 'is_visible': True, 'default': ''}, 
'src_port_range_min': {'allow_post': True, 'allow_put': True, 
   'convert_to': attr.convert_to_int, 
   'is_visible': True, 'default': 0}, 
'src_port_range_max': {'allow_post': True, 'allow_put': True, 
   'convert_to': attr.convert_to_int, 
   'is_visible': True, 'default': 0}, 
'dst_port_range_min': {'allow_post': True, 'allow_put': True, 
   'convert_to': attr.convert_to_int, 
   'is_visible': True, 'default': 0}, 
'dst_port_range_max': {'allow_post': True, 'allow_put': True, 
   'convert_to': attr.convert_to_int, 
   'is_visible': True, 'default': 0}, 
'src_ip_prefix': {'allow_post': True, 'allow_put': True, 
  'validate': {'type:subnet': 
attr._validate_subnet}, 
  'is_visible': True, 'default': '0.0.0.0/0'}, 
'dst_ip_prefix': {'allow_post': True, 'allow_put': True, 
  'validate': {'type:subnet': 
attr._validate_subnet}, 
  'is_visible': True, 'default': '0.0.0.0/0'} 
} 

This may need more complex pipeline. So I think add a new table and new 
pipeline may be a easier way. 

Thanks for sharing the info on future capabilities.

We have a very flexible syntax for traffic classification in OVN.  It's 
the logical flow match syntax (see logical flows in the southbound 
database).  We expose this syntax in the northbound database in the 
"match" column of the ACL table.

This would be another use case where we could use this syntax in the 
northbound database.  Expanding on my preview proposal:

 - a new port type of 'mirror'

 - when port type=mirror, an option to identify which port is being 
mirrored

 - (the new part) when port type=mirror, an option that may be used to 
specify traffic classification for the subset of traffic on a port to 
mirror, in "match" syntax

Do you think this captures the use case?

-- 
Russell Bryant

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

Re: [ovs-dev] [PATCH v5] ovn-controller: Refactor function of consider_port_binding

2017-08-03 Thread wang . qianyu

The function of consider_port_binding is redundant. This patch divide the 
function to some sub-function by the port type.

Signed-off-by: wang qianyu <wang.qia...@zte.com.cn>
---
 ovn/controller/physical.c | 834 
++
 1 file changed, 481 insertions(+), 353 deletions(-)

diff --git a/ovn/controller/physical.c b/ovn/controller/physical.c
index 719b020..5f52b86 100644
--- a/ovn/controller/physical.c
+++ b/ovn/controller/physical.c
@@ -291,172 +291,204 @@ load_logical_ingress_metadata(const struct 
sbrec_port_binding *binding,
 }
 
 static void
-consider_port_binding(enum mf_field_id mff_ovn_geneve,
-  const struct simap *ct_zones,
+patch_port_handle(const struct simap *ct_zones,
   const struct lport_index *lports,
-  const struct chassis_index *chassis_index,
-  struct sset *active_tunnels,
-  struct hmap *local_datapaths,
   const struct sbrec_port_binding *binding,
-  const struct sbrec_chassis *chassis,
   struct ofpbuf *ofpacts_p,
-  struct hmap *flow_table)
+  struct hmap *flow_table,
+  uint32_t dp_key,
+  uint32_t port_key)
 {
-uint32_t dp_key = binding->datapath->tunnel_key;
-uint32_t port_key = binding->tunnel_key;
-if (!get_local_datapath(local_datapaths, dp_key)) {
+const char *peer_name = smap_get(>options, "peer");
+if (!peer_name) {
 return;
 }
 
+const struct sbrec_port_binding *peer = lport_lookup_by_name(
+lports, peer_name);
+if (!peer || strcmp(peer->type, binding->type)) {
+return;
+}
+const char *peer_peer_name = smap_get(>options, "peer");
+if (!peer_peer_name || strcmp(peer_peer_name, binding->logical_port)) 
{
+return;
+}
+
+struct zone_ids binding_zones = get_zone_ids(binding, ct_zones);
+put_local_common_flows(dp_key, port_key, false, _zones,
+   ofpacts_p, flow_table);
+
 struct match match;
-if (!strcmp(binding->type, "patch")
-|| (!strcmp(binding->type, "l3gateway")
-&& binding->chassis == chassis)) {
-const char *peer_name = smap_get(>options, "peer");
-if (!peer_name) {
-return;
-}
+match_init_catchall();
+ofpbuf_clear(ofpacts_p);
+match_set_metadata(, htonll(dp_key));
+match_set_reg(, MFF_LOG_OUTPORT - MFF_REG0, port_key);
 
-const struct sbrec_port_binding *peer = lport_lookup_by_name(
-lports, peer_name);
-if (!peer || strcmp(peer->type, binding->type)) {
-return;
-}
-const char *peer_peer_name = smap_get(>options, "peer");
-if (!peer_peer_name || strcmp(peer_peer_name, 
binding->logical_port)) {
-return;
-}
+size_t clone_ofs = ofpacts_p->size;
+struct ofpact_nest *clone = ofpact_put_CLONE(ofpacts_p);
+ofpact_put_CT_CLEAR(ofpacts_p);
+put_load(0, MFF_LOG_DNAT_ZONE, 0, 32, ofpacts_p);
+put_load(0, MFF_LOG_SNAT_ZONE, 0, 32, ofpacts_p);
+put_load(0, MFF_LOG_CT_ZONE, 0, 32, ofpacts_p);
+struct zone_ids peer_zones = get_zone_ids(peer, ct_zones);
+load_logical_ingress_metadata(peer, _zones, ofpacts_p);
+put_load(0, MFF_LOG_FLAGS, 0, 32, ofpacts_p);
+put_load(0, MFF_LOG_OUTPORT, 0, 32, ofpacts_p);
+for (int i = 0; i < MFF_N_LOG_REGS; i++) {
+put_load(0, MFF_LOG_REG0 + i, 0, 32, ofpacts_p);
+}
+put_load(0, MFF_IN_PORT, 0, 16, ofpacts_p);
+put_resubmit(OFTABLE_LOG_INGRESS_PIPELINE, ofpacts_p);
+clone = ofpbuf_at_assert(ofpacts_p, clone_ofs, sizeof *clone);
+ofpacts_p->header = clone;
+ofpact_finish_CLONE(ofpacts_p, );
 
-struct zone_ids binding_zones = get_zone_ids(binding, ct_zones);
-put_local_common_flows(dp_key, port_key, false, _zones,
-   ofpacts_p, flow_table);
-
-match_init_catchall();
-ofpbuf_clear(ofpacts_p);
-match_set_metadata(, htonll(dp_key));
-match_set_reg(, MFF_LOG_OUTPORT - MFF_REG0, port_key);
-
-size_t clone_ofs = ofpacts_p->size;
-struct ofpact_nest *clone = ofpact_put_CLONE(ofpacts_p);
-ofpact_put_CT_CLEAR(ofpacts_p);
-put_load(0, MFF_LOG_DNAT_ZONE, 0, 32, ofpacts_p);
-put_load(0, MFF_LOG_SNAT_ZONE, 0, 32, ofpacts_p);
-put_load(0, MFF_LOG_CT_ZONE, 0, 32, ofpacts_p);
-struct zone_ids peer_zones = get_zone_ids(peer, ct_zones);
-load_logical_ingress_metadata(peer, _zones, ofpacts_p);
-put_load(0, MFF_LOG_FLAGS, 0, 32, ofpacts_p);
-put_load(0, MFF_LOG_OUTPORT, 0, 32, ofpacts_p);
-for (int i = 0; i < MFF_N_LOG_REGS; i++) {
-

[ovs-dev] [PATCH v4] ovn-controller: Refactor function of consider_port_binding

2017-08-03 Thread wang . qianyu

The function of consider_port_binding is redundant. This patch divide the 
function to some sub-function by the port type.

Signed-off-by: wang qianyu <wang.qia...@zte.com.cn>
---
 ovn/controller/physical.c | 816 
+++---
 1 file changed, 482 insertions(+), 334 deletions(-)

diff --git a/ovn/controller/physical.c b/ovn/controller/physical.c
index 719b020..48b6165 100644
--- a/ovn/controller/physical.c
+++ b/ovn/controller/physical.c
@@ -291,144 +291,200 @@ load_logical_ingress_metadata(const struct 
sbrec_port_binding *binding,
 }
 
 static void
-consider_port_binding(enum mf_field_id mff_ovn_geneve,
-  const struct simap *ct_zones,
+patch_port_handle(const struct simap *ct_zones,
   const struct lport_index *lports,
-  const struct chassis_index *chassis_index,
-  struct sset *active_tunnels,
-  struct hmap *local_datapaths,
   const struct sbrec_port_binding *binding,
-  const struct sbrec_chassis *chassis,
   struct ofpbuf *ofpacts_p,
-  struct hmap *flow_table)
+  struct hmap *flow_table,
+  uint32_t dp_key,
+  uint32_t port_key)
 {
-uint32_t dp_key = binding->datapath->tunnel_key;
-uint32_t port_key = binding->tunnel_key;
-if (!get_local_datapath(local_datapaths, dp_key)) {
+const char *peer_name = smap_get(>options, "peer");
+if (!peer_name) {
+return;
+}
+
+const struct sbrec_port_binding *peer = lport_lookup_by_name(
+lports, peer_name);
+if (!peer || strcmp(peer->type, binding->type)) {
+return;
+}
+const char *peer_peer_name = smap_get(>options, "peer");
+if (!peer_peer_name || strcmp(peer_peer_name, binding->logical_port)) 
{
 return;
 }
 
+struct zone_ids binding_zones = get_zone_ids(binding, ct_zones);
+put_local_common_flows(dp_key, port_key, false, _zones,
+   ofpacts_p, flow_table);
+
 struct match match;
-if (!strcmp(binding->type, "patch")
-|| (!strcmp(binding->type, "l3gateway")
-&& binding->chassis == chassis)) {
-const char *peer_name = smap_get(>options, "peer");
-if (!peer_name) {
-return;
-}
+match_init_catchall();
+ofpbuf_clear(ofpacts_p);
+match_set_metadata(, htonll(dp_key));
+match_set_reg(, MFF_LOG_OUTPORT - MFF_REG0, port_key);
 
-const struct sbrec_port_binding *peer = lport_lookup_by_name(
-lports, peer_name);
-if (!peer || strcmp(peer->type, binding->type)) {
-return;
-}
-const char *peer_peer_name = smap_get(>options, "peer");
-if (!peer_peer_name || strcmp(peer_peer_name, 
binding->logical_port)) {
-return;
-}
+size_t clone_ofs = ofpacts_p->size;
+struct ofpact_nest *clone = ofpact_put_CLONE(ofpacts_p);
+ofpact_put_CT_CLEAR(ofpacts_p);
+put_load(0, MFF_LOG_DNAT_ZONE, 0, 32, ofpacts_p);
+put_load(0, MFF_LOG_SNAT_ZONE, 0, 32, ofpacts_p);
+put_load(0, MFF_LOG_CT_ZONE, 0, 32, ofpacts_p);
+struct zone_ids peer_zones = get_zone_ids(peer, ct_zones);
+load_logical_ingress_metadata(peer, _zones, ofpacts_p);
+put_load(0, MFF_LOG_FLAGS, 0, 32, ofpacts_p);
+put_load(0, MFF_LOG_OUTPORT, 0, 32, ofpacts_p);
+for (int i = 0; i < MFF_N_LOG_REGS; i++) {
+put_load(0, MFF_LOG_REG0 + i, 0, 32, ofpacts_p);
+}
+put_load(0, MFF_IN_PORT, 0, 16, ofpacts_p);
+put_resubmit(OFTABLE_LOG_INGRESS_PIPELINE, ofpacts_p);
+clone = ofpbuf_at_assert(ofpacts_p, clone_ofs, sizeof *clone);
+ofpacts_p->header = clone;
+ofpact_finish_CLONE(ofpacts_p, );
 
-struct zone_ids binding_zones = get_zone_ids(binding, ct_zones);
-put_local_common_flows(dp_key, port_key, false, _zones,
-   ofpacts_p, flow_table);
-
-match_init_catchall();
-ofpbuf_clear(ofpacts_p);
-match_set_metadata(, htonll(dp_key));
-match_set_reg(, MFF_LOG_OUTPORT - MFF_REG0, port_key);
-
-size_t clone_ofs = ofpacts_p->size;
-struct ofpact_nest *clone = ofpact_put_CLONE(ofpacts_p);
-ofpact_put_CT_CLEAR(ofpacts_p);
-put_load(0, MFF_LOG_DNAT_ZONE, 0, 32, ofpacts_p);
-put_load(0, MFF_LOG_SNAT_ZONE, 0, 32, ofpacts_p);
-put_load(0, MFF_LOG_CT_ZONE, 0, 32, ofpacts_p);
-struct zone_ids peer_zones = get_zone_ids(peer, ct_zones);
-load_logical_ingress_metadata(peer, _zones, ofpacts_p);
-put_load(0, MFF_LOG_FLAGS, 0, 32, ofpacts_p);
-put_load(0, MFF_LOG_OUTPORT, 0, 32, ofpacts_p);
-for (int i = 0; i < MFF_N_LOG_REGS; i++) {
-

[ovs-dev] [PATCH v2] ovn-controller: Refactor function of consider_port_binding

2017-08-03 Thread wang . qianyu

The function of consider_port_binding is redundant. This patch divide the 
function to some sub-function by the port type.

Signed-off-by: wang qianyu <wang.qia...@zte.com.cn>
---
 ovn/controller/physical.c | 816 
+++---
 1 file changed, 482 insertions(+), 334 deletions(-)

diff --git a/ovn/controller/physical.c b/ovn/controller/physical.c
index 719b020..48b6165 100644
--- a/ovn/controller/physical.c
+++ b/ovn/controller/physical.c
@@ -291,144 +291,200 @@ load_logical_ingress_metadata(const struct 
sbrec_port_binding *binding,
 }
 
 static void
-consider_port_binding(enum mf_field_id mff_ovn_geneve,
-  const struct simap *ct_zones,
+patch_port_handle(const struct simap *ct_zones,
   const struct lport_index *lports,
-  const struct chassis_index *chassis_index,
-  struct sset *active_tunnels,
-  struct hmap *local_datapaths,
   const struct sbrec_port_binding *binding,
-  const struct sbrec_chassis *chassis,
   struct ofpbuf *ofpacts_p,
-  struct hmap *flow_table)
+  struct hmap *flow_table,
+  uint32_t dp_key,
+  uint32_t port_key)
 {
-uint32_t dp_key = binding->datapath->tunnel_key;
-uint32_t port_key = binding->tunnel_key;
-if (!get_local_datapath(local_datapaths, dp_key)) {
+const char *peer_name = smap_get(>options, "peer");
+if (!peer_name) {
+return;
+}
+
+const struct sbrec_port_binding *peer = lport_lookup_by_name(
+lports, peer_name);
+if (!peer || strcmp(peer->type, binding->type)) {
+return;
+}
+const char *peer_peer_name = smap_get(>options, "peer");
+if (!peer_peer_name || strcmp(peer_peer_name, binding->logical_port)) 
{
 return;
 }
 
+struct zone_ids binding_zones = get_zone_ids(binding, ct_zones);
+put_local_common_flows(dp_key, port_key, false, _zones,
+   ofpacts_p, flow_table);
+
 struct match match;
-if (!strcmp(binding->type, "patch")
-|| (!strcmp(binding->type, "l3gateway")
-&& binding->chassis == chassis)) {
-const char *peer_name = smap_get(>options, "peer");
-if (!peer_name) {
-return;
-}
+match_init_catchall();
+ofpbuf_clear(ofpacts_p);
+match_set_metadata(, htonll(dp_key));
+match_set_reg(, MFF_LOG_OUTPORT - MFF_REG0, port_key);
 
-const struct sbrec_port_binding *peer = lport_lookup_by_name(
-lports, peer_name);
-if (!peer || strcmp(peer->type, binding->type)) {
-return;
-}
-const char *peer_peer_name = smap_get(>options, "peer");
-if (!peer_peer_name || strcmp(peer_peer_name, 
binding->logical_port)) {
-return;
-}
+size_t clone_ofs = ofpacts_p->size;
+struct ofpact_nest *clone = ofpact_put_CLONE(ofpacts_p);
+ofpact_put_CT_CLEAR(ofpacts_p);
+put_load(0, MFF_LOG_DNAT_ZONE, 0, 32, ofpacts_p);
+put_load(0, MFF_LOG_SNAT_ZONE, 0, 32, ofpacts_p);
+put_load(0, MFF_LOG_CT_ZONE, 0, 32, ofpacts_p);
+struct zone_ids peer_zones = get_zone_ids(peer, ct_zones);
+load_logical_ingress_metadata(peer, _zones, ofpacts_p);
+put_load(0, MFF_LOG_FLAGS, 0, 32, ofpacts_p);
+put_load(0, MFF_LOG_OUTPORT, 0, 32, ofpacts_p);
+for (int i = 0; i < MFF_N_LOG_REGS; i++) {
+put_load(0, MFF_LOG_REG0 + i, 0, 32, ofpacts_p);
+}
+put_load(0, MFF_IN_PORT, 0, 16, ofpacts_p);
+put_resubmit(OFTABLE_LOG_INGRESS_PIPELINE, ofpacts_p);
+clone = ofpbuf_at_assert(ofpacts_p, clone_ofs, sizeof *clone);
+ofpacts_p->header = clone;
+ofpact_finish_CLONE(ofpacts_p, );
 
-struct zone_ids binding_zones = get_zone_ids(binding, ct_zones);
-put_local_common_flows(dp_key, port_key, false, _zones,
-   ofpacts_p, flow_table);
-
-match_init_catchall();
-ofpbuf_clear(ofpacts_p);
-match_set_metadata(, htonll(dp_key));
-match_set_reg(, MFF_LOG_OUTPORT - MFF_REG0, port_key);
-
-size_t clone_ofs = ofpacts_p->size;
-struct ofpact_nest *clone = ofpact_put_CLONE(ofpacts_p);
-ofpact_put_CT_CLEAR(ofpacts_p);
-put_load(0, MFF_LOG_DNAT_ZONE, 0, 32, ofpacts_p);
-put_load(0, MFF_LOG_SNAT_ZONE, 0, 32, ofpacts_p);
-put_load(0, MFF_LOG_CT_ZONE, 0, 32, ofpacts_p);
-struct zone_ids peer_zones = get_zone_ids(peer, ct_zones);
-load_logical_ingress_metadata(peer, _zones, ofpacts_p);
-put_load(0, MFF_LOG_FLAGS, 0, 32, ofpacts_p);
-put_load(0, MFF_LOG_OUTPORT, 0, 32, ofpacts_p);
-for (int i = 0; i < MFF_N_LOG_REGS; i++) {
-

[ovs-dev] [PATCH] ovn-controller: Refactor function of consider_port_binding

2017-08-03 Thread wang . qianyu

The function of consider_port_binding is redundant. This patch split the 
function to some sub-function by the port type.

Signed-off-by: wang qianyu <wang.qia...@zte.com.cn>
---
 ovn/controller/physical.c | 816 
+++---
 1 file changed, 482 insertions(+), 334 deletions(-)

diff --git a/ovn/controller/physical.c b/ovn/controller/physical.c
index 719b020..48b6165 100644
--- a/ovn/controller/physical.c
+++ b/ovn/controller/physical.c
@@ -291,144 +291,200 @@ load_logical_ingress_metadata(const struct 
sbrec_port_binding *binding,
 }
 
 static void
-consider_port_binding(enum mf_field_id mff_ovn_geneve,
-  const struct simap *ct_zones,
+patch_port_handle(const struct simap *ct_zones,
   const struct lport_index *lports,
-  const struct chassis_index *chassis_index,
-  struct sset *active_tunnels,
-  struct hmap *local_datapaths,
   const struct sbrec_port_binding *binding,
-  const struct sbrec_chassis *chassis,
   struct ofpbuf *ofpacts_p,
-  struct hmap *flow_table)
+  struct hmap *flow_table,
+  uint32_t dp_key,
+  uint32_t port_key)
 {
-uint32_t dp_key = binding->datapath->tunnel_key;
-uint32_t port_key = binding->tunnel_key;
-if (!get_local_datapath(local_datapaths, dp_key)) {
+const char *peer_name = smap_get(>options, "peer");
+if (!peer_name) {
+return;
+}
+
+const struct sbrec_port_binding *peer = lport_lookup_by_name(
+lports, peer_name);
+if (!peer || strcmp(peer->type, binding->type)) {
+return;
+}
+const char *peer_peer_name = smap_get(>options, "peer");
+if (!peer_peer_name || strcmp(peer_peer_name, binding->logical_port)) 
{
 return;
 }
 
+struct zone_ids binding_zones = get_zone_ids(binding, ct_zones);
+put_local_common_flows(dp_key, port_key, false, _zones,
+   ofpacts_p, flow_table);
+
 struct match match;
-if (!strcmp(binding->type, "patch")
-|| (!strcmp(binding->type, "l3gateway")
-&& binding->chassis == chassis)) {
-const char *peer_name = smap_get(>options, "peer");
-if (!peer_name) {
-return;
-}
+match_init_catchall();
+ofpbuf_clear(ofpacts_p);
+match_set_metadata(, htonll(dp_key));
+match_set_reg(, MFF_LOG_OUTPORT - MFF_REG0, port_key);
 
-const struct sbrec_port_binding *peer = lport_lookup_by_name(
-lports, peer_name);
-if (!peer || strcmp(peer->type, binding->type)) {
-return;
-}
-const char *peer_peer_name = smap_get(>options, "peer");
-if (!peer_peer_name || strcmp(peer_peer_name, 
binding->logical_port)) {
-return;
-}
+size_t clone_ofs = ofpacts_p->size;
+struct ofpact_nest *clone = ofpact_put_CLONE(ofpacts_p);
+ofpact_put_CT_CLEAR(ofpacts_p);
+put_load(0, MFF_LOG_DNAT_ZONE, 0, 32, ofpacts_p);
+put_load(0, MFF_LOG_SNAT_ZONE, 0, 32, ofpacts_p);
+put_load(0, MFF_LOG_CT_ZONE, 0, 32, ofpacts_p);
+struct zone_ids peer_zones = get_zone_ids(peer, ct_zones);
+load_logical_ingress_metadata(peer, _zones, ofpacts_p);
+put_load(0, MFF_LOG_FLAGS, 0, 32, ofpacts_p);
+put_load(0, MFF_LOG_OUTPORT, 0, 32, ofpacts_p);
+for (int i = 0; i < MFF_N_LOG_REGS; i++) {
+put_load(0, MFF_LOG_REG0 + i, 0, 32, ofpacts_p);
+}
+put_load(0, MFF_IN_PORT, 0, 16, ofpacts_p);
+put_resubmit(OFTABLE_LOG_INGRESS_PIPELINE, ofpacts_p);
+clone = ofpbuf_at_assert(ofpacts_p, clone_ofs, sizeof *clone);
+ofpacts_p->header = clone;
+ofpact_finish_CLONE(ofpacts_p, );
 
-struct zone_ids binding_zones = get_zone_ids(binding, ct_zones);
-put_local_common_flows(dp_key, port_key, false, _zones,
-   ofpacts_p, flow_table);
-
-match_init_catchall();
-ofpbuf_clear(ofpacts_p);
-match_set_metadata(, htonll(dp_key));
-match_set_reg(, MFF_LOG_OUTPORT - MFF_REG0, port_key);
-
-size_t clone_ofs = ofpacts_p->size;
-struct ofpact_nest *clone = ofpact_put_CLONE(ofpacts_p);
-ofpact_put_CT_CLEAR(ofpacts_p);
-put_load(0, MFF_LOG_DNAT_ZONE, 0, 32, ofpacts_p);
-put_load(0, MFF_LOG_SNAT_ZONE, 0, 32, ofpacts_p);
-put_load(0, MFF_LOG_CT_ZONE, 0, 32, ofpacts_p);
-struct zone_ids peer_zones = get_zone_ids(peer, ct_zones);
-load_logical_ingress_metadata(peer, _zones, ofpacts_p);
-put_load(0, MFF_LOG_FLAGS, 0, 32, ofpacts_p);
-put_load(0, MFF_LOG_OUTPORT, 0, 32, ofpacts_p);
-for (int i = 0; i < MFF_N_LOG_REGS; i++) {
-

[ovs-dev] 答复: Re: [PATCH] ovn-controller: Refactor function of consider_port_binding

2017-08-03 Thread wang . qianyu

The reason of this patch cannot be applied may be the character of 
"0xfeff" at begin of the file. I will delete the character and post again.

Thanks

Ben Pfaff <b...@ovn.org>
2017/08/04 04:23

收件人：wang.qia...@zte.com.cn, 
抄送：  d...@openvswitch.org, zhou.huij...@zte.com.cn, 
xu.r...@zte.com.cn
主题：  Re: [ovs-dev] [PATCH] ovn-controller: Refactor function of 
consider_port_binding

On Fri, Jul 28, 2017 at 11:32:29AM +0800, wang.qia...@zte.com.cn wrote:
> The function of consider_port_binding is redundant. This patch divide 
the 
> function to some sub-function by the port type.
> 
> Change-Id: I86a408e97e6d6211f3695cf42fc5b858352ac7ff
> Signed-off-by: wang qianyu <wang.qia...@zte.com.cn>

Thank you for the contribution.

This patch is word-wrapped and cannot be applied.  Can you re-post it,
please?  "git send-email" always works properly.  Or you can use a
github pull request if that can't work.

Thanks,

Ben.

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

[ovs-dev] 答复: Re: [PATCH] ovn: Support for taas(tap-as-a-service) function

2017-08-03 Thread wang . qianyu

Miguel Ángel and Russell

Thanks for your reviews.

Current taas function just for port monitor, in this situation, we can 
simplify the design by just add new port type. But we have the plane to 
add flow_classifier to tap_flow to monitor special flows of given port. 
The flow_classifier definition may like as follow:
'flow_classifiers': {
'id': {'allow_post': False, 'allow_put': False,
   'validate': {'type:uuid': None}, 'is_visible': True,
   'primary_key': True},
'tenant_id': {'allow_post': True, 'allow_put': False,
  'validate': {'type:string': None},
  'required_by_policy': True, 'is_visible': True},
'name': {'allow_post': True, 'allow_put': True,
 'validate': {'type:string': None},
 'is_visible': True, 'default': ''},
'description': {'allow_post': True, 'allow_put': True,
'validate': {'type:string': None},
'is_visible': True, 'default': ''},
'protocol': {'allow_post': True, 'allow_put': True,
 'validate': {'type:string': None},
 'is_visible': True, 'default': ''},
'src_port_range_min': {'allow_post': True, 'allow_put': True,
   'convert_to': attr.convert_to_int,
   'is_visible': True, 'default': 0},
'src_port_range_max': {'allow_post': True, 'allow_put': True,
   'convert_to': attr.convert_to_int,
   'is_visible': True, 'default': 0},
'dst_port_range_min': {'allow_post': True, 'allow_put': True,
   'convert_to': attr.convert_to_int,
   'is_visible': True, 'default': 0},
'dst_port_range_max': {'allow_post': True, 'allow_put': True,
   'convert_to': attr.convert_to_int,
   'is_visible': True, 'default': 0},
'src_ip_prefix': {'allow_post': True, 'allow_put': True,
  'validate': {'type:subnet': 
attr._validate_subnet},
  'is_visible': True, 'default': '0.0.0.0/0'},
'dst_ip_prefix': {'allow_post': True, 'allow_put': True,
  'validate': {'type:subnet': 
attr._validate_subnet},
  'is_visible': True, 'default': '0.0.0.0/0'}
} 

This may need more complex pipeline. So I think add a new table and new 
pipeline may be a easier way.

Thanks.

Miguel Angel Ajo Pelayo <majop...@redhat.com>
2017/08/03 23:21

收件人：Russell Bryant <russ...@ovn.org>, 
抄送：  wang.qia...@zte.com.cn, ovs dev <d...@openvswitch.org>, 
zhou.huij...@zte.com.cn, xurong00037997 <xu.r...@zte.com.cn>
主题：  Re: [ovs-dev] [PATCH] ovn: Support for 
taas(tap-as-a-service) function

I had the same thought about the tables.

Regards,
Miguel Ángel

On Thu, Aug 3, 2017 at 5:11 PM, Russell Bryant <russ...@ovn.org> wrote:
On Thu, Aug 3, 2017 at 4:44 AM,  <wang.qia...@zte.com.cn> wrote:
> Taas was designed to provide tenants and service providers a means of
> monitoring the traffic flowing in their Neutron provisioned virtual
> networks. It is useful for network trouble-shooting, security and
> analytics. The taas presentations could be found from
> 
https://github.com/openstack/tap-as-a-service/blob/master/doc/source/presentations.rst

> , and the api reference could be found from
> 
https://github.com/openstack/tap-as-a-service/blob/master/API_REFERENCE.rst

>
> To support taas function, this patch add a new logical switch
> "logica_mirror_switch" which represents a taas_service in ovn.
> This patch also add logica_mirror_switch_port with type of "mirror" and
> "taas". port with type "mirror" is used as inport for monitor flow in
> logica_mirror_switch, and port with type "taas" is used as outport for
> monitor flow in logica_mirror_switch.
>
> The ovn-controller will make the relation between the 
logical_switch_port
> and logica_mirror_switch_port.
>
> Signed-off-by: wang qianyu <wang.qia...@zte.com.cn>
> ---
>  ovn/controller/binding.c|  11 +-
>  ovn/controller/ovn-controller.c |   4 +-
>  ovn/controller/physical.c   | 125 +++-
>  ovn/northd/ovn-northd.c | 317
> 
>  ovn/ovn-nb.ovsschema|  42 +-
>  ovn/ovn-nb.xml  | 167 +
>  ovn/ovn-sb.xml  |  85 ++-
>  ovn/utilities/ovn-nbctl.c   | 152 ++-
>  ovn/utilities/ovn-trace.c   |   5 +-
>  9 files changed, 865 insertions(+), 43 deletions(-)

Thanks for working on the new feature!

The first thing that stands out to me is the new tables

[ovs-dev] [PATCH] ovn: Support for taas(tap-as-a-service) function

2017-08-03 Thread wang . qianyu

Taas was designed to provide tenants and service providers a means of 
monitoring the traffic flowing in their Neutron provisioned virtual 
networks. It is useful for network trouble-shooting, security and 
analytics. The taas presentations could be found from 
https://github.com/openstack/tap-as-a-service/blob/master/doc/source/presentations.rst
, and the api reference could be found from 
https://github.com/openstack/tap-as-a-service/blob/master/API_REFERENCE.rst

To support taas function, this patch add a new logical switch 
"logica_mirror_switch" which represents a taas_service in ovn.
This patch also add logica_mirror_switch_port with type of "mirror" and 
"taas". port with type "mirror" is used as inport for monitor flow in 
logica_mirror_switch, and port with type "taas" is used as outport for 
monitor flow in logica_mirror_switch.

The ovn-controller will make the relation between the logical_switch_port 
and logica_mirror_switch_port.

Signed-off-by: wang qianyu <wang.qia...@zte.com.cn>
---
 ovn/controller/binding.c|  11 +-
 ovn/controller/ovn-controller.c |   4 +-
 ovn/controller/physical.c   | 125 +++-
 ovn/northd/ovn-northd.c | 317 

 ovn/ovn-nb.ovsschema|  42 +-
 ovn/ovn-nb.xml  | 167 +
 ovn/ovn-sb.xml  |  85 ++-
 ovn/utilities/ovn-nbctl.c   | 152 ++-
 ovn/utilities/ovn-trace.c   |   5 +-
 9 files changed, 865 insertions(+), 43 deletions(-)

diff --git a/ovn/controller/binding.c b/ovn/controller/binding.c
index a80671a..70b33f4 100644
--- a/ovn/controller/binding.c
+++ b/ovn/controller/binding.c
@@ -1,4 +1,4 @@
-/* Copyright (c) 2015, 2016, 2017 Nicira, Inc.
+/* Copyright (c) 2015, 2016, 2017 Nicira, Inc.
  *
  * Licensed under the Apache License, Version 2.0 (the "License");
  * you may not use this file except in compliance with the License.
@@ -432,6 +432,15 @@ consider_local_datapath(struct controller_ctx *ctx,
  * for them. */
 sset_add(local_lports, binding_rec->logical_port);
 our_chassis = false;
+} else if (!strcmp(binding_rec->type, "mirror") ||
+   !strcmp(binding_rec->type, "taas")) {
+const char *chassis_id = smap_get(_rec->options,
+  "taas-chassis");
+our_chassis = chassis_id && !strcmp(chassis_id, 
chassis_rec->name);
+
+//sset_add(local_lports, binding_rec->logical_port);
+add_local_datapath(ldatapaths, lports, binding_rec->datapath,
+   false, local_datapaths);
 }
 
 if (ctx->ovnsb_idl_txn) {
diff --git a/ovn/controller/ovn-controller.c 
b/ovn/controller/ovn-controller.c
index da3e83a..31fd411 100644
--- a/ovn/controller/ovn-controller.c
+++ b/ovn/controller/ovn-controller.c
@@ -1,4 +1,4 @@
-/* Copyright (c) 2015, 2016, 2017 Nicira, Inc.
+/* Copyright (c) 2015, 2016, 2017 Nicira, Inc.
  *
  * Licensed under the Apache License, Version 2.0 (the "License");
  * you may not use this file except in compliance with the License.
@@ -150,6 +150,8 @@ update_sb_monitors(struct ovsdb_idl *ovnsb_idl,
 struct ovsdb_idl_condition mg = OVSDB_IDL_CONDITION_INIT();
 struct ovsdb_idl_condition dns = OVSDB_IDL_CONDITION_INIT();
 sbrec_port_binding_add_clause_type(, OVSDB_F_EQ, "patch");
+sbrec_port_binding_add_clause_type(, OVSDB_F_EQ, "mirror");
+sbrec_port_binding_add_clause_type(, OVSDB_F_EQ, "taas");
 /* XXX: We can optimize this, if we find a way to only monitor
  * ports that have a Gateway_Chassis that point's to our own
  * chassis */
diff --git a/ovn/controller/physical.c b/ovn/controller/physical.c
index 719b020..dfe2a05 100644
--- a/ovn/controller/physical.c
+++ b/ovn/controller/physical.c
@@ -1,4 +1,4 @@
-/* Copyright (c) 2015, 2016, 2017 Nicira, Inc.
+/* Copyright (c) 2015, 2016, 2017 Nicira, Inc.
  *
  * Licensed under the Apache License, Version 2.0 (the "License");
  * you may not use this file except in compliance with the License.
@@ -291,6 +291,59 @@ load_logical_ingress_metadata(const struct 
sbrec_port_binding *binding,
 }
 
 static void
+taas_port_handle(const struct simap *ct_zones,
+ const struct lport_index *lports,
+ const struct sbrec_port_binding *binding,
+ struct ofpbuf *ofpacts_p,
+ struct hmap *flow_table,
+ uint32_t dp_key,
+ uint32_t port_key)
+{
+if (strlen(binding->logical_port) < strlen("taas-")) {
+VLOG_INFO("logical_port is %s len lt taas-", 
binding->logical_port);
+return;
+}
+
+char *logical_port_name = binding->logical_port + strlen("taas-");
+const struct sbrec

[ovs-dev] 答复: Re: [PATCH 1/2] ovn-controller: fix vlan_trunk bug

2017-08-02 Thread wang . qianyu

ok




Ben Pfaff 
2017/08/03 04:38
 
收件人：wang.qia...@zte.com.cn, 
抄送：  d...@openvswitch.org
主题：  Re: [ovs-dev]  [PATCH 1/2] ovn-controller: fix vlan_trunk 
bug


On Fri, Jul 14, 2017 at 10:24:17AM +0800, wang.qia...@zte.com.cn wrote:
> The bug description is as follow:
> 
> Neutron configure a trunk-sub port. The parent-port and sub-port located 

> in different network. there is a vm attached to parent port. And no vm 
> attached to the network of sub-port in the same chassis. In this 
> situation, the ovn-controller can not get the configuration info of 
> sub-port.
> 
> The reason is that ovn-controller does not monitor the port-binding with 

> parent.
> 
> This patch fix this bug.
> 
> Change-Id: I0ce3f5b1b5a9e81608ecc587a796998520a8da47
> Signed-off-by: 10110202 

I took the liberty of fixing the Signed-off-by line, and then applied
this to master and branch-2.7.


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

[ovs-dev] [PATCH] ovn-controller: Refactor function of consider_port_binding

2017-07-27 Thread wang . qianyu

The function of consider_port_binding is redundant. This patch divide the 
function to some sub-function by the port type.

Change-Id: I86a408e97e6d6211f3695cf42fc5b858352ac7ff
Signed-off-by: wang qianyu <wang.qia...@zte.com.cn>
---
 ovn/controller/physical.c | 819 
+++---
 1 file changed, 484 insertions(+), 335 deletions(-)

diff --git a/ovn/controller/physical.c b/ovn/controller/physical.c
index 719b020..28dcd5e 100644
--- a/ovn/controller/physical.c
+++ b/ovn/controller/physical.c
@@ -1,4 +1,4 @@
-/* Copyright (c) 2015, 2016, 2017 Nicira, Inc.
+锘?* Copyright (c) 2015, 2016, 2017 Nicira, Inc.
  *
  * Licensed under the Apache License, Version 2.0 (the "License");
  * you may not use this file except in compliance with the License.
@@ -291,144 +291,200 @@ load_logical_ingress_metadata(const struct 
sbrec_port_binding *binding,
 }
 
 static void
-consider_port_binding(enum mf_field_id mff_ovn_geneve,
-  const struct simap *ct_zones,
+patch_port_handle(const struct simap *ct_zones,
   const struct lport_index *lports,
-  const struct chassis_index *chassis_index,
-  struct sset *active_tunnels,
-  struct hmap *local_datapaths,
   const struct sbrec_port_binding *binding,
-  const struct sbrec_chassis *chassis,
   struct ofpbuf *ofpacts_p,
-  struct hmap *flow_table)
+  struct hmap *flow_table,
+  uint32_t dp_key,
+  uint32_t port_key)
 {
-uint32_t dp_key = binding->datapath->tunnel_key;
-uint32_t port_key = binding->tunnel_key;
-if (!get_local_datapath(local_datapaths, dp_key)) {
+const char *peer_name = smap_get(>options, "peer");
+if (!peer_name) {
+return;
+}
+
+const struct sbrec_port_binding *peer = lport_lookup_by_name(
+lports, peer_name);
+if (!peer || strcmp(peer->type, binding->type)) {
+return;
+}
+const char *peer_peer_name = smap_get(>options, "peer");
+if (!peer_peer_name || strcmp(peer_peer_name, binding->logical_port)) 
{
 return;
 }
 
+struct zone_ids binding_zones = get_zone_ids(binding, ct_zones);
+put_local_common_flows(dp_key, port_key, false, _zones,
+   ofpacts_p, flow_table);
+
 struct match match;
-if (!strcmp(binding->type, "patch")
-|| (!strcmp(binding->type, "l3gateway")
-&& binding->chassis == chassis)) {
-const char *peer_name = smap_get(>options, "peer");
-if (!peer_name) {
-return;
-}
+match_init_catchall();
+ofpbuf_clear(ofpacts_p);
+match_set_metadata(, htonll(dp_key));
+match_set_reg(, MFF_LOG_OUTPORT - MFF_REG0, port_key);
 
-const struct sbrec_port_binding *peer = lport_lookup_by_name(
-lports, peer_name);
-if (!peer || strcmp(peer->type, binding->type)) {
-return;
-}
-const char *peer_peer_name = smap_get(>options, "peer");
-if (!peer_peer_name || strcmp(peer_peer_name, 
binding->logical_port)) {
-return;
-}
+size_t clone_ofs = ofpacts_p->size;
+struct ofpact_nest *clone = ofpact_put_CLONE(ofpacts_p);
+ofpact_put_CT_CLEAR(ofpacts_p);
+put_load(0, MFF_LOG_DNAT_ZONE, 0, 32, ofpacts_p);
+put_load(0, MFF_LOG_SNAT_ZONE, 0, 32, ofpacts_p);
+put_load(0, MFF_LOG_CT_ZONE, 0, 32, ofpacts_p);
+struct zone_ids peer_zones = get_zone_ids(peer, ct_zones);
+load_logical_ingress_metadata(peer, _zones, ofpacts_p);
+put_load(0, MFF_LOG_FLAGS, 0, 32, ofpacts_p);
+put_load(0, MFF_LOG_OUTPORT, 0, 32, ofpacts_p);
+for (int i = 0; i < MFF_N_LOG_REGS; i++) {
+put_load(0, MFF_LOG_REG0 + i, 0, 32, ofpacts_p);
+}
+put_load(0, MFF_IN_PORT, 0, 16, ofpacts_p);
+put_resubmit(OFTABLE_LOG_INGRESS_PIPELINE, ofpacts_p);
+clone = ofpbuf_at_assert(ofpacts_p, clone_ofs, sizeof *clone);
+ofpacts_p->header = clone;
+ofpact_finish_CLONE(ofpacts_p, );
 
-struct zone_ids binding_zones = get_zone_ids(binding, ct_zones);
-put_local_common_flows(dp_key, port_key, false, _zones,
-   ofpacts_p, flow_table);
-
-match_init_catchall();
-ofpbuf_clear(ofpacts_p);
-match_set_metadata(, htonll(dp_key));
-match_set_reg(, MFF_LOG_OUTPORT - MFF_REG0, port_key);
-
-size_t clone_ofs = ofpacts_p->size;
-struct ofpact_nest *clone = ofpact_put_CLONE(ofpacts_p);
-ofpact_put_CT_CLEAR(ofpacts_p);
-put_load(0, MFF_LOG_DNAT_ZONE, 0, 32, ofpacts_p);
-put_load(0, MFF_LOG_SNAT_ZONE, 0, 32, ofpacts_p);
-put_load(0, MFF_LOG_CT_ZONE, 0, 32, ofpacts_p);
-

[ovs-dev] [PATCH 1/2] ovn-controller: fix vlan_trunk bug

2017-07-13 Thread wang . qianyu

The bug description is as follow:

Neutron configure a trunk-sub port. The parent-port and sub-port located 
in different network. there is a vm attached to parent port. And no vm 
attached to the network of sub-port in the same chassis. In this 
situation, the ovn-controller can not get the configuration info of 
sub-port.

The reason is that ovn-controller does not monitor the port-binding with 
parent.

This patch fix this bug.

Change-Id: I0ce3f5b1b5a9e81608ecc587a796998520a8da47
Signed-off-by: 10110202 
---
 ovn/controller/ovn-controller.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/ovn/controller/ovn-controller.c 
b/ovn/controller/ovn-controller.c
index 00b4cda..4406f00 100644
--- a/ovn/controller/ovn-controller.c
+++ b/ovn/controller/ovn-controller.c
@@ -174,6 +174,7 @@ update_sb_monitors(struct ovsdb_idl *ovnsb_idl,
 const char *name;
 SSET_FOR_EACH (name, local_ifaces) {
 sbrec_port_binding_add_clause_logical_port(, OVSDB_F_EQ, 
name);
+sbrec_port_binding_add_clause_parent_port(, OVSDB_F_EQ, 
name);
 }
 }
 if (local_datapaths) {
-- 
1.8.3.1

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

[ovs-dev] [PATCH 2/2] ovn-controller: fix vlan_trunk bug

2017-07-13 Thread wang . qianyu

The bug description is as follow:

Neutron configure a trunk-sub port. The parent-port and sub-port located 
in different network. there is a vm attached to parent port. And no vm 
attached to the network of sub-port in the same chassis. In this 
situation, the ovn-controller can not get the configuration info of 
sub-port.

The reason is that ovn-controller does not monitor the port-binding with 
parent.

This patch fix this bug.

Change-Id: I0ce3f5b1b5a9e81608ecc587a796998520a8da47
Signed-off-by: wangqianyu 
---
 ovn/controller/ovn-controller.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/ovn/controller/ovn-controller.c 
b/ovn/controller/ovn-controller.c
index 45a670b..41eedbc 100644
--- a/ovn/controller/ovn-controller.c
+++ b/ovn/controller/ovn-controller.c
@@ -174,6 +174,7 @@ update_sb_monitors(struct ovsdb_idl *ovnsb_idl,
 const char *name;
 SSET_FOR_EACH (name, local_ifaces) {
 sbrec_port_binding_add_clause_logical_port(, OVSDB_F_EQ, 
name);
+sbrec_port_binding_add_clause_parent_port(, OVSDB_F_EQ, 
name);
 }
 }
 if (local_datapaths) {
-- 
1.9.1
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH] ovn-northd: Optimize acl of localnet-port

2017-07-09 Thread wang . qianyu

Localnet port is not an endpoint, and have no security requirements
to use localnet port at present. So, for performance consideration, we
could do not use ct for localnet port.

The more specific discussion can be found from
https://mail.openvswitch.org/pipermail/ovs-dev/2017-July/335048.html

Change-Id: Iac42ceaa3ef1d4e9b34768f802502d8326b7f507
Signed-off-by: wangqianyu 
---
 ovn/northd/ovn-northd.8.xml |  4 +++-
 ovn/northd/ovn-northd.c | 24 +++-
 2 files changed, 26 insertions(+), 2 deletions(-)

diff --git a/ovn/northd/ovn-northd.8.xml b/ovn/northd/ovn-northd.8.xml
index c0b4c5e..05f0470 100644
--- a/ovn/northd/ovn-northd.8.xml
+++ b/ovn/northd/ovn-northd.8.xml
@@ -220,7 +220,9 @@
   logical datapath, a priority-100 flow is added that sets a hint
   (with reg0[0] = 1; next;) for table
   Pre-stateful to send IP packets to the connection 
tracker
-  before eventually advancing to ingress table ACLs.
+  before eventually advancing to ingress table ACLs. If 
some
+  special ports such as route ports or localnet ports can't use ct(), 
 a
+  priority-110 flow is added to skip over stateful ACLs.
 
 
 Ingress Table 4: Pre-LB
diff --git a/ovn/northd/ovn-northd.c b/ovn/northd/ovn-northd.c
index 83db753..eea12e8 100644
--- a/ovn/northd/ovn-northd.c
+++ b/ovn/northd/ovn-northd.c
@@ -1,4 +1,4 @@
-/*
+/*
  * Licensed under the Apache License, Version 2.0 (the "License");
  * you may not use this file except in compliance with the License.
  * You may obtain a copy of the License at:
@@ -416,6 +416,7 @@ struct ovn_datapath {
 /* The "derived" OVN port representing the instance of l3dgw_port on
  * the "redirect-chassis". */
 struct ovn_port *l3redirect_port;
+struct ovn_port *localnet_port;
 };
 
 struct macam_node {
@@ -1351,6 +1352,10 @@ join_logical_ports(struct northd_context *ctx,
 ovs_list_push_back(nb_only, >list);
 }
 
+if (!strcmp(nbsp->type, "localnet")) {
+   od->localnet_port = op;
+}
+
 op->lsp_addrs
 = xmalloc(sizeof *op->lsp_addrs * nbsp->n_addresses);
 for (size_t j = 0; j < nbsp->n_addresses; j++) {
@@ -2629,6 +2634,23 @@ build_pre_acls(struct ovn_datapath *od, struct hmap 
*lflows)
 ds_destroy(_in);
 ds_destroy(_out);
 }
+if (od->localnet_port) {
+struct ds match_in = DS_EMPTY_INITIALIZER;
+struct ds match_out = DS_EMPTY_INITIALIZER;
+
+ds_put_format(_in, "ip && inport == %s",
+  od->localnet_port->json_key);
+ds_put_format(_out, "ip && outport == %s",
+  od->localnet_port->json_key);
+ovn_lflow_add(lflows, od, S_SWITCH_IN_PRE_ACL, 110,
+  ds_cstr(_in), "next;");
+ovn_lflow_add(lflows, od, S_SWITCH_OUT_PRE_ACL, 110,
+  ds_cstr(_out), "next;");
+
+ds_destroy(_in);
+ds_destroy(_out);
+}
+
 /* Ingress and Egress Pre-ACL Table (Priority 110).
  *
  * Not to do conntrack on ND packets. */
-- 
2.7.2.windows.1

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

[ovs-dev] 答复: Re: 答复: Re: 答复: Re: 答复: [spam可疑邮件]Re: 答复: Re: [PATCH 2/2] ovn-northd: Fix ping failure of vlan networks.

2017-07-06 Thread wang . qianyu

Hi Han

Thanks for the reiew job.

I will revise the commit message in new patch.

Qianyu

Han Zhou
2017/07/07 02:15

收件人：Mickey Spiegel ,
抄送： wang.qia...@zte.com.cn, ovs dev ,
xurong00037997 , zhou.huij...@zte.com.cn
主题： Re: 答复: Re: [ovs-dev] 答复: Re: 答复: [spam可疑邮件]Re:
答复: Re: [PATCH 2/2] ovn-northd: Fix ping failure of vlan networks.

Despite the original motivation of this change, I found the patch valuable
for data-plane performance.

When localnet port is used for communication between 2 ports of same
lswitch (basic provider network scenario), without the patch, each flow is
tracked in conntrack table twice. With the patch, it improve the
performance in 2 ways:

1) It reduces 50% of conntrack operations

2) It reduces 50% number of entries in conntrack table, which also helps
reducing conntrack cost

I had some tests for TCP_CRR, it improves performance for 5 - 10%.
Discussed in today's ovn meeting and we agreed it is valid optimization
because localnet port is used as transport, not the real end-point to
protect.

@Qianyu, would it be good to revise the patch on the commit message to put
it as an optimization for conntrack performance? The current commit
message is not true because it is not a supported scenario for now, and
the "fix" is not complete, either. The new scenaro would worth a separate
discussion. What do you think?

On Wed, Jul 5, 2017 at 9:07 PM, Mickey Spiegel
wrote:

On Tue, Jul 4, 2017 at 6:01 PM, wrote:
Hi Mickey,

Thanks for your review.

If we could do some modifications to avoid the north/south problem you
mentioned? Like as follow:

When packets send to the localnet-port, if the MAC is router-port MAC, we
change the router-port MAC to HV physical NIC MAC. And in gateway node, we
make the HV physical NIC MAC and router-port MAC all sense.

In OpenStack usage, for public internet access, it is common for one
logical switch to have many different logical routers connected to it,
which can reside on the same hypervisor. The MAC address is used to
identify which logical router the traffic is destined to. So you would
need a MAC address per (logical router, chassis) pair, or you would have
to introduce yet another type of router that front ends the distributed
logical routers, deciding based on destination IP address. Either way, a
port with a different MAC address on each chassis that hosts the port
seems different than the logical router ports that exist today.

I am still trying to understand your use case. It sounds like you have
different regions, with different logical switches in different regions.
If you just put localnets on each of those logical switches, wouldn't that
do what you want?

If you need L3 between the different regions, you could use a separate
router per region, either a gateway router in each region, or a
distributed logical router with a distributed gateway port in each region.
With gateway routers, traffic coming in and out of each region goes
through one centralized chassis. With a distributed logical router,
non-NAT traffic coming in and out of each region goes through one
centralized chassis, while NAT traffic coming in and out of each region
can be distributed. With this type of solution, traffic will go in and out
of each localnet symmetrically, in both directions.

Mickey

Thanks!

Mickey Spiegel
2017/06/30 12:31

收件人：Han Zhou ,
抄送：wang.qia...@zte.com.cn, ovs dev , zhou.huij...@zte.com.cn, xurong00037997
主题：Re: [ovs-dev] 答复: Re: 答复: [spam可疑邮件]Re: 答复
: Re: [PATCH 2/2] ovn-northd: Fix ping failure of vlan networks.

On Thu, Jun 29, 2017 at 2:19 PM, Han Zhou wrote:
I learned that this use case is kind of Hierarchical scenario:
https://specs.openstack.org/openstack/neutron-specs/specs/kilo/ml2-hierarchical-port-binding.html

In such scenario, user wants to use OVN to manage vlan networks, and the
vlan networks is connected via VTEP overlay, which is not managed by OVN
itself. VTEP is needed to connect to BM/SRIOV VMs to the same L2 that OVS
VIFs are connected to.

User don't want to use OVN to manage VTEPs since there will be flooding to
many VTEPs. (Mac-learning is not supported yet)

So in this scenario, user want to utilize distributed logical router as a
way to optimize the datapath. For VM to VM traffic between different
vlans,
instead of going to a centralized external L3 router, user wants the
traffic to be tagged to the destination vlan directly and go straight from
source HV to destination HV through the destination vlan.

L2 and L3 have different semantics and different ways of handling packets.

There is a big difference between:
1) bridging between

[ovs-dev] 答复: Re: 答复: Re: 答复: [spam可疑邮件]Re: 答复: Re: [PATCH 2/2] ovn-northd: Fix ping failure of vlan networks.

2017-07-04 Thread wang . qianyu

Hi Mickey,

Thanks for your review.

If we could do some modifications to avoid the north/south problem you
mentioned? Like as follow:

Thanks!

Mickey Spiegel
2017/06/30 12:31

收件人：Han Zhou ,
抄送： wang.qia...@zte.com.cn, ovs dev ,
zhou.huij...@zte.com.cn, xurong00037997
主题： Re: [ovs-dev] 答复: Re: 答复: [spam可疑邮件]Re: 答复: Re:
[PATCH 2/2] ovn-northd: Fix ping failure of vlan networks.

User don't want to use OVN to manage VTEPs since there will be flooding to
many VTEPs. (Mac-learning is not supported yet)

L2 and L3 have different semantics and different ways of handling packets.
There is a big difference between:
1) bridging between different VLANs, going through a VTEP overlay
that connects those VLANs, and
2) routing between different VLANs.
Trying to blur that boundary will lead to unexpected behavior and various
issues.

In the vtep scenario, this is a valuable optimization. Even in a normal
vlan setup without vtep, this can be an optimization too if src and dst
VMs
are on the same HV (so that the packet doesn't need to go to physical
switch and come back).

So, I agree with Qianyu that connecting VLAN networks with logical router
is reasonable, which means, the transport of logical router can be not
only
tunnels, but also physical networks (localnet port).

Mixing routers and localnet is dangerous because of interactions with
MAC addresses and L2 learning. The reason it is not a good idea to
transmit packets from a distributed logical router directly to a physical
network through localnet is because the router rewrites the source MAC
to the router MAC. The physical network will learn about the router MAC
based on the last location from which it saw the router send a packet to
the physical network. That may have low correlation with the next
packet from the physical network back to the router MAC, so north/south
packets may end up with an almost random distribution of chassis on
which the distributed logical router resides, independent of where the
destination actually resides.

You are looking only at east west traffic, counting on the asymmetry using
the distributed router instance on the other side so that return traffic
never hits the physical network with the router MAC as the destination
MAC. However, there will be north/south traffic destined to the router
MAC, and this approach will make that bounce all over the place.

Perhaps you can make something work if you have per node per router
MAC addresses, but it still scares me.

To fulfill this
requirement, we need to solve some problems in current OVN code:

1) Since the data path is asymmetric, we need to solve the CT problem of
the localnet port. I agree with the idea of the patch from Qianyu, which
bypasses FW for localnet ports, since localnet port is to connect real
endpoints, so maybe there is not much value to add ACL on localnet ports.
Not sure if there is use case where ACL is really needed for localnet
ports.

2) When there are ARP requests from vlan network (e.g. from a BM) to
logical router interface IP, the ARP request will reach every HV through
the localnet port and the distributed logical router port will respond
from
every HV. Shall we disable ARP response from logical router for requests
from localnet port? In this scenario, I would expect the BM/SRIOV VMs on
the same vlan to use a different GW rather than the logical router.

How will north/south traffic work?

Distributed gateway ports limit ARP responses so that only one instance
of the distributed gateway port on one chassis responds.

At the moment distributed gateway ports only allow direct traffic (without
going through the central node) for 1:1 NAT with logical_port and
external_mac specified. This is because of the implications of upstream
L2 learning, and lack of a routing protocol. If there are mechanisms that

[ovs-dev] [PATCH] ovn-controller: fix vlan_trunk bug

2017-07-04 Thread wang . qianyu

The bug description is as follow:

Neutron configure a trunk-sub port. The parent-port and sub-port located 
in different network. there is a vm attached to parent port. And no vm 
attached to the network of sub-port in the same chassis. In this 
situation, the ovn-controller can not get the configuration info of 
sub-port.

The reason is that ovn-controller does not monitor the port-binding with 
parent.

This patch fix this bug.

Change-Id: I0ce3f5b1b5a9e81608ecc587a796998520a8da47
Signed-off-by: 10110202 
---
 ovn/controller/ovn-controller.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/ovn/controller/ovn-controller.c 
b/ovn/controller/ovn-controller.c
index 00b4cda..4406f00 100644
--- a/ovn/controller/ovn-controller.c
+++ b/ovn/controller/ovn-controller.c
@@ -174,6 +174,7 @@ update_sb_monitors(struct ovsdb_idl *ovnsb_idl,
 const char *name;
 SSET_FOR_EACH (name, local_ifaces) {
 sbrec_port_binding_add_clause_logical_port(, OVSDB_F_EQ, 
name);
+sbrec_port_binding_add_clause_parent_port(, OVSDB_F_EQ, 
name);
 }
 }
 if (local_datapaths) {
-- 
1.8.3.1
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] 答复: Re: 答复: [spam可疑邮件]Re: 答复: Re: [PATCH 2/2] ovn-northd: Fix ping failure of vlan networks.

2017-06-27 Thread wang . qianyu

Hi Han Zhou,

> If using localnet, it should rely on physical network (L2 and L3) to 
reach the destination, not overlay, so adding the logical router here 
doesn't make sense here

Why ovn have this limit for physical network? Does this mean that vlan 
network can not use the l3 function of ovn?

Thanks





Han Zhou 
2017/06/27 16:24
 
收件人：wang.qia...@zte.com.cn, 
抄送：  Russell Bryant , ovs dev 
, zhou.huij...@zte.com.cn, xurong00037997 

主题：  Re: [ovs-dev] 答复: [spam可疑邮件]Re: 答复: Re: [PATCH 
2/2] ovn-northd: Fix ping failure of vlan networks.




On Thu, Jun 15, 2017 at 1:04 AM,  wrote:
>
> Hi Russell, I am sorry for the late reply.
> The route not bound to a chassis, and have no redirect-chassis. The 
dumped
> northbound db is as follow.
> Ip addresses of 100.0.0.148 and 200.0.0.2 locate on different chassis. 
The
> ping between them is not success before this patch.
>
>
> [root@tecs159 ~]#
> [root@tecs159 ~]# ovsdb-client dump
> unix:/var/run/openvswitch/ovnnb_db.sock
> ACL table
> _uuidactiondirection 
 external_ids
> log   match priority
>  - --
>  -
> 
--
> 
> ac2900f9-49fd-430a-b646-88d1f7c54ab8 allow from-lport
> {"neutron:lport"="1ef52eb4-1f0e-416d-8dc2-e2fc7557979c"} false "inport 
==
> \"1ef52eb4-1f0e-416d-8dc2-e2fc7557979c\" && ip4 && ip4.dst ==
> {255.255.255.255, 100.0.0.0/24} && udp && udp.src == 68 && udp.dst == 
67"
> 1002
> 784a55c3-05fd-4c4d-a51e-5b9ee5cc1e8e allow from-lport
> {"neutron:lport"="6c04e45e-ad83-4cf0-ae74-84f7720a5bc4"} false "inport 
==
> \"6c04e45e-ad83-4cf0-ae74-84f7720a5bc4\" && ip4 && ip4.dst ==
> {255.255.255.255, 100.0.0.0/24} && udp && udp.src == 68 && udp.dst == 
67"
> 1002
> 08be2532-f8ff-493f-83e3-085eede36e08 allow from-lport
> {"neutron:lport"="c5ff4f7b-bd0d-4757-ac18-636f9d62b94c"} false "inport 
==
> \"c5ff4f7b-bd0d-4757-ac18-636f9d62b94c\" && ip4 && ip4.dst ==
> {255.255.255.255, 100.0.0.0/24} && udp && udp.src == 68 && udp.dst == 
67"
> 1002
> bb263947-a436-4a0d-9218-5abd89546a69 allow from-lport
> {"neutron:lport"="f8de0603-f4ec-4546-a8f3-574640f270e8"} false "inport 
==
> \"f8de0603-f4ec-4546-a8f3-574640f270e8\" && ip4 && ip4.dst ==
> {255.255.255.255, 200.0.0.0/24} && udp && udp.src == 68 && udp.dst == 
67"
> 1002
> 092964cc-2ce5-4a34-b747-558006bb3de1 allow-related from-lport
> {"neutron:lport"="1ef52eb4-1f0e-416d-8dc2-e2fc7557979c"} false "inport 
==
> \"1ef52eb4-1f0e-416d-8dc2-e2fc7557979c\" && ip4" 1002
> 5f2ebb8e-edbc-40aa-ada6-2fc90fc104af allow-related from-lport
> {"neutron:lport"="1ef52eb4-1f0e-416d-8dc2-e2fc7557979c"} false "inport 
==
> \"1ef52eb4-1f0e-416d-8dc2-e2fc7557979c\" && ip6" 1002
> 13d32fab-0ed7-4472-97c2-1e3057eaca6e allow-related from-lport
> {"neutron:lport"="6c04e45e-ad83-4cf0-ae74-84f7720a5bc4"} false "inport 
==
> \"6c04e45e-ad83-4cf0-ae74-84f7720a5bc4\" && ip4" 1002
> 7fa4e0b0-ffce-436f-a20a-07b0584c3285 allow-related from-lport
> {"neutron:lport"="6c04e45e-ad83-4cf0-ae74-84f7720a5bc4"} false "inport 
==
> \"6c04e45e-ad83-4cf0-ae74-84f7720a5bc4\" && ip6" 1002
> b32cf462-a8e5-4597-9c6e-4dc02ae2e2c4 allow-related from-lport
> {"neutron:lport"="c5ff4f7b-bd0d-4757-ac18-636f9d62b94c"} false "inport 
==
> \"c5ff4f7b-bd0d-4757-ac18-636f9d62b94c\" && ip4" 1002
> 4d003f24-f546-49fa-a33c-92384e4d3549 allow-related from-lport
> {"neutron:lport"="c5ff4f7b-bd0d-4757-ac18-636f9d62b94c"} false "inport 
==
> \"c5ff4f7b-bd0d-4757-ac18-636f9d62b94c\" && ip6" 1002
> 7078873a-fa44-4c64-be7f-067d19361fb4 allow-related from-lport
> {"neutron:lport"="f8de0603-f4ec-4546-a8f3-574640f270e8"} false "inport 
==
> \"f8de0603-f4ec-4546-a8f3-574640f270e8\" && ip4" 1002
> a15bd032-9755-45a5-b7ea-9687b9d14560 allow-related from-lport
> {"neutron:lport"="f8de0603-f4ec-4546-a8f3-574640f270e8"} false "inport 
==
> \"f8de0603-f4ec-4546-a8f3-574640f270e8\" && ip6" 1002
> 4ace5b98-e6dd-467c-a7cf-af5e76a258f5 allow-related to-lport
> {"neutron:lport"="1ef52eb4-1f0e-416d-8dc2-e2fc7557979c"} false "outport 
==
> \"1ef52eb4-1f0e-416d-8dc2-e2fc7557979c\" && ip4 && ip4.src ==
> $as_ip4_539bd583_ca35_4ae7_9774_299fd56765ef" 1002
> 6e3453ee-a717-49fe-8160-ab304daa7bd8 allow-related to-lport
> {"neutron:lport"="1ef52eb4-1f0e-416d-8dc2-e2fc7557979c"} false "outport 
==
> \"1ef52eb4-1f0e-416d-8dc2-e2fc7557979c\" && ip6 && ip6.src ==
> $as_ip6_539bd583_ca35_4ae7_9774_299fd56765ef" 1002
> cc1b88c5-e9d7-42fe-8e17-deb2fbc7c7a2 allow-related to-lport
>

[ovs-dev] [PATCH] ovn: add qos function.

2017-06-25 Thread wang . qianyu

The current qos function is used for geneve
tunnel to control the traffic out the ovs. And have no to-port qos 
control.

This patch do the modification as follow
1. change the qos configuration with direction to consistent with neutron
qos rule. Add qos_ingress_max_rate, qos_ingress_burst, qos_egress_max_rate
and qos_egress_burst to instead old qos_max_rate and qos_burst.

2. By configure the interface table field of ingress_policing_rate and
ingress_policing_bust to implement the ingress qos control.

3. Add qos configuration to qos field of port table to implement egress 
qos
control.

4. Add dpdk qos support.

Change-Id: Ie90364cb5bee7f6b7e3086e0867997f7edab7038
---
 ovn/controller/binding.c | 525 
---
 ovn/northd/ovn-northd.c  |  17 +-
 ovn/ovn-nb.xml   |  18 +-
 ovn/ovn-sb.xml   |  18 +-
 4 files changed, 360 insertions(+), 218 deletions(-)

diff --git a/ovn/controller/binding.c b/ovn/controller/binding.c
index bb76608..f40273f 100644
--- a/ovn/controller/binding.c
+++ b/ovn/controller/binding.c
@@ -1,4 +1,4 @@
-/* Copyright (c) 2015, 2016, 2017 Nicira, Inc.
+/* Copyright (c) 2015, 2016, 2017 Nicira, Inc.
  *
  * Licensed under the Apache License, Version 2.0 (the "License");
  * you may not use this file except in compliance with the License.
@@ -33,13 +33,26 @@ VLOG_DEFINE_THIS_MODULE(binding);
 
 #define OVN_QOS_TYPE "linux-htb"
 
+#define IS_SUB_PORT(PB)  (PB->parent_port && \
+PB->parent_port[0])
+
 struct qos_queue {
 struct hmap_node node;
 uint32_t queue_id;
-uint32_t max_rate;
-uint32_t burst;
+uint32_t ingress_max_rate;
+uint32_t ingress_burst;
+uint32_t egress_max_rate;
+uint32_t egress_burst;
 };
 
+static void
+add_column_noalert(struct ovsdb_idl *idl,
+   const struct ovsdb_idl_column *column)
+{
+ovsdb_idl_add_column(idl, column);
+ovsdb_idl_omit_alert(idl, column);
+}
+
 void
 binding_register_ovs_idl(struct ovsdb_idl *ovs_idl)
 {
@@ -59,16 +72,28 @@ binding_register_ovs_idl(struct ovsdb_idl *ovs_idl)
 ovsdb_idl_add_column(ovs_idl, _interface_col_name);
 ovsdb_idl_add_column(ovs_idl, _interface_col_external_ids);
 ovsdb_idl_add_column(ovs_idl, _interface_col_status);
+add_column_noalert(ovs_idl, 
_interface_col_ingress_policing_rate);
+add_column_noalert(ovs_idl, 
_interface_col_ingress_policing_burst);
+add_column_noalert(ovs_idl, _port_col_qos);
 
 ovsdb_idl_add_table(ovs_idl, _table_qos);
-ovsdb_idl_add_column(ovs_idl, _qos_col_type);
+add_column_noalert(ovs_idl, _qos_col_external_ids);
+add_column_noalert(ovs_idl, _qos_col_other_config);
+add_column_noalert(ovs_idl, _qos_col_type);
+add_column_noalert(ovs_idl, _qos_col_queues);
+
+ovsdb_idl_add_table(ovs_idl, _table_queue);
+add_column_noalert(ovs_idl, _queue_col_external_ids);
+add_column_noalert(ovs_idl, _queue_col_other_config);
+add_column_noalert(ovs_idl, _queue_col_dscp);
 }
 
 static void
 get_local_iface_ids(const struct ovsrec_bridge *br_int,
 struct shash *lport_to_iface,
 struct sset *local_lports,
-struct sset *egress_ifaces)
+struct sset *egress_ifaces,
+struct shash *lport_to_pport)
 {
 int i;
 
@@ -90,6 +115,7 @@ get_local_iface_ids(const struct ovsrec_bridge *br_int,
 
 if (iface_id && ofport > 0) {
 shash_add(lport_to_iface, iface_id, iface_rec);
+shash_add(lport_to_pport, iface_id, port_rec);
 sset_add(local_lports, iface_id);
 }
 
@@ -163,206 +189,39 @@ add_local_datapath(const struct ldatapath_index 
*ldatapaths,
  local_datapaths);
 }
 
-static void
-get_qos_params(const struct sbrec_port_binding *pb, struct hmap 
*queue_map)
+static  bool
+get_qos_params(const struct sbrec_port_binding *pb, struct qos_queue 
*queue)
 {
-uint32_t max_rate = smap_get_int(>options, "qos_max_rate", 0);
-uint32_t burst = smap_get_int(>options, "qos_burst", 0);
+uint32_t ingress_max_rate = smap_get_int(>options, 
"qos_ingress_max_rate", 0);
+uint32_t ingress_burst = smap_get_int(>options, 
"qos_ingress_burst", 0);
+uint32_t egress_max_rate = smap_get_int(>options, 
"qos_egress_max_rate", 0);
+uint32_t egress_burst = smap_get_int(>options, 
"qos_egress_burst", 0);
 uint32_t queue_id = smap_get_int(>options, "qdisc_queue_id", 0);
-
-if ((!max_rate && !burst) || !queue_id) {
+ 
+if (!queue_id) {
 /* Qos is not configured for this port. */
-return;
-}
-
-struct qos_queue *node = xzalloc(sizeof *node);
-hmap_insert(queue_map, >node, hash_int(queue_id, 0));
-node->max_rate = max_rate;
-node->burst = burst;
-node->queue_id = queue_id;
-}
-
-static const struct ovsrec_qos *
-get_noop_qos(struct controller_ctx *ctx)
-{
-const struct ovsrec_qos *qos;
-OVSREC_QOS_FOR_EACH (qos,

[ovs-dev] 答复: [spam可疑邮件]Re: 答复: Re: [PATCH 2/2] ovn-northd: Fix ping failure of vlan networks.

2017-06-15 Thread wang . qianyu

Hi Russell, I am sorry for the late reply.
The route not bound to a chassis, and have no redirect-chassis. The dumped 
northbound db is as follow.
Ip addresses of 100.0.0.148 and 200.0.0.2 locate on different chassis. The 
ping between them is not success before this patch.


[root@tecs159 ~]# 
[root@tecs159 ~]# ovsdb-client dump 
unix:/var/run/openvswitch/ovnnb_db.sock
ACL table
_uuidactiondirection  external_ids 
log   match priority
 - -- 
 - 
--
 

ac2900f9-49fd-430a-b646-88d1f7c54ab8 allow from-lport 
{"neutron:lport"="1ef52eb4-1f0e-416d-8dc2-e2fc7557979c"} false "inport == 
\"1ef52eb4-1f0e-416d-8dc2-e2fc7557979c\" && ip4 && ip4.dst == 
{255.255.255.255, 100.0.0.0/24} && udp && udp.src == 68 && udp.dst == 67" 
1002 
784a55c3-05fd-4c4d-a51e-5b9ee5cc1e8e allow from-lport 
{"neutron:lport"="6c04e45e-ad83-4cf0-ae74-84f7720a5bc4"} false "inport == 
\"6c04e45e-ad83-4cf0-ae74-84f7720a5bc4\" && ip4 && ip4.dst == 
{255.255.255.255, 100.0.0.0/24} && udp && udp.src == 68 && udp.dst == 67" 
1002 
08be2532-f8ff-493f-83e3-085eede36e08 allow from-lport 
{"neutron:lport"="c5ff4f7b-bd0d-4757-ac18-636f9d62b94c"} false "inport == 
\"c5ff4f7b-bd0d-4757-ac18-636f9d62b94c\" && ip4 && ip4.dst == 
{255.255.255.255, 100.0.0.0/24} && udp && udp.src == 68 && udp.dst == 67" 
1002 
bb263947-a436-4a0d-9218-5abd89546a69 allow from-lport 
{"neutron:lport"="f8de0603-f4ec-4546-a8f3-574640f270e8"} false "inport == 
\"f8de0603-f4ec-4546-a8f3-574640f270e8\" && ip4 && ip4.dst == 
{255.255.255.255, 200.0.0.0/24} && udp && udp.src == 68 && udp.dst == 67" 
1002 
092964cc-2ce5-4a34-b747-558006bb3de1 allow-related from-lport 
{"neutron:lport"="1ef52eb4-1f0e-416d-8dc2-e2fc7557979c"} false "inport == 
\"1ef52eb4-1f0e-416d-8dc2-e2fc7557979c\" && ip4" 1002 
5f2ebb8e-edbc-40aa-ada6-2fc90fc104af allow-related from-lport 
{"neutron:lport"="1ef52eb4-1f0e-416d-8dc2-e2fc7557979c"} false "inport == 
\"1ef52eb4-1f0e-416d-8dc2-e2fc7557979c\" && ip6" 1002 
13d32fab-0ed7-4472-97c2-1e3057eaca6e allow-related from-lport 
{"neutron:lport"="6c04e45e-ad83-4cf0-ae74-84f7720a5bc4"} false "inport == 
\"6c04e45e-ad83-4cf0-ae74-84f7720a5bc4\" && ip4" 1002 
7fa4e0b0-ffce-436f-a20a-07b0584c3285 allow-related from-lport 
{"neutron:lport"="6c04e45e-ad83-4cf0-ae74-84f7720a5bc4"} false "inport == 
\"6c04e45e-ad83-4cf0-ae74-84f7720a5bc4\" && ip6" 1002 
b32cf462-a8e5-4597-9c6e-4dc02ae2e2c4 allow-related from-lport 
{"neutron:lport"="c5ff4f7b-bd0d-4757-ac18-636f9d62b94c"} false "inport == 
\"c5ff4f7b-bd0d-4757-ac18-636f9d62b94c\" && ip4" 1002 
4d003f24-f546-49fa-a33c-92384e4d3549 allow-related from-lport 
{"neutron:lport"="c5ff4f7b-bd0d-4757-ac18-636f9d62b94c"} false "inport == 
\"c5ff4f7b-bd0d-4757-ac18-636f9d62b94c\" && ip6" 1002 
7078873a-fa44-4c64-be7f-067d19361fb4 allow-related from-lport 
{"neutron:lport"="f8de0603-f4ec-4546-a8f3-574640f270e8"} false "inport == 
\"f8de0603-f4ec-4546-a8f3-574640f270e8\" && ip4" 1002 
a15bd032-9755-45a5-b7ea-9687b9d14560 allow-related from-lport 
{"neutron:lport"="f8de0603-f4ec-4546-a8f3-574640f270e8"} false "inport == 
\"f8de0603-f4ec-4546-a8f3-574640f270e8\" && ip6" 1002 
4ace5b98-e6dd-467c-a7cf-af5e76a258f5 allow-related to-lport 
{"neutron:lport"="1ef52eb4-1f0e-416d-8dc2-e2fc7557979c"} false "outport == 
\"1ef52eb4-1f0e-416d-8dc2-e2fc7557979c\" && ip4 && ip4.src == 
$as_ip4_539bd583_ca35_4ae7_9774_299fd56765ef" 1002 
6e3453ee-a717-49fe-8160-ab304daa7bd8 allow-related to-lport 
{"neutron:lport"="1ef52eb4-1f0e-416d-8dc2-e2fc7557979c"} false "outport == 
\"1ef52eb4-1f0e-416d-8dc2-e2fc7557979c\" && ip6 && ip6.src == 
$as_ip6_539bd583_ca35_4ae7_9774_299fd56765ef" 1002 
cc1b88c5-e9d7-42fe-8e17-deb2fbc7c7a2 allow-related to-lport 
{"neutron:lport"="6c04e45e-ad83-4cf0-ae74-84f7720a5bc4"} false "outport == 
\"6c04e45e-ad83-4cf0-ae74-84f7720a5bc4\" && ip4 && ip4.src == 
$as_ip4_539bd583_ca35_4ae7_9774_299fd56765ef" 1002 
ecb2798f-4a87-4260-b9a8-3cdea1eca638 allow-related to-lport 
{"neutron:lport"="6c04e45e-ad83-4cf0-ae74-84f7720a5bc4"} false "outport == 
\"6c04e45e-ad83-4cf0-ae74-84f7720a5bc4\" && ip6 && ip6.src == 
$as_ip6_539bd583_ca35_4ae7_9774_299fd56765ef" 1002 
71c56144-3b95-454a-acb4-67cd924dff08 allow-related to-lport 
{"neutron:lport"="c5ff4f7b-bd0d-4757-ac18-636f9d62b94c"} false "outport == 
\"c5ff4f7b-bd0d-4757-ac18-636f9d62b94c\" && ip4 && ip4.src == 
$as_ip4_539bd583_ca35_4ae7_9774_299fd56765ef" 1002 
15766592-aa79-465b-8935-bbc916692b75 allow-related to-lport 
{"neutron:lport"="c5ff4f7b-bd0d-4757-ac18-636f9d62b94c"} false "outport ==

[ovs-dev] 答复: Re: [PATCH 2/2] ovn-northd: Fix ping failure of vlan networks.

2017-06-05 Thread wang . qianyu

router is not external to OVN




Russell Bryant 
2017/06/05 20:12
 
收件人：wang.qia...@zte.com.cn, 
抄送：  Ben Pfaff , ovs dev , 
zhou.huij...@zte.com.cn, xurong00037997 
主题：  Re: [ovs-dev] [PATCH 2/2] ovn-northd: Fix ping failure of 
vlan networks.


On Thu, Jun 1, 2017 at 10:09 PM,   wrote:
> There are two computer node, each have one vm. And the two vms in
> indifferent vlan networks. The ping between the vms is not success.
>
> The reason is that, acl of to-localnet port or from-localnet port is
> signed to contrack. So the pair of icmp request and reply have different
> zone id in one ovs node. This makes the ct state not correct.
>
> This patch do the modification that localnet port do not use ct.
>
> Change-Id: Iac42ceaa3ef1d4e9b34768f802502d8326b7f507
> Signed-off-by: wangqianyu 
> ---
>  ovn/northd/ovn-northd.8.xml |  4 +++-
>  ovn/northd/ovn-northd.c | 24 +++-
>  2 files changed, 26 insertions(+), 2 deletions(-)
>

Can you help clarify the scenario here used to reproduce the problem?

Is it just:

Logical Switch A
VM 1
localnet port - VLAN 100

Logical Switch B
VM 2
localnet port - VLAN 200

and pinging between VM 1 and VM 2 through a router that is external to 
OVN?


> diff --git a/ovn/northd/ovn-northd.8.xml b/ovn/northd/ovn-northd.8.xml
> index c0b4c5e..05f0470 100644
> --- a/ovn/northd/ovn-northd.8.xml
> +++ b/ovn/northd/ovn-northd.8.xml
> @@ -220,7 +220,9 @@
>logical datapath, a priority-100 flow is added that sets a hint
>(with reg0[0] = 1; next;) for table
>Pre-stateful to send IP packets to the connection
> tracker
> -  before eventually advancing to ingress table ACLs.
> +  before eventually advancing to ingress table ACLs. 
If
> some
> +  special ports such as route ports or localnet ports can't use 
ct(),
>  a
> +  priority-110 flow is added to skip over stateful ACLs.
>  
>
>  Ingress Table 4: Pre-LB
> diff --git a/ovn/northd/ovn-northd.c b/ovn/northd/ovn-northd.c
> index 83db753..eea12e8 100644
> --- a/ovn/northd/ovn-northd.c
> +++ b/ovn/northd/ovn-northd.c
> @@ -1,4 +1,4 @@
> -/*
> +/*
>   * Licensed under the Apache License, Version 2.0 (the "License");
>   * you may not use this file except in compliance with the License.
>   * You may obtain a copy of the License at:
> @@ -416,6 +416,7 @@ struct ovn_datapath {
>  /* The "derived" OVN port representing the instance of l3dgw_port 
on
>   * the "redirect-chassis". */
>  struct ovn_port *l3redirect_port;
> +struct ovn_port *localnet_port;
>  };
>
>  struct macam_node {
> @@ -1351,6 +1352,10 @@ join_logical_ports(struct northd_context *ctx,
>  ovs_list_push_back(nb_only, >list);
>  }
>
> +if (!strcmp(nbsp->type, "localnet")) {
> +   od->localnet_port = op;
> +}
> +
>  op->lsp_addrs
>  = xmalloc(sizeof *op->lsp_addrs * 
nbsp->n_addresses);
>  for (size_t j = 0; j < nbsp->n_addresses; j++) {
> @@ -2629,6 +2634,23 @@ build_pre_acls(struct ovn_datapath *od, struct 
hmap
> *lflows)
>  ds_destroy(_in);
>  ds_destroy(_out);
>  }
> +if (od->localnet_port) {
> +struct ds match_in = DS_EMPTY_INITIALIZER;
> +struct ds match_out = DS_EMPTY_INITIALIZER;
> +
> +ds_put_format(_in, "ip && inport == %s",
> +  od->localnet_port->json_key);
> +ds_put_format(_out, "ip && outport == %s",
> +  od->localnet_port->json_key);
> +ovn_lflow_add(lflows, od, S_SWITCH_IN_PRE_ACL, 110,
> +  ds_cstr(_in), "next;");
> +ovn_lflow_add(lflows, od, S_SWITCH_OUT_PRE_ACL, 110,
> +  ds_cstr(_out), "next;");
> +
> +ds_destroy(_in);
> +ds_destroy(_out);
> +}
> +
>  /* Ingress and Egress Pre-ACL Table (Priority 110).
>   *
>   * Not to do conntrack on ND packets. */
> --
> 2.7.2.windows.1
> ___
> 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

[ovs-dev] [PATCH 2/2] ovn-northd: Fix ping failure of vlan networks.

2017-06-01 Thread wang . qianyu

There are two computer node, each have one vm. And the two vms in 
indifferent vlan networks. The ping between the vms is not success.

The reason is that, acl of to-localnet port or from-localnet port is
signed to contrack. So the pair of icmp request and reply have different
zone id in one ovs node. This makes the ct state not correct.

This patch do the modification that localnet port do not use ct.

Change-Id: Iac42ceaa3ef1d4e9b34768f802502d8326b7f507
Signed-off-by: wangqianyu 
---
 ovn/northd/ovn-northd.8.xml |  4 +++-
 ovn/northd/ovn-northd.c | 24 +++-
 2 files changed, 26 insertions(+), 2 deletions(-)

diff --git a/ovn/northd/ovn-northd.8.xml b/ovn/northd/ovn-northd.8.xml
index c0b4c5e..05f0470 100644
--- a/ovn/northd/ovn-northd.8.xml
+++ b/ovn/northd/ovn-northd.8.xml
@@ -220,7 +220,9 @@
   logical datapath, a priority-100 flow is added that sets a hint
   (with reg0[0] = 1; next;) for table
   Pre-stateful to send IP packets to the connection 
tracker
-  before eventually advancing to ingress table ACLs.
+  before eventually advancing to ingress table ACLs. If 
some
+  special ports such as route ports or localnet ports can't use ct(), 
 a
+  priority-110 flow is added to skip over stateful ACLs.
 
 
 Ingress Table 4: Pre-LB
diff --git a/ovn/northd/ovn-northd.c b/ovn/northd/ovn-northd.c
index 83db753..eea12e8 100644
--- a/ovn/northd/ovn-northd.c
+++ b/ovn/northd/ovn-northd.c
@@ -1,4 +1,4 @@
-/*
+/*
  * Licensed under the Apache License, Version 2.0 (the "License");
  * you may not use this file except in compliance with the License.
  * You may obtain a copy of the License at:
@@ -416,6 +416,7 @@ struct ovn_datapath {
 /* The "derived" OVN port representing the instance of l3dgw_port on
  * the "redirect-chassis". */
 struct ovn_port *l3redirect_port;
+struct ovn_port *localnet_port;
 };
 
 struct macam_node {
@@ -1351,6 +1352,10 @@ join_logical_ports(struct northd_context *ctx,
 ovs_list_push_back(nb_only, >list);
 }
 
+if (!strcmp(nbsp->type, "localnet")) {
+   od->localnet_port = op;
+}
+
 op->lsp_addrs
 = xmalloc(sizeof *op->lsp_addrs * nbsp->n_addresses);
 for (size_t j = 0; j < nbsp->n_addresses; j++) {
@@ -2629,6 +2634,23 @@ build_pre_acls(struct ovn_datapath *od, struct hmap 
*lflows)
 ds_destroy(_in);
 ds_destroy(_out);
 }
+if (od->localnet_port) {
+struct ds match_in = DS_EMPTY_INITIALIZER;
+struct ds match_out = DS_EMPTY_INITIALIZER;
+
+ds_put_format(_in, "ip && inport == %s",
+  od->localnet_port->json_key);
+ds_put_format(_out, "ip && outport == %s",
+  od->localnet_port->json_key);
+ovn_lflow_add(lflows, od, S_SWITCH_IN_PRE_ACL, 110,
+  ds_cstr(_in), "next;");
+ovn_lflow_add(lflows, od, S_SWITCH_OUT_PRE_ACL, 110,
+  ds_cstr(_out), "next;");
+
+ds_destroy(_in);
+ds_destroy(_out);
+}
+
 /* Ingress and Egress Pre-ACL Table (Priority 110).
  *
  * Not to do conntrack on ND packets. */
-- 
2.7.2.windows.1
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] 答复: [spam可疑邮件]Re: 答复: [spam可疑邮件]Re: [PATCH] ovn-northd: Fix ping failure of vlan networks.

2017-05-31 Thread wang . qianyu

Thanks for you rapidly reply.

We think localnet port never be the real destination port of vm instance. 
Like patch port of route, localnet port just used for interim.

And nouse of ct to localnet will not cause the bypass of firewall. Because 
of the real destination  port of vm1 or vm2 have their own ct.

The introducing of same port or same zone in different networks maybe not 
suitable, this is not consensus with the isolation of networks.

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

[ovs-dev] [PATCH] ovn-northd: Fix ping failure of vlan networks.

2017-05-22 Thread wang . qianyu

There are two computer node, each have one vm. And the two vms in 
indifferent vlan networks. The ping between the vms is not success.

The reason is that, acl of to-localnet port or from-localnet port is
signed to contrack. So the pair of icmp request and reply have different
zone id in one ovs node. This makes the ct state not correct.

This patch do the modification that localnet port do not use ct.

Signed-off-by: wangqianyu 
---
 ovn/northd/ovn-northd.c | 22 +-
 1 file changed, 21 insertions(+), 1 deletion(-)

diff --git a/ovn/northd/ovn-northd.c b/ovn/northd/ovn-northd.c
index 83db753..5d1587e 100644
--- a/ovn/northd/ovn-northd.c
+++ b/ovn/northd/ovn-northd.c
@@ -1,4 +1,4 @@
-/*
+/*
  * Licensed under the Apache License, Version 2.0 (the "License");
  * you may not use this file except in compliance with the License.
  * You may obtain a copy of the License at:
@@ -416,6 +416,7 @@ struct ovn_datapath {
 /* The "derived" OVN port representing the instance of l3dgw_port on
  * the "redirect-chassis". */
 struct ovn_port *l3redirect_port;
+struct ovn_port *localnet_port;
 };
 
 struct macam_node {
@@ -1351,6 +1352,10 @@ join_logical_ports(struct northd_context *ctx,
 ovs_list_push_back(nb_only, >list);
 }
 
+if(!strcmp(nbsp->type, "localnet")) {
+   od->localnet_port = op;
+}
+
 op->lsp_addrs
 = xmalloc(sizeof *op->lsp_addrs * nbsp->n_addresses);
 for (size_t j = 0; j < nbsp->n_addresses; j++) {
@@ -2629,6 +2634,21 @@ build_pre_acls(struct ovn_datapath *od, struct hmap 
*lflows)
 ds_destroy(_in);
 ds_destroy(_out);
 }
+if(od->localnet_port) {
+struct ds match_in = DS_EMPTY_INITIALIZER;
+struct ds match_out = DS_EMPTY_INITIALIZER;
+
+ds_put_format(_in, "ip && inport == %s", 
od->localnet_port->json_key);
+ds_put_format(_out, "ip && outport == %s", 
od->localnet_port->json_key);
+ovn_lflow_add(lflows, od, S_SWITCH_IN_PRE_ACL, 110,
+  ds_cstr(_in), "next;");
+ovn_lflow_add(lflows, od, S_SWITCH_OUT_PRE_ACL, 110,
+  ds_cstr(_out), "next;");
+
+ds_destroy(_in);
+ds_destroy(_out);
+}
+
 /* Ingress and Egress Pre-ACL Table (Priority 110).
  *
  * Not to do conntrack on ND packets. */
-- 
2.7.2.windows.1



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

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

2017-05-08 Thread wang . qianyu

ovn-controller-vtep could only be used to forwards traffic between 
networks managed by openstack and physical network openstack not managed. 
We want to use ovn in the scenary that ovs-computer node and sriov 
computer node all managed by openstack. 
Waiting for your suggestions.
Thanks

Macauley Cheng <macauley_ch...@accton.com>
2017/05/09 11:16

收件人："wang.qia...@zte.com.cn" <wang.qia...@zte.com.cn>, 
"ovs-dev-boun...@openvswitch.org" <ovs-dev-boun...@openvswitch.org>, 
"b...@ovn.org" <b...@ovn.org>, "mickeys@gmail.com" 
<mickeys@gmail.com>, 
抄送：  ovs dev <d...@openvswitch.org>, "xu.r...@zte.com.cn" 
<xu.r...@zte.com.cn>, "ovs-dev-boun...@openvswitch.org" 
<ovs-dev-boun...@openvswitch.org>
主题：  RE: [ovs-dev] 答复: Re: 答复: Re: 答复: Re: 
[PATCH] ovn-controller: Support vxlan tunnel in ovn

Hi Qianyu,
Did you try the ovn-controller-vtep before?
You can use the ovn-controller-vtep with HW switch to setup the vxlan 
tunnel with host which run ovn-controller.

-Original Message-
From: ovs-dev-boun...@openvswitch.org [
mailto:ovs-dev-boun...@openvswitch.org] On Behalf Of 
wang.qia...@zte.com.cn
Sent: Tuesday, May 09, 2017 9:29 AM
To: ovs-dev-boun...@openvswitch.org; b...@ovn.org; mickeys@gmail.com
Cc: ovs dev; xu.r...@zte.com.cn; ovs-dev-boun...@openvswitch.org
Subject: [ovs-dev] 答复: Re: 答复: Re: 答复: Re: [PATCH] ovn-controller: 
Support vxlan tunnel in ovn

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@gmail.com>
发件人： ovs-dev-boun...@openvswitch.org
2017/05/08 04:58

收件人：xu.r...@zte.com.cn, 
抄送：  ovs dev <d...@openvswitch.org>, 
ovs-dev-boun...@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.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)
>

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.

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

2017-05-08 Thread wang . qianyu

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@gmail.com>
发件人： ovs-dev-boun...@openvswitch.org
2017/05/08 04:58

收件人：xu.r...@zte.com.cn, 
抄送：  ovs dev <d...@openvswitch.org>, 
ovs-dev-boun...@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.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)
>

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 por

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

43 matches

Mail list logo