date:20170123

Acked-by: Jarno Rajahalme 

> On Jan 20, 2017, at 6:05 PM, Andy Zhou  wrote:
> 
> When ofproto probe for datapath features, no packets should actually
> be sent to the network. This pactch fixes the userspace by dropping
> probe packets before action execution.
> 
> Signed-off-by: Andy Zhou 
> ---
> lib/dpif-netdev.c | 7 +++
> 1 file changed, 7 insertions(+)
> 
> diff --git a/lib/dpif-netdev.c b/lib/dpif-netdev.c
> index 3901129..9c21af3 100644
> --- a/lib/dpif-netdev.c
> +++ b/lib/dpif-netdev.c
> @@ -2660,6 +2660,13 @@ dpif_netdev_execute(struct dpif *dpif, struct 
> dpif_execute *execute)
> }
> }
> 
> +if (execute->probe) {
> +/* If this is part of a probe, Drop the packet, since executing
> + * the action may actually cause spurious packets be sent into
> + * the network. */
> +return 0;
> +}
> +
> /* If the current thread is non-pmd thread, acquires
>  * the 'non_pmd_mutex'. */
> if (pmd->core_id == NON_PMD_CORE_ID) {
> -- 
> 1.9.1
> 
> ___
> 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] [patch_v2 2/3] Userspace Datapath: Introduce NAT support.

This patch introduces NAT support for the userspace datapath.

The per packet scope of lookups for NAT and un_NAT is at
the bucket level rather than global. One hash table is
introduced to support create/delete handling. The create/delete
events may be further optimized, if the need becomes clear.

Some NAT options with limited utility (persistent, random) are
not supported yet, but will be supported in a later patch.

Signed-off-by: Darrell Ball 
---
 lib/conntrack-private.h |  25 +-
 lib/conntrack.c | 724 ++--
 lib/conntrack.h |  81 +-
 lib/dpif-netdev.c   |  85 +-
 tests/test-conntrack.c  |   8 +-
 5 files changed, 819 insertions(+), 104 deletions(-)

diff --git a/lib/conntrack-private.h b/lib/conntrack-private.h
index 013f19f..b71af37 100644
--- a/lib/conntrack-private.h
+++ b/lib/conntrack-private.h
@@ -29,15 +29,6 @@
 #include "packets.h"
 #include "unaligned.h"
 
-struct ct_addr {
-union {
-ovs_16aligned_be32 ipv4;
-union ovs_16aligned_in6_addr ipv6;
-ovs_be32 ipv4_aligned;
-struct in6_addr ipv6_aligned;
-};
-};
-
 struct ct_endpoint {
 struct ct_addr addr;
 union {
@@ -60,14 +51,23 @@ struct conn_key {
 uint16_t zone;
 };
 
+struct nat_conn_key_node {
+struct hmap_node node;
+struct conn_key key;
+struct conn_key value;
+};
+
 struct conn {
 struct conn_key key;
 struct conn_key rev_key;
 long long expiration;
 struct ovs_list exp_node;
 struct hmap_node node;
-uint32_t mark;
 ovs_u128 label;
+/* XXX: consider flattening. */
+struct nat_action_info_t *nat_info;
+uint32_t mark;
+uint8_t conn_type;
 };
 
 enum ct_update_res {
@@ -76,6 +76,11 @@ enum ct_update_res {
 CT_UPDATE_NEW,
 };
 
+enum ct_conn_type {
+CT_CONN_TYPE_DEFAULT,
+   CT_CONN_TYPE_UN_NAT,
+};
+
 struct ct_l4_proto {
 struct conn *(*new_conn)(struct conntrack_bucket *, struct dp_packet *pkt,
  long long now);
diff --git a/lib/conntrack.c b/lib/conntrack.c
index 9bea3d9..85fd941 100644
--- a/lib/conntrack.c
+++ b/lib/conntrack.c
@@ -76,6 +76,20 @@ static void set_label(struct dp_packet *, struct conn *,
   const struct ovs_key_ct_labels *mask);
 static void *clean_thread_main(void *f_);
 
+static struct nat_conn_key_node *
+nat_conn_keys_lookup(struct hmap *nat_conn_keys,
+ const struct conn *conn,
+ uint32_t basis);
+
+static void
+nat_conn_keys_remove(struct hmap *nat_conn_keys,
+const struct conn *conn,
+uint32_t basis);
+
+static bool
+nat_select_range_tuple(struct conntrack *ct, const struct conn *conn,
+  struct conn *rev_conn);
+
 static struct ct_l4_proto *l4_protos[] = {
 [IPPROTO_TCP] = _proto_tcp,
 [IPPROTO_UDP] = _proto_other,
@@ -90,7 +104,7 @@ long long ct_timeout_val[] = {
 };
 
 /* If the total number of connections goes above this value, no new connections
- * are accepted */
+ * are accepted; this is for CT_CONN_TYPE_DEFAULT connections. */
 #define DEFAULT_N_CONN_LIMIT 300
 
 /* Initializes the connection tracker 'ct'.  The caller is responsible for
@@ -101,6 +115,11 @@ conntrack_init(struct conntrack *ct)
 unsigned i, j;
 long long now = time_msec();
 
+ct_rwlock_init(>nat_resources_lock);
+ct_rwlock_wrlock(>nat_resources_lock);
+hmap_init(>nat_conn_keys);
+ct_rwlock_unlock(>nat_resources_lock);
+
 for (i = 0; i < CONNTRACK_BUCKETS; i++) {
 struct conntrack_bucket *ctb = >buckets[i];
 
@@ -139,13 +158,24 @@ conntrack_destroy(struct conntrack *ct)
 ovs_mutex_destroy(>cleanup_mutex);
 ct_lock_lock(>lock);
 HMAP_FOR_EACH_POP(conn, node, >connections) {
-atomic_count_dec(>n_conn);
+if (conn->conn_type == CT_CONN_TYPE_DEFAULT) {
+atomic_count_dec(>n_conn);
+}
 delete_conn(conn);
 }
 hmap_destroy(>connections);
 ct_lock_unlock(>lock);
 ct_lock_destroy(>lock);
 }
+ct_rwlock_wrlock(>nat_resources_lock);
+struct nat_conn_key_node *nat_conn_key_node;
+HMAP_FOR_EACH_POP(nat_conn_key_node, node, >nat_conn_keys) {
+free(nat_conn_key_node);
+}
+hmap_destroy(>nat_conn_keys);
+ct_rwlock_unlock(>nat_resources_lock);
+ct_rwlock_destroy(>nat_resources_lock);
+
 }
 
 static unsigned hash_to_bucket(uint32_t hash)
@@ -167,10 +197,175 @@ write_ct_md(struct dp_packet *pkt, uint16_t state, 
uint16_t zone,
 pkt->md.ct_label = label;
 }
 
+static void
+nat_packet(struct dp_packet *pkt, const struct conn *conn, uint16_t *state)
+{
+if (conn->nat_info->nat_action & NAT_ACTION_SRC) {
+   *state |= CS_SRC_NAT;
+if (conn->key.dl_type == htons(ETH_TYPE_IP)) {
+struct ip_header *nh = dp_packet_l3(pkt);
+packet_set_ipv4_addr(pkt,

[ovs-dev] [patch_v2 1/3] Export packet_set_ipv6_addr() for dpdkdatapath.

Signed-off-by: Darrell Ball 
---
 lib/packets.c | 2 +-
 lib/packets.h | 4 
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/lib/packets.c b/lib/packets.c
index fa70df6..94e7d87 100644
--- a/lib/packets.c
+++ b/lib/packets.c
@@ -986,7 +986,7 @@ packet_update_csum128(struct dp_packet *packet, uint8_t 
proto,
 }
 }
 
-static void
+void
 packet_set_ipv6_addr(struct dp_packet *packet, uint8_t proto,
  ovs_16aligned_be32 addr[4],
  const struct in6_addr *new_addr,
diff --git a/lib/packets.h b/lib/packets.h
index c4d3799..850f192 100644
--- a/lib/packets.h
+++ b/lib/packets.h
@@ -1100,6 +1100,10 @@ void packet_set_ipv4_addr(struct dp_packet *packet, 
ovs_16aligned_be32 *addr,
 void packet_set_ipv6(struct dp_packet *, const struct in6_addr *src,
  const struct in6_addr *dst, uint8_t tc,
  ovs_be32 fl, uint8_t hlmit);
+void packet_set_ipv6_addr(struct dp_packet *packet, uint8_t proto,
+  ovs_16aligned_be32 addr[4],
+  const struct in6_addr *new_addr,
+  bool recalculate_csum);
 void packet_set_tcp_port(struct dp_packet *, ovs_be16 src, ovs_be16 dst);
 void packet_set_udp_port(struct dp_packet *, ovs_be16 src, ovs_be16 dst);
 void packet_set_sctp_port(struct dp_packet *, ovs_be16 src, ovs_be16 dst);
-- 
1.9.1

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

[ovs-dev] [patch_v2 3/3] Enable NAT tests for userspace datapath.

Signed-off-by: Darrell Ball 
---
 tests/system-userspace-macros.at | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/tests/system-userspace-macros.at b/tests/system-userspace-macros.at
index 631f71a..6e3d468 100644
--- a/tests/system-userspace-macros.at
+++ b/tests/system-userspace-macros.at
@@ -99,9 +99,6 @@ m4_define([CHECK_CONNTRACK_LOCAL_STACK],
 # CHECK_CONNTRACK_NAT()
 #
 # Perform requirements checks for running conntrack NAT tests. The userspace
-# doesn't support NATs yet, so skip the tests
+# datapath supports NAT.
 #
-m4_define([CHECK_CONNTRACK_NAT],
-[
-AT_SKIP_IF([:])
-])
+m4_define([CHECK_CONNTRACK_NAT])
-- 
1.9.1

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

[ovs-dev] [patch_v2 0/3] Userspace Datapath: introduce NAT support.

This patch series introduces NAT support for the userspace datapath.

The per packet scope of lookups for NAT and un_NAT is at
the bucket level rather than global. One hash table is 
introduced to support create/delete handling. The create/delete
events may be further optimized, if the need becomes clear.

The existing NAT tests are enabled for the dpdk datapath.

Some NAT options with limited utility (persistent, random) are
not supported yet, but will be supported in a later patch.

Enforcement of a capping of a max delta of nat ipv6 addresses to
4 billion needs to be done. I have not done it yet as I want
to confirm the form of user visibility.

One V6 api is exported to facilitate selective editing the V6
header - packet_set_ipv6_addr().

alg and fragmentation support are not included here but are
being worked on.

NEWS is not updated in this series yet, until confirmation of
release.

I realize patch 2 is big. It may be clearer and easier to keep
as a single patch, so I have done that after some discussion.

v1->v2: Updates/fixes that were missed in v1 patches.

Darrell Ball (3):
  Export packet_set_ipv6_addr() for dpdkdatapath.
  Userspace Datapath: Introduce NAT support.
  Enable NAT tests for userspace datapath.

 lib/conntrack-private.h  |  25 +-
 lib/conntrack.c  | 724 ++-
 lib/conntrack.h  |  81 -
 lib/dpif-netdev.c|  85 -
 lib/packets.c|   2 +-
 lib/packets.h|   4 +
 tests/system-userspace-macros.at |   7 +-
 tests/test-conntrack.c   |   8 +-
 8 files changed, 826 insertions(+), 110 deletions(-)

-- 
1.9.1

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

Re: [ovs-dev] [PATCH ovs V2 03/21] other-config: Add hw-offload switch to control netdev flow offloading

2017-01-23 Thread Joe Stringer

On 22 January 2017 at 08:13, Paul Blakey  wrote:
>
>
> On 05/01/2017 03:26, Joe Stringer wrote:
>>
>> On 25 December 2016 at 03:39, Paul Blakey  wrote:
>>>
>>> Add a new configuration option - hw-offload that enables netdev
>>> flow api. Enabling this option will allow offloading flows
>>> using netdev implementation instead of the kernel datapath.
>>> This configuration option defaults to false - disabled.
>>>
>>> Signed-off-by: Paul Blakey 
>>> Reviewed-by: Roi Dayan 
>>> ---
>>>  lib/netdev.c | 18 ++
>>>  lib/netdev.h |  2 ++
>>>  vswitchd/bridge.c|  2 ++
>>>  vswitchd/vswitch.xml | 11 +++
>>>  4 files changed, 33 insertions(+)
>>>
>>> diff --git a/lib/netdev.c b/lib/netdev.c
>>> index 3ac3c48..b289166 100644
>>> --- a/lib/netdev.c
>>> +++ b/lib/netdev.c
>>> @@ -2071,7 +2071,25 @@ netdev_init_flow_api(struct netdev *netdev)
>>>  {
>>>  const struct netdev_class *class = netdev->netdev_class;
>>>
>>> +if (!netdev_flow_api_enabled) {
>>> +return EOPNOTSUPP;
>>> +}
>>> +
>>>  return (class->init_flow_api
>>>  ? class->init_flow_api(netdev)
>>>  : EOPNOTSUPP);
>>>  }
>>> +
>>> +bool netdev_flow_api_enabled = false;
>>> +
>>> +void
>>> +netdev_set_flow_api_enabled(bool enabled)
>>> +{
>>> +static struct ovsthread_once once = OVSTHREAD_ONCE_INITIALIZER;
>>> +
>>> +if (ovsthread_once_start()) {
>>> +netdev_flow_api_enabled = enabled;
>>> +VLOG_INFO("netdev: Flow API %s", enabled ? "Enabled" :
>>> "Disabled");
>>> +ovsthread_once_done();
>>> +}
>>> +}
>>
>>
>> Requiring restart to apply this option seems a bit arbitrary, why not
>> allow it to be changed at runtime?
>>
>
> Because it isn't something that is supposed to change often,
> It might cause problems if its enabled later on with different (netdev)
> implementations. We can try and test changing it to runtime at a later time.

Forcing the user to restart OVS to make a database setting take effect
is an unusual requirement. Even uncommon configurations that require
datapath-level changes (eg, reconfiguring queues) is applied in OVS
without requiring the user to intervene and restart. I understand that
even DPDK init doesn't require restart any more.

Here's another question: Let's say that hardware offloads is enabled
and traffic runs. User turns it off, restarts OVS. What happens to the
hardware flows? Presumably OVS doesn't manage them any more because
hw-offloads is off, but they would continue to forward traffic. If OVS
then gets different OpenFlow rules then the forwarding could be wrong.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH v2 1/2] tunneling: Avoid recirculation on datapath by computing the recirculate actions at translate time.


> On Jan 22, 2017, at 5:50 AM, Jan Scheurich  wrote:
> 
> How does the dpif-netdev CLONE action introduced here relate to the similar 
> action already introduced in the context of the OpenFLow CLONE action (see 
> for example 
> https://mail.openvswitch.org/pipermail/ovs-dev/2017-January/327808.html).
> 

OpenFlow level clone action was added a bit earlier, the email you refer to is 
a dpif-netdev level clone action.

> I assume these do comparable things and the native tunnel implementation 
> should re-use the new CLONE action.
> 

This is true. There were other needs for the datapath level clone action, and 
once that is merged this patch series should rebase to that.

  Jarno

> /Jan
> 
> On 2017-01-20 14:40, Zoltán Balogh wrote:
>> From: Sugesh Chandran 
>> 
>> Openvswitch datapath recirculates packets for tunneling, i.e.
>> the incoming packets are encapsulated at first pass. Further actions are
>> applied on encapsulated packets on the second pass after recirculating.
>> The proposed patch compute and append the post tunnel actions at the time of
>> translation itself instead of recirculating at datapath. These actions are 
>> solely
>> depends on tunnel attributes so there is no need of datapath recirculation.
>> By avoiding the recirculation at datapath, the patch offers upto 30%
>> performance improvement for VxLAN tunneling in our testing.
>> The action execution logic is also extended with new CLONE action to define
>> the packet cloning when the actions are combined. The lenght in the CLONE
>> action specifies the size of nested action set.
>> 
>> Signed-off-by: Sugesh Chandran 
>> Signed-off-by: Zoltán Balogh 
>> Co-authored-by: Zoltán Balogh 
>> ---
>>  datapath/linux/compat/include/linux/openvswitch.h |   1 +
>>  lib/dpif-netdev.c |  20 +-
>>  lib/dpif.c|   1 +
>>  lib/odp-execute.c |  57 -
>>  lib/odp-util.c|  96 +++-
>>  lib/odp-util.h|   5 +
>>  ofproto/ofproto-dpif-sflow.c  |   1 +
>>  ofproto/ofproto-dpif-xlate.c  | 267 
>> +++---
>>  8 files changed, 288 insertions(+), 160 deletions(-)
>> 
>> diff --git a/datapath/linux/compat/include/linux/openvswitch.h 
>> b/datapath/linux/compat/include/linux/openvswitch.h
>> index 12260d8..91849d6 100644
>> --- a/datapath/linux/compat/include/linux/openvswitch.h
>> +++ b/datapath/linux/compat/include/linux/openvswitch.h
>> @@ -818,6 +818,7 @@ enum ovs_action_attr {
>>  #ifndef __KERNEL__
>>  OVS_ACTION_ATTR_TUNNEL_PUSH,   /* struct ovs_action_push_tnl*/
>>  OVS_ACTION_ATTR_TUNNEL_POP,/* u32 port number. */
>> +OVS_ACTION_ATTR_CLONE,
>>  #endif
>>  __OVS_ACTION_ATTR_MAX,/* Nothing past this will be accepted
>> * from userspace. */
>> diff --git a/lib/dpif-netdev.c b/lib/dpif-netdev.c
>> index 3901129..0b85fe4 100644
>> --- a/lib/dpif-netdev.c
>> +++ b/lib/dpif-netdev.c
>> @@ -4547,24 +4547,8 @@ dp_execute_cb(void *aux_, struct dp_packet_batch 
>> *packets_,
>>case OVS_ACTION_ATTR_TUNNEL_PUSH:
>>  if (*depth < MAX_RECIRC_DEPTH) {
>> -struct dp_packet_batch tnl_pkt;
>> -struct dp_packet_batch *orig_packets_ = packets_;
>> -int err;
>> -
>> -if (!may_steal) {
>> -dp_packet_batch_clone(_pkt, packets_);
>> -packets_ = _pkt;
>> -dp_packet_batch_reset_cutlen(orig_packets_);
>> -}
>> -
>>  dp_packet_batch_apply_cutlen(packets_);
>> -
>> -err = push_tnl_action(pmd, a, packets_);
>> -if (!err) {
>> -(*depth)++;
>> -dp_netdev_recirculate(pmd, packets_);
>> -(*depth)--;
>> -}
>> +push_tnl_action(pmd, a, packets_);
>>  return;
>>  }
>>  break;
>> @@ -4714,6 +4698,8 @@ dp_execute_cb(void *aux_, struct dp_packet_batch 
>> *packets_,
>>  break;
>>  }
>>  +case OVS_ACTION_ATTR_CLONE:
>> +break;
>>  case OVS_ACTION_ATTR_PUSH_VLAN:
>>  case OVS_ACTION_ATTR_POP_VLAN:
>>  case OVS_ACTION_ATTR_PUSH_MPLS:
>> diff --git a/lib/dpif.c b/lib/dpif.c
>> index 50c3382..b698da2 100644
>> --- a/lib/dpif.c
>> +++ b/lib/dpif.c
>> @@ -1183,6 +1183,7 @@ dpif_execute_helper_cb(void *aux_, struct 
>> dp_packet_batch *packets_,
>>  case OVS_ACTION_ATTR_SAMPLE:
>>  case OVS_ACTION_ATTR_TRUNC:
>>  case OVS_ACTION_ATTR_UNSPEC:
>> +case OVS_ACTION_ATTR_CLONE:
>>  case __OVS_ACTION_ATTR_MAX:
>>  OVS_NOT_REACHED();
>>  }
>> diff --git a/lib/odp-execute.c b/lib/odp-execute.c
>> index 73e1016..77bca94 100644
>> --- a/lib/odp-execute.c
>> +++

[ovs-dev] Fwd: [PATCH] datapath: internal-dev: Disable rtnl_link_ops register under linux < 3.17

Thomas & Pravin,

Apparently the commit 5282e284ac57 (“datapath: introduce rtnl ops stub”) 
applied to OVS two years ago is not compatible with Linux 3.16 or earlier, as 
the corresponding upstream change was only applied in Linux 3.17. For Linux 
3.16 and earlier, in your opinion, is the right solution to effectively revert 
this commit, or would there be a way to make the ops stub compatible with these 
Linux versions by somehow amending the stub (.setup, .dellink, etc.)?

  Jarno

> Begin forwarded message:
> 
> From: Markos Chandras 
> Subject: Re: [ovs-dev] [PATCH] datapath: internal-dev: Disable rtnl_link_ops 
> register under linux < 3.17
> Date: January 23, 2017 at 7:13:03 AM PST
> To: ovs-dev@openvswitch.org
> 
> Hi,
> 
> On 12/14/2016 03:44 AM, Zhang Dongya wrote:
>> From: "fortitude.zhang" 
>> 
>> Under linux < 3.17, b0ab2fabb5b91da99c189db02e91ae10bc8355c5 is not 
>> introduced,
>> which allow internal-dev created by openvswitch datapath deleted by using 
>> rtnl
>> interface, this causes data related to internal-dev not freed and stops 
>> datapath
>> working correctly.
>> 
>> Signed-off-by: fortitude.zhang 
> 
> I recently encountered this bug and this commit fixed it for me. So...
> 
> Tested-by: Markos Chandras 
> 
> It might also worth backporting it to stable branches as well.
> 
> -- 
> markos
> 
> SUSE LINUX GmbH | GF: Felix Imendörffer, Jane Smithard, Graham Norton
> HRB 21284 (AG Nürnberg) Maxfeldstr. 5, D-90409, Nürnberg
> ___
> 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

Re: [ovs-dev] [PATCH v2] ovn: Document upgrade procedure.

On Mon, Jan 23, 2017 at 11:36 AM, Ben Pfaff  wrote:

> On Mon, Jan 23, 2017 at 09:50:02AM -0500, Russell Bryant wrote:
> > Signed-off-by: Russell Bryant 
>
> Thanks Russell!
>
> s/its/it's/ here:
> > +You should start by upgrading ovn-controller on each host its running
> on.
>
> Acked-by: Ben Pfaff 
>

Fixed the typo and applied to branch-2.7 and master.

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

Re: [ovs-dev] OVS - ODL Sync on OF Bundle in 1.3


> On Jan 23, 2017, at 9:01 AM, Jan Scheurich  wrote:
> 
> Hi,
>  
> Here are the main differences I have found between the ONF Bundle extension 
> (EXT-230) to OF 1.3 and the OF Bundle specified in OF 1.5.1:
>  
> No OFPC_BUNDLES bit in ofp_capabilities to indicate switch support for 
> bundles.

We support this for OpenFlow 1.4 and later.

> Bundle Features MP message not supported

OVS does not implement this for any OpenFlow version yet.

> No support for scheduled bundles

These are also not implemented.

  Jarno

> ONF Experimenter messages 2300 (ONF_ET_BUNDLE_CONTROL) and 2301 
> (ONF_ET_BUNDLE_ADD_MESSAGE) instead of standard OFP messages 33 
> (OFP_BUNDLE_CONTROL) and 34 (OFP_ BUNDLE_ADD_MESSAGE). 
> Other than that the message syntax and semantics seem identical
> ONF experimenter error codes for bundles errors in the range 2300-2315 
> instead of standard error codes 0-15 for error type OFPET_BUNDLE_FAILED. 
> Otherwise same meaning.
>  
> Inside OVS it seems that standard OF 1.5 and OF 1.3 extension messages are 
> internally mapped to a common message type. Errors are mapped back to 
> standard OFP error (type, code) for OF 1.5 and experimenter error type in OF 
> 1.3.
>  
> So, the OVS bundle implementation for OF 1.3 should be faithful to EXT-230.
>  
> BR, Jan
>  
> -Original Appointment-
> From: Jan Scheurich 
> Sent: Wednesday, 18 January, 2017 16:23
> To: Jan Scheurich; Abhijit Kumbhare; Zoltán Balogh; László Sürü; Miklós 
> Pelyva; Jozef Bacigál; Tomáš Slušný; Prasanna Huddar; Shuva Jyoti Kar; 
> Sharath Kumar V; Kanagasundaram K; Sunil Kumar G; D Arunprakash; Muthukumaran 
> K; Jarno Rajahalme (ja...@ovn.org 
> );d...@openvswitch.org 
> Subject: OVS - ODL Sync on OF Bundle in 1.3 
> When: Monday, 23 January, 2017 17:00-18:00 (UTC+01:00) Amsterdam, Berlin, 
> Bern, Rome, Stockholm, Vienna.
> Where: Skype Meeting
>  
>  
>  <>Hi Jarno,
>  
> OpenDaylight folks are finally starting to implement support of OpenFlow 
> bundles as a basis for the bundle-based hitless recync procedure we discussed 
> earlier. As ODL does not yet have protocol support for OpenFlow versions 1.4 
> or 1.5, they intend to implement the bundle extension to OF 1.3 as specified 
> in EXT-230 in 
> https://www.opennetworking.org/images/stories/downloads/sdn-resources/onf-specifications/openflow/openflow-extensions-1.3.x-pack2.zip
>  
> 
>  
> Would you have time for a short meeting on early Monday to discuss and 
> confirm whether the OVS implementation of bundles in OF 1.3 is compliant with 
> EXT-230 and has everything they need?
>  
> Thanks, Jan
>  
>  
> .
>  <>à Join Skype Meeting    
> <><>
> This is an online meeting for Skype for Business, the professional meetings 
> and communications app formerly known as Lync.
> Join by phone
>  
> +492115343925  (Germany)  English 
> (United States) 
> 89925  (Germany)  English (United States)
>  
> Find a local number 
>  
> Conference ID: 64134840
> Forgot your dial-in PIN?  |Help 
>   
>  
>  
> To join a Lync / Skype for Business meeting from an Ericsson standard video 
> room, add 77 before the Conference ID (e.g. 771234567 where 1234567 is the 
> conference ID).To join from a video room outside of Ericsson add one of 
> the domains after 77 and Conference ID (e.g. 771234567@ .ericsson.net, 
> where =emea/apac/amcs).  For assistance contact the IT Service Desk. 
> [!OC([1033])!]
> .

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

Re: [ovs-dev] [PATCH] doc: Remove tutorials/ovn-basics.

On Mon, Jan 23, 2017 at 11:25 AM, Ben Pfaff  wrote:

> On Mon, Jan 23, 2017 at 09:02:07AM -0500, Russell Bryant wrote:
> > On Thu, Jan 19, 2017 at 6:01 PM, Ben Pfaff  wrote:
> >
> > > On Thu, Jan 19, 2017 at 02:17:09PM -0500, Russell Bryant wrote:
> > > > The only thing worse than a lack of documentation is incorrect or
> > > > out-of-date documentation.  Over time, this document has not kept up
> with
> > > > the pace of OVN and is no longer a good current resource.
> > > >
> > > > For a sandbox based tutorial like this, I'd like to start over using
> > > > ovn-trace as the basis.
> > > >
> > > > An even more important type of tutorial would be something along the
> > > lines
> > > > of: http://blog.spinhirne.com/p/blog-series.html
> > > >
> > > > That blog series was fantastic and has been the primary tutorial
> > > reference
> > > > I have been sending people to since it was written.
> > > >
> > > > Signed-off-by: Russell Bryant 
> > >
> > > I'm a little sad to see this go, but if it's no longer a good
> > > introduction then it has to happen.  Thank you for all the work on it.
> > >
> >
> > Thanks.  I'm actually happy that OVN has progressed quickly and we have
> > much better tools for working with OVN and analyzing flows now.  :-)
> >
> > If I put energy into this, I'd like to write a tutorial around ovn-trace.
> > Thanks for all the work you put into that!
>
> You're welcome!
>
> It sounds possible that OVS/OVN will have a 3-hour tutorial slot at ONS
> in April.  If so, we'll need to write a tutorial.  Maybe we can
> collaborate.
>

Sure.  The dates aren't great for me to be there in person (conflict with
wedding anniversary), but I'd certainly be happy to collaborate on content.

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

Re: [ovs-dev] [PATCH 3/3] ovs-router: introduce pkt-mark.


> On Dec 28, 2016, at 1:44 AM, Pravin B Shelar  wrote:
> 
> OVS router is basically partial copy of linux kernel FIB.
> kernel routing table use skb-mark along with usual routing

“use”->”uses”

Could you elaborate a bit here, is the kernel doing a simple exact match of the 
whole mark? Is the value 0 special in any way?

> parameters. Following patch brings in support for skb-mark
> to ovs-router so that we can lookup route according to
> flow skb-mark.
> 

So by default we use the flow’s skb_mark, but if the ‘egress_pkt_mark’ is set, 
then we use that?

> Signed-off-by: Pravin B Shelar 
> ---
> lib/netdev-vport.c   |   4 +-
> lib/ovs-router.c | 192 ++-
> lib/ovs-router.h |   6 +-
> lib/route-table.c|   2 +-
> ofproto/ofproto-dpif-sflow.c |   2 +-
> ofproto/ofproto-dpif-xlate.c |   2 +-
> tests/ovs-router.at  |  22 +
> tests/tunnel-push-pop.at |   3 +
> 8 files changed, 188 insertions(+), 45 deletions(-)
> 
> diff --git a/lib/netdev-vport.c b/lib/netdev-vport.c
> index 25dd0e8..54db559 100644
> --- a/lib/netdev-vport.c
> +++ b/lib/netdev-vport.c
> @@ -259,10 +259,12 @@ tunnel_check_status_change__(struct netdev_vport 
> *netdev)
> bool status = false;
> struct in6_addr *route;
> struct in6_addr gw;
> +uint32_t mark;
> 
> iface[0] = '\0';
> route = >tnl_cfg.ipv6_dst;
> -if (ovs_router_lookup(route, iface, NULL, )) {
> +mark = netdev->tnl_cfg.egress_pkt_mark;
> +if (ovs_router_lookup(mark, route, iface, NULL, )) {
> struct netdev *egress_netdev;
> 
> if (!netdev_open(iface, NULL, _netdev)) {
> diff --git a/lib/ovs-router.c b/lib/ovs-router.c
> index 935b60a..7300b36 100644
> --- a/lib/ovs-router.c
> +++ b/lib/ovs-router.c
> @@ -45,6 +45,11 @@
> #include "unaligned.h"
> #include "unixctl.h"
> #include "util.h"
> +#include "openvswitch/vlog.h"
> +
> +VLOG_DEFINE_THIS_MODULE(ovs_route);
> +

This should be ‘ovs_router’ instead.

> +static struct vlog_rate_limit rl = VLOG_RATE_LIMIT_INIT(1, 5);
> 
> static struct ovs_mutex mutex = OVS_MUTEX_INITIALIZER;
> static struct classifier cls;
> @@ -57,6 +62,7 @@ struct ovs_router_entry {
> struct in6_addr src_addr;
> uint8_t plen;
> uint8_t priority;
> +uint32_t mark;
> };
> 
> static struct ovs_router_entry *
> @@ -88,11 +94,12 @@ ovs_router_lookup_fallback(const struct in6_addr 
> *ip6_dst, char output_bridge[],
> }
> 
> bool
> -ovs_router_lookup(const struct in6_addr *ip6_dst, char output_bridge[],
> +ovs_router_lookup(uint32_t mark, const struct in6_addr *ip6_dst,
> +  char output_bridge[],
>   struct in6_addr *src, struct in6_addr *gw)
> {
> const struct cls_rule *cr;
> -struct flow flow = {.ipv6_dst = *ip6_dst};
> +struct flow flow = {.ipv6_dst = *ip6_dst, .pkt_mark = mark};
> 
> cr = classifier_lookup(, OVS_VERSION_MAX, , NULL);
> if (cr) {
> @@ -115,7 +122,8 @@ rt_entry_free(struct ovs_router_entry *p)
> free(p);
> }
> 
> -static void rt_init_match(struct match *match, const struct in6_addr 
> *ip6_dst,
> +static void rt_init_match(struct match *match, uint32_t mark,
> +  const struct in6_addr *ip6_dst,
>   uint8_t plen)
> {
> struct in6_addr dst;
> @@ -127,6 +135,8 @@ static void rt_init_match(struct match *match, const 
> struct in6_addr *ip6_dst,
> memset(match, 0, sizeof *match);
> match->flow.ipv6_dst = dst;
> match->wc.masks.ipv6_dst = mask;
> +match->wc.masks.pkt_mark = UINT32_MAX;
> +match->flow.pkt_mark = mark;

So by default, when the route entry does not specify a mark, an exact match on 
zero is made?

> }
> 
> static int
> @@ -178,7 +188,8 @@ out:
> }
> 
> static int
> -ovs_router_insert__(uint8_t priority, const struct in6_addr *ip6_dst,
> +ovs_router_insert__(uint32_t mark, uint8_t priority,
> +const struct in6_addr *ip6_dst,
> uint8_t plen, const char output_bridge[],
> const struct in6_addr *gw)
> {
> @@ -187,13 +198,14 @@ ovs_router_insert__(uint8_t priority, const struct 
> in6_addr *ip6_dst,
> struct match match;
> int err;
> 
> -rt_init_match(, ip6_dst, plen);
> +rt_init_match(, mark, ip6_dst, plen);
> 
> p = xzalloc(sizeof *p);
> ovs_strlcpy(p->output_bridge, output_bridge, sizeof p->output_bridge);
> if (ipv6_addr_is_set(gw)) {
> p->gw = *gw;
> }
> +p->mark = mark;
> p->nw_addr = match.flow.ipv6_dst;
> p->plen = plen;
> p->priority = priority;
> @@ -202,7 +214,12 @@ ovs_router_insert__(uint8_t priority, const struct 
> in6_addr *ip6_dst,
> err = get_src_addr(gw, output_bridge, >src_addr);
> }
> if (err) {
> +struct ds ds = DS_EMPTY_INITIALIZER;
> +
> +ipv6_format_mapped(ip6_dst, );
> +VLOG_DBG_RL(, "src addr not available for route %s", 
> ds_cstr());
>

Re: [ovs-dev] [PATCH 2/3] routing-table: parse skb-mark from RTNETLINK msg

Acked-by: Jarno Rajahalme 

> On Dec 28, 2016, at 1:44 AM, Pravin B Shelar  wrote:
> 
> Keep track of skb-mark of given RTNL routing notification.
> This will be used by next commit.
> 
> Signed-off-by: Pravin B Shelar 
> ---
> lib/route-table.c | 6 ++
> 1 file changed, 6 insertions(+)
> 
> diff --git a/lib/route-table.c b/lib/route-table.c
> index 00f95e3..61c8cd8 100644
> --- a/lib/route-table.c
> +++ b/lib/route-table.c
> @@ -45,6 +45,7 @@ struct route_data {
> struct in6_addr rta_dst; /* 0 if missing. */
> struct in6_addr rta_gw;
> char ifname[IFNAMSIZ]; /* Interface name. */
> +uint32_t mark;
> };
> 
> /* A digested version of a route message sent down by the kernel to indicate
> @@ -190,11 +191,13 @@ route_table_parse(struct ofpbuf *buf, struct 
> route_table_msg *change)
> [RTA_DST] = { .type = NL_A_U32, .optional = true  },
> [RTA_OIF] = { .type = NL_A_U32, .optional = true },
> [RTA_GATEWAY] = { .type = NL_A_U32, .optional = true },
> +[RTA_MARK] = { .type = NL_A_U32, .optional = true },
> };
> 
> static const struct nl_policy policy6[] = {
> [RTA_DST] = { .type = NL_A_IPV6, .optional = true },
> [RTA_OIF] = { .type = NL_A_U32, .optional = true },
> +[RTA_MARK] = { .type = NL_A_U32, .optional = true },
> [RTA_GATEWAY] = { .type = NL_A_IPV6, .optional = true },
> };
> 
> @@ -270,6 +273,9 @@ route_table_parse(struct ofpbuf *buf, struct 
> route_table_msg *change)
> change->rd.rta_gw = nl_attr_get_in6_addr(attrs[RTA_GATEWAY]);
> }
> }
> +if (attrs[RTA_MARK]) {
> +change->rd.mark = nl_attr_get_u32(attrs[RTA_MARK]);
> +}
> } else {
> VLOG_DBG_RL(, "received unparseable rtnetlink route message");
> return 0;
> -- 
> 2.9.3
> 
> ___
> 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

Re: [ovs-dev] [PATCH 1/3] tunnel: Add support to configure ptk_mark

2017-01-23 Thread Planifique la Capacitación de su Equipo

Pravin,

Sorry for the delay, I hope you find time to respond.

> On Dec 28, 2016, at 1:44 AM, Pravin B Shelar  wrote:
> 
> Today packet mark action is broaken for Tunnel ports with
> tunnel monitoring.

“broaken”->”broken”

Could you be more specific here. Setting packet mark works, but apparently not 
when sending the packet to a tunnel, or possibly when sending packet to a 
tunnel when tunnel monitoring (you mean BFD?). What exactly is the problem?

> User can write a flow to set pkt-mark for
> any tunnel packet generated by vswitchd itself, like BFD packets.
> 

So the problem is that if a flow sets the pkt_mark, it will be also used for 
BFD packets? Or is it that it will not be used for BFD packets? What is the 
desired behavior?

> Following patch introduces new option in OVSDB tunnel
> configuration so that user can set skb-mark for given
> tunnel endpoint. OVS would set the mark according to the
> skb-mark option for all tunnel traffic including packets
> generated by vSwitchd like tunnel monitoring BFD packet.
> 

What happens to the tunnel packet mark when the new option is not specified? Is 
that behavior changed?

> Signed-off-by: Pravin B Shelar 
> ---
> lib/netdev-vport.c   |  8 
> lib/netdev.h |  1 +
> ofproto/tunnel.c |  5 +
> tests/tunnel-push-pop.at | 16 
> vswitchd/vswitch.xml |  4 
> 5 files changed, 34 insertions(+)
> 
> diff --git a/lib/netdev-vport.c b/lib/netdev-vport.c
> index 02a246a..25dd0e8 100644
> --- a/lib/netdev-vport.c
> +++ b/lib/netdev-vport.c
> @@ -505,6 +505,10 @@ set_tunnel_config(struct netdev *dev_, const struct smap 
> *args)
> }
> 
> free(str);
> +} else if (!strcmp(node->key, "egress_pkt_mark")) {
> +char *ptr = NULL;
> +
> +tnl_cfg.egress_pkt_mark = strtoul(node->value, , 10);

Could skip the “ptr” and use NULL instead.

Should document somewhere what happens when the option is not given, which 
seems to be the same as setting the egress_pkt_mark to zero.

> } else {
> VLOG_WARN("%s: unknown %s argument '%s'", name, type, node->key);
> }
> @@ -623,6 +627,10 @@ get_tunnel_config(const struct netdev *dev, struct smap 
> *args)
> smap_add(args, "df_default", "false");
> }
> 
> +if (tnl_cfg.egress_pkt_mark) {
> +smap_add_format(args, "egress_pkt_mark",
> +"%"PRIu32, tnl_cfg.egress_pkt_mark);
> +}


Does a zero mark mean that the mark is not used? If the zero value is still 
used is leaving it out misleading?

> return 0;
> }
> 
> diff --git a/lib/netdev.h b/lib/netdev.h
> index a667fe3..5ec1274 100644
> --- a/lib/netdev.h
> +++ b/lib/netdev.h
> @@ -89,6 +89,7 @@ struct netdev_tunnel_config {
> struct in6_addr ipv6_dst;
> 
> uint32_t exts;
> +uint32_t egress_pkt_mark;
> 
> uint8_t ttl;
> bool ttl_inherit;
> diff --git a/ofproto/tunnel.c b/ofproto/tunnel.c
> index ce727f4..6205948 100644
> --- a/ofproto/tunnel.c
> +++ b/ofproto/tunnel.c
> @@ -461,6 +461,11 @@ tnl_port_send(const struct ofport_dpif *ofport, struct 
> flow *flow,
> | (cfg->csum ? FLOW_TNL_F_CSUM : 0)
> | (cfg->out_key_present ? FLOW_TNL_F_KEY : 0);
> 
> +if (cfg->egress_pkt_mark) {
> +flow->pkt_mark = cfg->egress_pkt_mark;
> +wc->masks.pkt_mark = UINT32_MAX;

Here the pkt_mark from the flow is not used or inherited, so why are we setting 
the mask (which causes an exact match on the incoming pkt_mark value (which is 
likely zero))?

> +}
> +

If egress_pkt_mark is zero, do we further on in the tunnel code (maybe due to 
later patches) use the pkt_mask value from the flow?

> if (pre_flow_str) {
> char *post_flow_str = flow_to_string(flow);
> char *tnl_str = tnl_port_fmt(tnl_port);
> diff --git a/tests/tunnel-push-pop.at b/tests/tunnel-push-pop.at
> index 700ef55..4aaa669 100644
> --- a/tests/tunnel-push-pop.at
> +++ b/tests/tunnel-push-pop.at
> @@ -12,6 +12,8 @@ AT_CHECK([ovs-vsctl add-port int-br t2 -- set Interface t2 
> type=vxlan \
>options:remote_ip=1.1.2.93 options:out_key=flow 
> options:csum=true ofport_request=4\
> -- add-port int-br t4 -- set Interface t4 type=geneve \
>options:remote_ip=flow options:key=123 
> ofport_request=5\
> +-- add-port int-br t5 -- set Interface t5 type=geneve \
> +   options:remote_ip=1.1.2.93 options:out_key=flow 
> options:egress_pkt_mark=1234 ofport_request=6\
>], [0])
> 
> AT_CHECK([ovs-appctl dpif/show], [0], [dnl
> @@ -25,6 +27,7 @@ dummy@ovs-dummy: hit:0 missed:0
>   t2 2/4789: (vxlan: key=123, remote_ip=1.1.2.92)
>   t3 4/4789: (vxlan: csum=true, out_key=flow, remote_ip=1.1.2.93)
>   t4 5/6081: (geneve: key=123, remote_ip=flow)
> + t5 6/6081: (geneve: egress_pkt_mark=1234,

[ovs-dev] question about ovs's bandwidth limition

2017-01-23 Thread lg.yue





hi,
i have two questiones to consult. 
software version:  openvswitch-2.6.90.13454.gita9ba22b7 , 3.10.0-327.36.3.el7


1. why logical_switch_port's rate and burst is  set on physical device, rather 
than port's tap device? does this policy  work?  .why ovn does not choose to 
setup ovs's db， but to call netdev's api?
options of  port_binding is 'qdisc_queue_id="2", qos_burst="25000", 
qos_max_rate="55000"'.   


#tc class show dev eth0
class htb 1:fffe root rate 10Kbit ceil 10Kbit burst 1500b cburst 1500b 
class htb 1:2 parent 1:fffe prio 0 rate 12000bit ceil 52000bit burst 2749b 
cburst 2749b 
class htb 1:3 parent 1:fffe prio 0 rate 12000bit ceil 55000bit burst 3124b 
cburst 3124b 


2. how the following flows are handled in kernel space or in user space(where 
is the code)?it seems that ovs translates queue_id into sob_priority. if i 
miss something.
please tell  the process flow


cookie=0x0, duration=979234.497s, table=16, n_packets=0, n_bytes=0, 
idle_age=65534, hard_age=21295, 
priority=50,reg14=0x2,metadata=0x1,dl_src=02:ac:10:ff:01:94 
actions=set_queue:2,resubmit(,17)
 cookie=0x0, duration=960048.293s, table=16, n_packets=0, n_bytes=0, 
idle_age=65534, hard_age=65534, priority=50,reg14=0x2,metadata=0x7 
actions=set_queue:1,resubmit(,17)
 cookie=0x0, duration=979234.496s, table=16, n_packets=3975, n_bytes=1044630, 
idle_age=21519, hard_age=65534, priority=50,reg14=0x2,metadata=0x2 
actions=set_queue:1,resubmit(,17)
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH v2] ovn: Document upgrade procedure.

2017-01-23 Thread Ben Pfaff

On Mon, Jan 23, 2017 at 09:50:02AM -0500, Russell Bryant wrote:
> Signed-off-by: Russell Bryant 

Thanks Russell!

s/its/it's/ here:
> +You should start by upgrading ovn-controller on each host its running on.

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

Re: [ovs-dev] [urgent] is there anyway to enable multi-vlan for on vm upon ovs ?

2017-01-23 Thread Ben Pfaff

On Sun, Jan 22, 2017 at 05:18:48PM +0800, xiucai wrote:
> hi,
> everyone :)
> 
> 
> in my case, there is one vm for storage sharing, we name it SVM, and 
> several VMs as testing client.
> for historic reasons, i can not modify the network which uses vlan upon 
> ovs.
> 
> 
> the SVM is corresponding to vnet0, make it as trunk for tag-2 and tag-3;
> the VM1 is corresponding to vnet2/tag-2 and the VM2 is corresponding to 
> vnet4/tag-3.
> i wanna all VMx can connect to SVM, but VMx can not communicate with each 
> other!
> 
> 
> ==configurations==
> SVM's eth0: 192.168.1.1 static 52:54:01:CB:35:C4
> VM1's eth0: 192.168.1.2 static 52:54:02:CB:35:C4
> VM2's eth0: 192.168.1.3 static 52:54:03:CB:35:C4
> 
> 
> Bridge "br1"
> Port "vnet4"
> tag: 3
> Interface "vnet4"
> Port "vnet0"
> trunks: [2, 3]
> Interface "vnet0"
> Port "vnet2"
> tag: 2
> Interface "vnet2"
> Port "br1"
> Interface "br1"
> type: internal
> ovs_version: "2.5.0"
> =
> 
> 
> but it does not work :(
> they can not ping through each other!
> 
> 
> i use tcpdump to monitor eth0 on SVM, and ping SVM from VM1, it said "ARP 
> Request who-has SVM-IP to tell VM1-IP".
> and i use arp to add entry for each other, then it only said "VM1-IP > 
> SVM-IP: ICMP echo request, id , seq x, length xx", but no "reply".
> 
> 
> i have got no idea about this case, i do not know i have mistaken the 
> concept of trunk on ovs or my config is wrong :(

Does your VM connected to vnet0 understand VLAN trunks?  Do you have
VLAN interfaces configured there?
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] doc: Remove tutorials/ovn-basics.

2017-01-23 Thread Ben Pfaff

On Mon, Jan 23, 2017 at 09:02:07AM -0500, Russell Bryant wrote:
> On Thu, Jan 19, 2017 at 6:01 PM, Ben Pfaff  wrote:
> 
> > On Thu, Jan 19, 2017 at 02:17:09PM -0500, Russell Bryant wrote:
> > > The only thing worse than a lack of documentation is incorrect or
> > > out-of-date documentation.  Over time, this document has not kept up with
> > > the pace of OVN and is no longer a good current resource.
> > >
> > > For a sandbox based tutorial like this, I'd like to start over using
> > > ovn-trace as the basis.
> > >
> > > An even more important type of tutorial would be something along the
> > lines
> > > of: http://blog.spinhirne.com/p/blog-series.html
> > >
> > > That blog series was fantastic and has been the primary tutorial
> > reference
> > > I have been sending people to since it was written.
> > >
> > > Signed-off-by: Russell Bryant 
> >
> > I'm a little sad to see this go, but if it's no longer a good
> > introduction then it has to happen.  Thank you for all the work on it.
> >
> 
> Thanks.  I'm actually happy that OVN has progressed quickly and we have
> much better tools for working with OVN and analyzing flows now.  :-)
> 
> If I put energy into this, I'd like to write a tutorial around ovn-trace.
> Thanks for all the work you put into that!

You're welcome!

It sounds possible that OVS/OVN will have a 3-hour tutorial slot at ONS
in April.  If so, we'll need to write a tutorial.  Maybe we can
collaborate.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] OVS - ODL Sync on OF Bundle in 1.3

2017-01-23 Thread Jan Scheurich

Rescheduled to Wednesday due to unavailability of key participants.
@Jarno: As you are the OVS brain behind bundles. Do you have the chance to join
for a short time to discuss some details regarding OF 1.3 bundle
implementation?

Hi Jarno,

OpenDaylight folks are finally starting to implement support of OpenFlow
bundles as a basis for the bundle-based hitless recync procedure we discussed
earlier. As ODL does not yet have protocol support for OpenFlow versions 1.4 or
1.5, they intend to implement the bundle extension to OF 1.3 as specified in
EXT-230 in
https://www.opennetworking.org/images/stories/downloads/sdn-resources/onf-specifications/openflow/openflow-extensions-1.3.x-pack2.zip

Would you have time for a short meeting on early Monday to discuss and confirm
whether the OVS implementation of bundles in OF 1.3 is compliant with EXT-230
and has everything they need?

Thanks, Jan

.
--> Join Skype Meeting
This is an online meeting for Skype for Business, the professional meetings
and communications app formerly known as Lync.
Join by phone

+492115343925 (Germany) English (United
States)
89925 (Germany) English (United States)

Find a local number

Conference ID: 64134840
Forgot your dial-in PIN?
|Help

To join a Lync / Skype for Business meeting from an Ericsson standard video
room, add 77 before the Conference ID (e.g. 771234567 where 1234567 is the
conference ID).To join from a video room outside of Ericsson add one of the
domains after 77 and Conference ID (e.g. 771234567@ .ericsson.net, where
=emea/apac/amcs). For assistance contact the IT Service Desk.
[!OC([1033])!]
.

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

[ovs-dev] Disney - Éxito en los Negocios

Estimado Cliente:

Le hacemos llegar el programa de capacitación correspondiente al mes de Febrero 
del ao en curso.


- Auditorías para la adquisición de empresas: Due Diligence - 2 de Febrero

- Matemáticas Financieras y Evaluación de Proyectos de Inversión - 3 de Febrero 

- Habilidades de Liderazgo y Trabajo en Equipo con Lego® Serious Play® - 3 de 
Febrero 

- El Éxito en los Negocios y las Finanzas basado en el Modelo Disney® - 10 de 
Febrero 

- Implementación de las NIIF 9 (reemplaza a la NIC 39) - 16 de Febrero 

- Curso Práctico de Análisis Financiero - 16 de marzo

- La Asistente Asertiva, Activa y Efectiva - 23 de Febrero 

- Taller de Grafología - 23 de Febrero 

-  Estrategias de Negociación de Compras - 24 de Febrero 



Para Obtener Información Completa, responda este correo con los siguientes 
datos: Nombre,Empresa,Teléfono,Curso. De igual manera Puede llamarnos sin 
compromiso al 018002120744. 


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

Re: [ovs-dev] [BUG] ovs-ofctl version 2.5.0 will crash with OFPFMFC_BAD_COMMAND

2017-01-23 Thread Vidyasagara Guntaka via dev

Hi Ben,

We could reproduce this with the latest version 2.6.1.  When we compiled the 
code, we removed -O2 from CFLAGS.  This seems to make it happen more 
frequently.  With the following script running, the error starts happening 
within a few seconds and then continues to happen after every few seconds.  In 
summary, our suspicion is that having no controller set and having no NORMAL 
processing flow seems to trigger the stack that was pointed out in the gdb 
session more often and hence we hit this race condition very easily using the 
following script.  (Even if there is a default NORMAL processing flow entry, 
after the first iteration of the script below, that will be deleted).

Also, a few things about the setup - just in case:
  * enp5s0 belongs to the physical interface on this hypervisor.
  * vport0 and vport1 belong to tap interfaces corresponding to two VMs running 
on this hypervisor.
  * When the script was running, we had pings issued from the VMs so that 
packets make it to the bridge br0.

Here is a small script that makes it happen on multiple of our hypervisors:

while true
do
ovs-ofctl add-flow br0 
"priority=200,table=123,idle_timeout=1,in_port=1,actions=controller"
ovs-ofctl add-flow br0 
"priority=200,table=123,idle_timeout=1,in_port=2,actions=controller"
ovs-ofctl add-flow br0 
"priority=200,table=123,idle_timeout=1,in_port=3,actions=controller"
ovs-ofctl add-flow br0 
"priority=200,table=123,idle_timeout=1,in_port=4,actions=controller"
ovs-ofctl del-flows br0 
done

Here is our bridge br0 setup:

[root@deepspace ~]# ifconfig br0
br0: flags=4163  mtu 1500
inet 192.168.2.142  netmask 255.255.255.0  broadcast 192.168.2.255
inet6 fe80::213:3bff:fe0f:1301  prefixlen 64  scopeid 0x20
ether 00:13:3b:0f:13:01  txqueuelen 1000  (Ethernet)
RX packets 89417814  bytes 12088012200 (11.2 GiB)
RX errors 0  dropped 82  overruns 0  frame 0
TX packets 32330647  bytes 3168352394 (2.9 GiB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

[root@deepspace ~]# ovs-vsctl show
54f89e00-edd2-486e-9626-6d11c7d8b0b6
Bridge "br0"
Port "vport1"
Interface "vport1"
Port "br0"
Interface "br0"
type: internal
Port vtep
Interface vtep
type: vxlan
options: {key=flow, remote_ip="192.168.1.141"}
Port "vport0"
Interface "vport0"
Port "enp5s0"
Interface "enp5s0"
ovs_version: “2.6.1"

[root@deepspace ~]# ovs-ofctl show br0
OFPT_FEATURES_REPLY (xid=0x2): dpid:00133b0f1301
n_tables:254, n_buffers:256
capabilities: FLOW_STATS TABLE_STATS PORT_STATS QUEUE_STATS ARP_MATCH_IP
actions: output enqueue set_vlan_vid set_vlan_pcp strip_vlan mod_dl_src 
mod_dl_dst mod_nw_src mod_nw_dst mod_nw_tos mod_tp_src mod_tp_dst
 1(enp5s0): addr:00:13:3b:0f:13:01
 config: 0
 state:  0
 current:1GB-FD AUTO_NEG
 advertised: 10MB-HD 10MB-FD 100MB-HD 100MB-FD 1GB-HD 1GB-FD COPPER 
AUTO_NEG AUTO_PAUSE AUTO_PAUSE_ASYM
 supported:  10MB-HD 10MB-FD 100MB-HD 100MB-FD 1GB-HD 1GB-FD COPPER AUTO_NEG
 speed: 1000 Mbps now, 1000 Mbps max
 2(vport0): addr:fe:00:00:00:00:03
 config: 0
 state:  0
 current:10MB-FD COPPER
 speed: 10 Mbps now, 0 Mbps max
 3(vport1): addr:fe:00:00:00:00:04
 config: 0
 state:  0
 current:10MB-FD COPPER
 speed: 10 Mbps now, 0 Mbps max
 4(vtep): addr:aa:97:d2:a9:19:ed
 config: 0
 state:  0
 speed: 0 Mbps now, 0 Mbps max
 LOCAL(br0): addr:00:13:3b:0f:13:01
 config: 0
 state:  0
 speed: 0 Mbps now, 0 Mbps max
OFPT_GET_CONFIG_REPLY (xid=0x4): frags=normal miss_send_len=0

[root@deepspace ~]# ovs-ofctl --version
ovs-ofctl (Open vSwitch) 2.6.1
OpenFlow versions 0x1:0x4

Please let us know if you need anything else to reproduce this.

Thanks,
Sagar.

> On Jan 18, 2017, at 1:19 PM, Ben Pfaff  wrote:
> 
> If you can come up with simple reproduction instructions that work for
> me, I'm happy to track this down.  It's probably something very simple.
> 
> On Tue, Jan 17, 2017 at 08:50:20AM -0800, Vidyasagara Guntaka wrote:
>> This issue happened on our in-use systems and we were trying to find a way
>> to move forward avoiding this issue so that we do not have to upgrade OVS
>> on thousands of our hypervisors causing down time. Our debugging did help
>> us avoid the issue for now by installing an explicit rule to to drop
>> packets when there is no match and this issue is not seen over many hours
>> of test runs.
>> 
>> We will definitely run this test with latest version.  But, will need more
>> time since we are busy with our release related activities.
>> 
>> Regards,
>> Sagar.
>> 
>> On Tue, Jan 17, 2017 at 8:42 AM, Ben Pfaff  wrote:
>> 
>>> It would be more helpful to have a simple reproduction case.
>>> 
>>>

Re: [ovs-dev] OVS - ODL Sync on OF Bundle in 1.3

2017-01-23 Thread Jan Scheurich

Hi,

A local dial-in number for Slovakia participants can be found under the link 
“Find a local number”:

Slovak Republic  ‪+421249499488‬‪ English (United States)‬

BR, Jan

  -Original Appointment-
  From: Jan Scheurich
  Sent: Wednesday, 18 January, 2017 16:23
  To: Jan Scheurich; Abhijit Kumbhare; Zoltán Balogh; László Sürü; Miklós 
Pelyva; Jozef Bacigál; Tomáš Slušný; Prasanna Huddar; Shuva Jyoti Kar; Sharath 
Kumar V; Kanagasundaram K; Sunil Kumar G; D Arunprakash; Muthukumaran K; Jarno 
Rajahalme (ja...@ovn.org); d...@openvswitch.org
  Subject: OVS - ODL Sync on OF Bundle in 1.3
  When: Monday, 23 January, 2017 17:00-18:00 (UTC+01:00) Amsterdam, Berlin, 
Bern, Rome, Stockholm, Vienna.
  Where: Skype Meeting


  Hi Jarno,

  OpenDaylight folks are finally starting to implement support of OpenFlow 
bundles as a basis for the bundle-based hitless recync procedure we discussed 
earlier. As ODL does not yet have protocol support for OpenFlow versions 1.4 or 
1.5, they intend to implement the bundle extension to OF 1.3 as specified in 
EXT-230 in
  
https://www.opennetworking.org/images/stories/downloads/sdn-resources/onf-specifications/openflow/openflow-extensions-1.3.x-pack2.zip

  Would you have time for a short meeting on early Monday to discuss and 
confirm whether the OVS implementation of bundles in OF 1.3 is compliant with 
EXT-230 and has everything they need?

  Thanks, Jan


  
.
  --> Join Skype Meeting
  This is an online meeting for Skype for Business, the professional meetings 
and communications app formerly known as Lync.
  Join by phone

  +492115343925 (Germany)English 
(United States)
  89925 (Germany)   English (United States)

  Find a local number

  Conference ID: 64134840
   Forgot your dial-in PIN? 
|Help


  To join a Lync / Skype for Business meeting from an Ericsson standard 
video room, add 77 before the Conference ID (e.g. 771234567 where 1234567 is 
the conference ID).To join from a video room outside of Ericsson add one of 
the domains after 77 and Conference ID (e.g. 771234567@ .ericsson.net, 
where =emea/apac/amcs).  For assistance contact the IT Service Desk.
  [!OC([1033])!]
  
.


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

Re: [ovs-dev] OVS - ODL Sync on OF Bundle in 1.3

2017-01-23 Thread Abhijit Kumbhare

Thanks. I just found that and was going to respond about that.

_
From: Jan Scheurich
Sent: Monday, January 23, 2017 7:31 AM
To: Abhijit Kumbhare ; Zoltán Balogh 
; László Sürü ; Miklós 
Pelyva ; Jozef Bacigál 
; Tomáš Slušný ; 
Prasanna Huddar ; Shuva Jyoti Kar 
; Sharath Kumar V ; 
Kanagasundaram K ; Sunil Kumar G 
; D Arunprakash ; 
Muthukumaran K ; Jarno Rajahalme (ja...@ovn.org) 
; d...@openvswitch.org
Subject: RE: OVS - ODL Sync on OF Bundle in 1.3

Hi,

A local dial-in number for Slovakia participants can be found under the link 
“Find a local number”:

Slovak Republic  ‪+421249499488‬‪ English (United States)‬

BR, Jan

  -Original Appointment-
  From: Jan Scheurich
  Sent: Wednesday, 18 January, 2017 16:23
  To: Jan Scheurich; Abhijit Kumbhare; Zoltán Balogh; László Sürü; Miklós 
Pelyva; Jozef Bacigál; Tomáš Slušný; Prasanna Huddar; Shuva Jyoti Kar; Sharath 
Kumar V; Kanagasundaram K; Sunil Kumar G; D Arunprakash; Muthukumaran K; Jarno 
Rajahalme (ja...@ovn.org); 
d...@openvswitch.org
  Subject: OVS - ODL Sync on OF Bundle in 1.3
  When: Monday, 23 January, 2017 17:00-18:00 (UTC+01:00) Amsterdam, Berlin, 
Bern, Rome, Stockholm, Vienna.
  Where: Skype Meeting

  Hi Jarno,

  OpenDaylight folks are finally starting to implement support of OpenFlow 
bundles as a basis for the bundle-based hitless recync procedure we discussed 
earlier. As ODL does not yet have protocol support for OpenFlow versions 1.4 or 
1.5, they intend to implement the bundle extension to OF 1.3 as specified in 
EXT-230 in

https://www.opennetworking.org/images/stories/downloads/sdn-resources/onf-specifications/openflow/openflow-extensions-1.3.x-pack2.zip

  Would you have time for a short meeting on early Monday to discuss and 
confirm whether the OVS implementation of bundles in OF 1.3 is compliant with 
EXT-230 and has everything they need?

  Thanks, Jan

.
  --> Join Skype Meeting
  This is an online meeting for Skype for Business, the professional meetings 
and communications app formerly known as Lync.
  Join by phone

  +492115343925 (Germany)English 
(United States)
  89925 (Germany)   English (United States)

  Find a local number

  Conference ID: 64134840
   Forgot your dial-in PIN? 
|Help

  To join a Lync / Skype for Business meeting from an Ericsson standard 
video room, add 77 before the Conference ID (e.g. 771234567 where 1234567 is 
the conference ID).To join from a video room outside of Ericsson add one of 
the domains after 77 and Conference ID (e.g. 771234567@ .ericsson.net, 
where =emea/apac/amcs).  For assistance contact the IT Service Desk.
  [!OC([1033])!]

.

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

Re: [ovs-dev] [PATCH] datapath: internal-dev: Disable rtnl_link_ops register under linux < 3.17

2017-01-23 Thread Markos Chandras

Hi,

On 12/14/2016 03:44 AM, Zhang Dongya wrote:
> From: "fortitude.zhang" 
> 
> Under linux < 3.17, b0ab2fabb5b91da99c189db02e91ae10bc8355c5 is not 
> introduced,
> which allow internal-dev created by openvswitch datapath deleted by using rtnl
> interface, this causes data related to internal-dev not freed and stops 
> datapath
> working correctly.
> 
> Signed-off-by: fortitude.zhang 

I recently encountered this bug and this commit fixed it for me. So...

Tested-by: Markos Chandras 

It might also worth backporting it to stable branches as well.

-- 
markos

SUSE LINUX GmbH | GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg) Maxfeldstr. 5, D-90409, Nürnberg
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH 1/2] ovn: Document upgrade procedure.

Oops, I forgot to follow up on this ...

On Thu, Dec 22, 2016 at 12:21 AM, Ben Pfaff  wrote:

> On Wed, Dec 21, 2016 at 10:56:35PM -0500, Russell Bryant wrote:
> > On Wed, Dec 21, 2016 at 5:06 PM, Ben Pfaff  wrote:
> >
> > > On Wed, Dec 07, 2016 at 02:28:13PM -0500, Russell Bryant wrote:
> > > > Signed-off-by: Russell Bryant 
> > >
> > > This procedure isn't what I expected.  It recommends:
> > >
> > > 1. Upgrade SB/NB databases and northd.
> > > 2. Upgrade ovn-controller.
> > > 3. Upgrade integration.
> > >
> > > I think that this is likely to cause problems in the common case,
> > > because the new northd is likely to try to start using features that
> are
> > > not yet available on the hypervisors, such as new logical match fields
> > > and actions.
> > >
> > > I expected:
> > >
> > > 1. Upgrade ovn-controller.
> > > 2. Upgrade SB/NB databases and northd.
> > > 3. Upgrade integration.
> > >
> > > (I don't think that it matters when the databases are upgraded, though,
> > > as long as they're upgraded before northd.)
> > >
> >
> > Thanks for the feedback!
> >
> > There's a possible problem in this case, too.  ovn-controller could try
> to
> > start using new fields in the southbound database that aren't there yet.
>
> I guess that I have always considered that ovn-controller needs to
> tolerate some version-related variation in the database schema.  This is
> a familiar problem, since ovs-vsctl and (to a lesser extent)
> ovs-vswitchd also need to tolerate similar variation.
>
> Different kinds of tolerance must be considered.  Missing columns
> (because they were added in a later database schema) are one of the
> easiest, and the IDL takes care of that for us; the column will just
> appear empty.  Over in OVS, we normally design the schema so that an
> empty column yields the default new behavior anyhow.
>
> The related_datapaths column that had been proposed for optimizing
> conditional monitoring was a tougher case for upgrade.  With this
> proposal, an empty column or a missing one would break ovn-controller,
> since it wouldn't get all of the rows that it needed.  Even if the
> column was present, it still wouldn't help if ovn-northd was too old to
> populate it correctly.  I was about to propose that ovn-controller
> needed to figure out not just whether the column was present but whether
> ovn-northd was new enough and properly populating it, when I came up
> with the approach we're now using that doesn't need this column at all.
>
> So, upgrading the databases earlier cannot hurt, but I doubt that it
> solves many problems.
>

Thanks for the info.


>
> > Maybe it should be:
> >
> > 1. Upgrade SB/NB databases.
> > 2. Upgrade ovn-controller.
> > 3. Upgrade ovn-northd.
> > 4. Upgrade integration.
>
> This ordering seems fine to me.
>

so we could do the above, or based on your comments:

1. Upgrade ovn-controller.
2. Upgrade databases.
3. Upgrade ovn-northd.
4. Upgrade integration.

This one is a little easier to document since 2&3 can be done with a single
command, so I'll just document it that way.


> Thank you for writing down the upgrade procedure.  (Have we written down
> the installation procedure?)
>

No, I don't think so.  We have options well documented, but not an OVN
install guide.  It tends to be covered along with integration guides,
though.  For example:

https://github.com/openvswitch/ovn-kubernetes

or

http://docs.openstack.org/developer/networking-ovn/install.html

but I think a standalone install guide would be good to have, too.

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

[ovs-dev] [PATCH v2] ovn: Document upgrade procedure.

Signed-off-by: Russell Bryant 
---
 Documentation/automake.mk|  1 +
 Documentation/intro/install/index.rst|  8 +++
 Documentation/intro/install/ovn-upgrades.rst | 87 
 3 files changed, 96 insertions(+)
 create mode 100644 Documentation/intro/install/ovn-upgrades.rst


v1->v2:
 - Update for new docs structure.
 - Change upgrade ordering based on previous discussion.  ovn-controller
   is now upgraded first.


diff --git a/Documentation/automake.mk b/Documentation/automake.mk
index 18e03a3..42553f0 100644
--- a/Documentation/automake.mk
+++ b/Documentation/automake.mk
@@ -16,6 +16,7 @@ EXTRA_DIST += \
Documentation/intro/install/fedora.rst \
Documentation/intro/install/general.rst \
Documentation/intro/install/netbsd.rst \
+   Documentation/intro/install/ovn-upgrades.rst \
Documentation/intro/install/rhel.rst \
Documentation/intro/install/userspace.rst \
Documentation/intro/install/windows.rst \
diff --git a/Documentation/intro/install/index.rst 
b/Documentation/intro/install/index.rst
index 34b014a..8696b4e 100644
--- a/Documentation/intro/install/index.rst
+++ b/Documentation/intro/install/index.rst
@@ -60,6 +60,14 @@ provided below.
fedora
rhel
 
+Upgrades
+
+
+.. toctree::
+   :maxdepth: 2
+
+   ovn-upgrades
+
 Others
 --
 
diff --git a/Documentation/intro/install/ovn-upgrades.rst 
b/Documentation/intro/install/ovn-upgrades.rst
new file mode 100644
index 000..420dc4d
--- /dev/null
+++ b/Documentation/intro/install/ovn-upgrades.rst
@@ -0,0 +1,87 @@
+..
+  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
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+  Unless required by applicable law or agreed to in writing, software
+  distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
+  WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
+  License for the specific language governing permissions and limitations
+  under the License.
+
+  Convention for heading levels in Open vSwitch documentation:
+
+  ===  Heading 0 (reserved for the title in a document)
+  ---  Heading 1
+  ~~~  Heading 2
+  +++  Heading 3
+  '''  Heading 4
+
+  Avoid deeper levels because they do not render well.
+
+
+OVN Upgrades
+
+
+Since OVN is a distributed system, special consideration must be given to
+the process used to upgrade OVN across a deployment.  This document discusses
+the recommended upgrade process.
+
+Release Notes
+-
+
+You should always check the OVS and OVN release notes (NEWS file) for any
+release specific notes on upgrades.
+
+OVS
+---
+
+OVN depends on and is included with OVS.  It's expected that OVS and OVN are
+upgraded together, partly for convenience.  OVN is included in OVS releases
+so it's easiest to upgrade them together.  OVN may also make use of new
+features of OVS only available in that release.
+
+Upgrade ovn-controller
+--
+
+You should start by upgrading ovn-controller on each host its running on.
+First, you upgrade the OVS and OVN packages.  Then, restart the
+ovn-controller service.  You can restart with ovn-ctl::
+
+$ sudo /usr/share/openvswitch/scripts/ovn-ctl restart_controller
+
+or with systemd::
+
+$ sudo systemd restart ovn-controller
+
+Upgrade OVN Databases and ovn-northd
+
+
+The OVN databases and ovn-northd should be upgraded next.  Since ovn-controller
+has already been upgraded, it will be ready to operate on any new functionality
+specified by the database or logical flows created by ovn-northd.
+
+Upgrading the OVN packages installs everything needed for an upgrade.  The only
+step required after upgrading the packages is to restart ovn-northd, which
+automatically restarts the databases and upgrades the database schema, as well.
+
+You may perform this restart using the ovn-ctl script::
+
+$ sudo /usr/share/openvswitch/scripts/ovn-ctl restart_northd
+
+or if you're using a Linux distribution with systemd::
+
+$ sudo systemctl restart ovn-northd
+
+Upgrading OVN Integration
+-
+
+Lastly, you may also want to upgrade integration with OVN that you may be
+using.  For example, this could be the OpenStack Neutron driver or
+ovn-kubernetes.
+
+OVN's northbound database schema is a backwards compatible interface, so
+you should be able to safely complete an OVN upgrade before upgrading
+any integration in use.
-- 
2.9.3

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

Re: [ovs-dev] [PATCH] doc: Remove tutorials/ovn-basics.