Re: [ovs-dev] [PATCH v2 0/2] ovn-controller: Add a new thread in pinctrl module to process packet-ins

2019-03-15 Thread Numan Siddique
On Sat, Mar 16, 2019 at 2:41 AM Ben Pfaff  wrote:

> On Tue, Mar 12, 2019 at 10:00:02PM +0530, nusid...@redhat.com wrote:
> > From: Numan Siddique 
> >
> > This series attempts to add a new thread in pinctrl module. This thread
> > will handle the packet-ins.
> >
> > v1 -> v2
> > --
> >   * Added a new patch p1 to the series suggessted by Mark.
> >   * Addressed the review comments from Han and Mark.
>
> Thanks for the series.
>
> Does this depend on some other series?  I get a cascade of errors from
> Clang:
>
> ../ovn/controller/pinctrl.c:65:18: error: use of undeclared identifier
> 'pinctrl_mutex'; did you mean 'pinctrl_run'?
> ../include/openvswitch/compiler.h:124:45: note: expanded from macro
> 'OVS_REQUIRES'
> ../ovn/controller/pinctrl.h:34:6: note: 'pinctrl_run' declared here
> ../ovn/controller/pinctrl.c:65:5: error: 'exclusive_locks_required'
> attribute requires arguments whose type is annotated with 'capability'
> attribute; type here is 'void (struct ovsdb_idl_txn *, struct
> ovsdb_idl_index *, struct ovsdb_idl_index *, struct ovsdb_idl_index *,
> struct ovsdb_idl_index *, struct ovsdb_idl_index *, struct ovsdb_idl_index
> *, const struct sbrec_dns_table *, const struct ovsrec_bridge *, const
> struct sbrec_chassis *, const struct hmap *, const struct sset *)'
> [-Werror,-Wthread-safety-attributes]
> ../include/openvswitch/compiler.h:124:20: note: expanded from macro
> 'OVS_REQUIRES'
> ../ovn/controller/pinctrl.c:73:18: error: use of undeclared identifier
> 'pinctrl_mutex'; did you mean 'pinctrl_run'?
> ../include/openvswitch/compiler.h:124:45: note: expanded from macro
> 'OVS_REQUIRES'
> ../ovn/controller/pinctrl.h:34:6: note: 'pinctrl_run' declared here
> ../ovn/controller/pinctrl.c:73:5: error: 'exclusive_locks_required'
> attribute requires arguments whose type is annotated with 'capability'
> attribute; type here is 'void (struct ovsdb_idl_txn *, struct
> ovsdb_idl_index *, struct ovsdb_idl_index *, struct ovsdb_idl_index *,
> struct ovsdb_idl_index *, struct ovsdb_idl_index *, struct ovsdb_idl_index
> *, const struct sbrec_dns_table *, const struct ovsrec_bridge *, const
> struct sbrec_chassis *, const struct hmap *, const struct sset *)'
> [-Werror,-Wthread-safety-attributes]
> ../include/openvswitch/compiler.h:124:20: note: expanded from macro
> 'OVS_REQUIRES'
> ../ovn/controller/pinctrl.c:79:18: error: use of undeclared identifier
> 'pinctrl_mutex'; did you mean 'pinctrl_run'?
> ../include/openvswitch/compiler.h:124:45: note: expanded from macro
> 'OVS_REQUIRES'
> ../ovn/controller/pinctrl.h:34:6: note: 'pinctrl_run' declared here
> ../ovn/controller/pinctrl.c:79:5: error: 'exclusive_locks_required'
> attribute requires arguments whose type is annotated with 'capability'
> attribute; type here is 'void (struct ovsdb_idl_txn *, struct
> ovsdb_idl_index *, struct ovsdb_idl_index *, struct ovsdb_idl_index *,
> struct ovsdb_idl_index *, struct ovsdb_idl_index *, struct ovsdb_idl_index
> *, const struct sbrec_dns_table *, const struct ovsrec_bridge *, const
> struct sbrec_chassis *, const struct hmap *, const struct sset *)'
> [-Werror,-Wthread-safety-attributes]
> ../include/openvswitch/compiler.h:124:20: note: expanded from macro
> 'OVS_REQUIRES'
> ../ovn/controller/pinctrl.c:92:18: error: use of undeclared identifier
> 'pinctrl_mutex'; did you mean 'pinctrl_run'?
> ../include/openvswitch/compiler.h:124:45: note: expanded from macro
> 'OVS_REQUIRES'
> ../ovn/controller/pinctrl.h:34:6: note: 'pinctrl_run' declared here
> ../ovn/controller/pinctrl.c:92:5: error: 'exclusive_locks_required'
> attribute requires arguments whose type is annotated with 'capability'
> attribute; type here is 'void (struct ovsdb_idl_txn *, struct
> ovsdb_idl_index *, struct ovsdb_idl_index *, struct ovsdb_idl_index *,
> struct ovsdb_idl_index *, struct ovsdb_idl_index *, struct ovsdb_idl_index
> *, const struct sbrec_dns_table *, const struct ovsrec_bridge *, const
> struct sbrec_chassis *, const struct hmap *, const struct sset *)'
> [-Werror,-Wthread-safety-attributes]
> ../include/openvswitch/compiler.h:124:20: note: expanded from macro
> 'OVS_REQUIRES'
> ../ovn/controller/pinctrl.c:94:18: error: use of undeclared identifier
> 'pinctrl_mutex'; did you mean 'pinctrl_run'?
> ../include/openvswitch/compiler.h:124:45: note: expanded from macro
> 'OVS_REQUIRES'
> ../ovn/controller/pinctrl.h:34:6: note: 'pinctrl_run' declared here
> ../ovn/controller/pinctrl.c:94:5: error: 'exclusive_locks_required'
> attribute requires arguments whose type is annotated with 'capability'
> attribute; type here is 'void (struct ovsdb_idl_txn *, struct
> ovsdb_idl_index *, struct ovsdb_idl_index *, struct ovsdb_idl_index *,
> struct ovsdb_idl_index *, struct ovsdb_idl_index *, struct ovsdb_idl_index
> *, const struct sbrec_dns_table *, const struct ovsrec_bridge *, const
> struct sbrec_chassis *, const struct hmap *, const struct sset *)'
> [-Werror,-Wthread-safety-attributes]
> ../include/openvswitch/compiler.h:124:20: note: 

[ovs-dev] [PATCH v3 2/2] ovn-controller: Add a new thread in pinctrl module to handle packet-ins.

2019-03-15 Thread nusiddiq
From: Numan Siddique 

Prior to this patch, ovn-controller was single threaded and everytime the
poll_block() at the end of the main while() loop wakes up, it  processes
the whole SB DB and translates the logical flows to OF flows.

There are few issues with this -

  * For every packet-in received, ovn-controller does this translation
resulting in unnecessary CPU cycles.

  * If the translation takes a lot of time, then the packet-in handling
would get delayed. The delay in responses to DHCP requests could
result in resending of these requests.

This patch addresses these issues by creating a new pthread in pinctrl module
to handle packet-ins. This thread doesn't access the Southbound DB IDL object.

Since some of the OVN actions - like dns_lookup, arp, put_arp, put_nd
require access to the Southbound DB contents and gARPs, periodic IPv6 RA
generation also requires the DB access, pinctrl_run() called by the main
ovn-controller thread accesses the Southbound DB IDL and builds the local
datastructures. pinctrl_handler thread accesses these data structures
in handling such requests. An ovs_mutex is used between the pinctr_run() and
the pinctrl_handler thread to protect these data structures.

Acked-by: Mark Michelson 
Signed-off-by: Numan Siddique 
---
 ovn/controller/pinctrl.c | 662 +++
 1 file changed, 526 insertions(+), 136 deletions(-)

diff --git a/ovn/controller/pinctrl.c b/ovn/controller/pinctrl.c
index dac1fec20..70e788ff5 100644
--- a/ovn/controller/pinctrl.c
+++ b/ovn/controller/pinctrl.c
@@ -27,6 +27,7 @@
 #include "lport.h"
 #include "nx-match.h"
 #include "ovn-controller.h"
+#include "latch.h"
 #include "lib/packets.h"
 #include "lib/sset.h"
 #include "openvswitch/ofp-actions.h"
@@ -48,48 +49,140 @@
 #include "openvswitch/poll-loop.h"
 #include "openvswitch/rconn.h"
 #include "socket-util.h"
+#include "seq.h"
 #include "timeval.h"
 #include "vswitch-idl.h"
 #include "lflow.h"
 
 VLOG_DEFINE_THIS_MODULE(pinctrl);
 
-/* OpenFlow connection to the switch. */
-static struct rconn *swconn_;
+/* pinctrl module creates a thread - pinctrl_handler to handle
+ * the packet-ins from ovs-vswitchd. Some of the OVN actions
+ * are translated to OF 'controller' actions. See include/ovn/actions.h
+ * for more details.
+ *
+ * pinctrl_handler thread doesn't access the Southbound IDL object. But
+ * some of the OVN actions which gets translated to 'controller'
+ * OF action, require data from Southbound DB.  Below are the details
+ * on how these actions are implemented.
+ *
+ * pinctrl_run() function is called by ovn-controller main thread.
+ * A Mutex - 'pinctrl_mutex' is used between the pinctrl_handler() thread
+ * and pinctrl_run().
+ *
+ *   - dns_lookup - In order to do a DNS lookup, this action needs
+ *  to access the 'DNS' table. pinctrl_run() builds a
+ *  local DNS cache - 'dns_cache'. See sync_dns_cache()
+ *  for more details.
+ *  The function 'pinctrl_handle_dns_lookup()' (which is
+ *  called with in the pinctrl_handler thread) looks into
+ *  the local DNS cache to resolve the DNS requests.
+ *
+ *   - put_arp/put_nd - These actions stores the IPv4/IPv6 and MAC addresses
+ *  in the 'MAC_Binding' table.
+ *  The function 'pinctrl_handle_put_mac_binding()' (which
+ *  is called with in the pinctrl_handler thread), stores
+ *  the IPv4/IPv6 and MAC addresses in the
+ *  hmap - put_mac_bindings.
+ *
+ *  pinctrl_run(), reads these mac bindings from the hmap
+ *  'put_mac_bindings' and writes to the 'MAC_Binding'
+ *  table in the Southbound DB.
+ *
+ *   - arp/nd_ns  - These actions generate an ARP/IPv6 Neighbor solicit
+ *  requests. The original packets are buffered and
+ *  injected back when put_arp/put_nd actions are called.
+ *  When pinctrl_run(), writes the mac bindings from the
+ *  'put_mac_bindings' hmap to the MAC_Binding table in
+ *  SB DB, it moves these mac bindings to another hmap -
+ *  'buffered_mac_bindings'.
+ *
+ *  The pinctrl_handler thread calls the function -
+ *  send_mac_binding_buffered_pkts(), which uses
+ *  the hmap - 'buffered_mac_bindings' and reinjects the
+ *  buffered packets.
+ *
+ * pinctrl module also periodically sends IPv6 Router Solicitation requests
+ * and gARPs (for the router gateway IPs and configured NAT addresses).
+ *
+ * IPv6 RA handling - pinctrl_run() prepares the IPv6 RA information
+ *(see prepare_ipv6_ras()) in the shash 'ipv6_ras' by
+ *looking into the Southbound DB table - 

[ovs-dev] [PATCH v3 1/2] ovn pinctrl: Pass 'struct rconn *swconn' to all the functions which use it

2019-03-15 Thread nusiddiq
From: Numan Siddique 

In pinctrl.c, many functions use 'swconn' variable which is declared as
global static. This patch passes 'swconn' as a variable to functions.
This will help in an upcoming patch which makes processing
packet-ins in a separate pthread.

Suggested-by: Mark Michelson 
Acked-by: Mark Michelson 
Signed-off-by: Numan Siddique 
---
 ovn/controller/pinctrl.c | 184 ++-
 1 file changed, 106 insertions(+), 78 deletions(-)

diff --git a/ovn/controller/pinctrl.c b/ovn/controller/pinctrl.c
index 100a20ff2..dac1fec20 100644
--- a/ovn/controller/pinctrl.c
+++ b/ovn/controller/pinctrl.c
@@ -55,16 +55,17 @@
 VLOG_DEFINE_THIS_MODULE(pinctrl);
 
 /* OpenFlow connection to the switch. */
-static struct rconn *swconn;
+static struct rconn *swconn_;
 
-/* Last seen sequence number for 'swconn'.  When this differs from
- * rconn_get_connection_seqno(rconn), 'swconn' has reconnected. */
+/* Last seen sequence number for 'swconn_'.  When this differs from
+ * rconn_get_connection_seqno(rconn), 'swconn_' has reconnected. */
 static unsigned int conn_seq_no;
 
 static void init_buffered_packets_map(void);
 static void destroy_buffered_packets_map(void);
 
-static void pinctrl_handle_put_mac_binding(const struct flow *md,
+static void pinctrl_handle_put_mac_binding(struct rconn *swconn,
+   const struct flow *md,
const struct flow *headers,
bool is_arp);
 static void init_put_mac_bindings(void);
@@ -81,6 +82,7 @@ static void init_send_garps(void);
 static void destroy_send_garps(void);
 static void send_garp_wait(void);
 static void send_garp_run(
+struct rconn *swconn,
 struct ovsdb_idl_index *sbrec_chassis_by_name,
 struct ovsdb_idl_index *sbrec_port_binding_by_datapath,
 struct ovsdb_idl_index *sbrec_port_binding_by_name,
@@ -88,17 +90,20 @@ static void send_garp_run(
 const struct sbrec_chassis *,
 const struct hmap *local_datapaths,
 const struct sset *active_tunnels);
-static void pinctrl_handle_nd_na(const struct flow *ip_flow,
+static void pinctrl_handle_nd_na(struct rconn *swconn,
+ const struct flow *ip_flow,
  const struct match *md,
  struct ofpbuf *userdata,
  bool is_router);
 static void reload_metadata(struct ofpbuf *ofpacts,
 const struct match *md);
 static void pinctrl_handle_put_nd_ra_opts(
+struct rconn *swconn,
 const struct flow *ip_flow, struct dp_packet *pkt_in,
 struct ofputil_packet_in *pin, struct ofpbuf *userdata,
 struct ofpbuf *continuation);
-static void pinctrl_handle_nd_ns(const struct flow *ip_flow,
+static void pinctrl_handle_nd_ns(struct rconn *swconn,
+ const struct flow *ip_flow,
  struct dp_packet *pkt_in,
  const struct match *md,
  struct ofpbuf *userdata);
@@ -106,6 +111,7 @@ static void init_ipv6_ras(void);
 static void destroy_ipv6_ras(void);
 static void ipv6_ra_wait(void);
 static void send_ipv6_ras(
+struct rconn *swconn,
 struct ovsdb_idl_index *sbrec_port_binding_by_datapath,
 struct ovsdb_idl_index *sbrec_port_binding_by_name,
 const struct hmap *local_datapaths);
@@ -117,7 +123,7 @@ COVERAGE_DEFINE(pinctrl_drop_buffered_packets_map);
 void
 pinctrl_init(void)
 {
-swconn = rconn_create(5, 0, DSCP_DEFAULT, 1 << OFP13_VERSION);
+swconn_ = rconn_create(5, 0, DSCP_DEFAULT, 1 << OFP13_VERSION);
 conn_seq_no = 0;
 init_put_mac_bindings();
 init_send_garps();
@@ -126,7 +132,7 @@ pinctrl_init(void)
 }
 
 static ovs_be32
-queue_msg(struct ofpbuf *msg)
+queue_msg(struct rconn *swconn, struct ofpbuf *msg)
 {
 const struct ofp_header *oh = msg->data;
 ovs_be32 xid = oh->xid;
@@ -135,34 +141,36 @@ queue_msg(struct ofpbuf *msg)
 return xid;
 }
 
-/* Sets up global 'swconn', a newly (re)connected connection to a switch. */
+/* Sets up 'swconn', a newly (re)connected connection to a switch. */
 static void
-pinctrl_setup(void)
+pinctrl_setup(struct rconn *swconn)
 {
 /* Fetch the switch configuration.  The response later will allow us to
  * change the miss_send_len to UINT16_MAX, so that we can enable
  * asynchronous messages. */
-queue_msg(ofpraw_alloc(OFPRAW_OFPT_GET_CONFIG_REQUEST,
+queue_msg(swconn, ofpraw_alloc(OFPRAW_OFPT_GET_CONFIG_REQUEST,
rconn_get_version(swconn), 0));
 
 /* Set a packet-in format that supports userdata.  */
-queue_msg(ofputil_encode_set_packet_in_format(rconn_get_version(swconn),
+queue_msg(swconn,
+  ofputil_encode_set_packet_in_format(rconn_get_version(swconn),
   OFPUTIL_PACKET_IN_NXT2));
 }
 
 

[ovs-dev] [PATCH v3 0/2] ovn-controller: Add a new thread in pinctrl module to process packet-ins

2019-03-15 Thread nusiddiq
From: Numan Siddique 

This series attempts to add a new thread in pinctrl module. This thread
will handle the packet-ins.


v2 -> v3
-
   * Fixed the clang errors.

v1 -> v2
--
  * Added a new patch p1 to the series suggessted by Mark.
  * Addressed the review comments from Han and Mark.

Numan Siddique (2):
  ovn pinctrl: Pass 'struct rconn *swconn' to all the functions which
use it
  ovn-controller: Add a new thread in pinctrl module to handle
packet-ins.

 ovn/controller/pinctrl.c | 752 ++-
 1 file changed, 585 insertions(+), 167 deletions(-)

-- 
2.20.1

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


Re: [ovs-dev] [ovs-discuss] Core dumps generated when running ovs tests in parallel

2019-03-15 Thread Ben Pfaff
On Sat, Mar 16, 2019 at 09:56:49AM +0530, Numan Siddique wrote:
> On Sat, Mar 16, 2019, 2:28 AM Ben Pfaff  wrote:
> 
> > On Sat, Mar 16, 2019 at 12:28:31AM +0530, Numan Siddique wrote:
> > > On my Fedora 29 when ever I run all the ovs tests with "-j5", I see few
> > > core dumps generated for ovsdb-server and python2.
> >
> > There are a couple of tests that intentionally do "kill -SEGV", to test
> > that things work properly in that case.  I suspect you're seeing those.
> 
> Thanks Ben. Sorry for my ignorance.

It surprises everyone at least once.  If you can think of a way to make
it less surprising, let us know--it would be helpful.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


Re: [ovs-dev] [ovs-discuss] Core dumps generated when running ovs tests in parallel

2019-03-15 Thread Numan Siddique
On Sat, Mar 16, 2019, 2:28 AM Ben Pfaff  wrote:

> On Sat, Mar 16, 2019 at 12:28:31AM +0530, Numan Siddique wrote:
> > On my Fedora 29 when ever I run all the ovs tests with "-j5", I see few
> > core dumps generated for ovsdb-server and python2.
>
> There are a couple of tests that intentionally do "kill -SEGV", to test
> that things work properly in that case.  I suspect you're seeing those.
>

Thanks Ben. Sorry for my ignorance.

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


Re: [ovs-dev] [ovs-dev, 1/2] test: Fix fragment-related tests that fail due to small-sized packets

2019-03-15 Thread 0-day Robot
Bleep bloop.  Greetings Yifeng Sun, I am a robot and I have tried out your 
patch.
Thanks for your contribution.

I encountered some error that I wasn't expecting.  See the details below.


git-am:
fatal: patch fragment without header at line 8: @@ -2849,8 +2849,8 @@ 
ADD_VETH(p0, at_ns0, br0, "fc00::1/96")
Repository lacks necessary blobs to fall back on 3-way merge.
Cannot fall back to three-way merge.
Patch failed at 0001 test: Fix fragment-related tests that fail due to 
small-sized packets
The copy of the patch that failed is found in:
   
/var/lib/jenkins/jobs/upstream_build_from_pw/workspace/.git/rebase-apply/patch
When you have resolved this problem, run "git am --resolved".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".


Please check this out.  If you feel there has been an error, please email 
acon...@bytheb.org

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


[ovs-dev] [PATCH 2/2] datapath: Add support for kernel 4.19.x and 4.20.x

2019-03-15 Thread Yifeng Sun
This patch introduces changes needed by OVS to support latest
Linux kernels (4.19.x and 4.20.x). Recent kernels changed many
APIs used by OVS. One major change is that struct nf_conntrack_l3proto
became unvisible outside of kernel, so the needed get_l4proto
function is added in file compact/nf_conntrack_core.c to
accommodate this issue.

This patch doesn't introduce new failed tests when running
'make check-kmod' for kernels listed below:
3.10.0-957.5.1.el7.x86_64
4.4.0-142-generic
4.17.14
4.18.0-16-generic
4.19.26
4.20.13

Travis passed at
https://travis-ci.org/yifsun/ovs-travis/builds/507034016

Signed-off-by: Yifeng Sun 
---
 .travis.yml   |  2 +
 NEWS  |  2 +
 acinclude.m4  | 20 -
 datapath/conntrack.c  | 72 -
 .../include/net/netfilter/nf_conntrack_core.h |  6 ++
 .../net/netfilter/nf_conntrack_count.h|  2 +
 datapath/linux/compat/nf_conncount.c  |  6 +-
 datapath/linux/compat/nf_conntrack_core.c | 80 +++
 datapath/linux/compat/nf_conntrack_proto.c|  3 +
 9 files changed, 186 insertions(+), 7 deletions(-)

diff --git a/.travis.yml b/.travis.yml
index 32d5f1918..dc7a20b6e 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -35,6 +35,8 @@ env:
   - KERNEL=3.16.54 TESTSUITE=1 DPDK=1
   - KERNEL=3.16.54 DPDK_SHARED=1
   - KERNEL=3.16.54 DPDK_SHARED=1 OPTS="--enable-shared"
+  - KERNEL=4.20.16
+  - KERNEL=4.19.29
   - KERNEL=4.18.20
   - KERNEL=4.17.19
   - KERNEL=4.16.18
diff --git a/NEWS b/NEWS
index 1e4744dbd..af5b5222f 100644
--- a/NEWS
+++ b/NEWS
@@ -25,6 +25,8 @@ Post-v2.11.0
- OVN:
  * Select IPAM mac_prefix in a random manner if not provided by the user
- New QoS type "linux-netem" on Linux.
+   - Linux datapath:
+ * Support for the kernel versions 4.19.x, 4.20.x.
 
 v2.11.0 - 19 Feb 2019
 -
diff --git a/acinclude.m4 b/acinclude.m4
index 3cd6ea730..7b11b7740 100644
--- a/acinclude.m4
+++ b/acinclude.m4
@@ -151,10 +151,10 @@ AC_DEFUN([OVS_CHECK_LINUX], [
 AC_MSG_RESULT([$kversion])
 
 if test "$version" -ge 4; then
-   if test "$version" = 4 && test "$patchlevel" -le 18; then
+   if test "$version" = 4 && test "$patchlevel" -le 20; then
   : # Linux 4.x
else
-  AC_ERROR([Linux kernel in $KBUILD is version $kversion, but version 
newer than 4.18.x is not supported (please refer to the FAQ for advice)])
+  AC_ERROR([Linux kernel in $KBUILD is version $kversion, but version 
newer than 4.20.x is not supported (please refer to the FAQ for advice)])
fi
 elif test "$version" = 3 && test "$patchlevel" -ge 10; then
: # Linux 3.x
@@ -583,6 +583,22 @@ AC_DEFUN([OVS_CHECK_LINUX_COMPAT], [
   [OVS_DEFINE([HAVE_VOID_INET_FRAGS_INIT])])
   OVS_GREP_IFELSE([$KSRC/include/net/inetpeer.h], [vif],
   [OVS_DEFINE([HAVE_INETPEER_VIF_SUPPORT])])
+  OVS_FIND_PARAM_IFELSE([$KSRC/include/net/netfilter/nf_conntrack_helper.h],
+[nf_ct_helper_ext_add], [nf_conntrack_helper],
+[OVS_DEFINE([HAVE_NF_CT_HELPER_EXT_ADD_TAKES_HELPER])])
+  OVS_FIND_PARAM_IFELSE([$KSRC/include/net/netfilter/nf_conntrack_core.h],
+[nf_ct_invert_tuple], [l3proto],
+[OVS_DEFINE([HAVE_NF_CT_INVERT_TUPLE_TAKES_L3PROTO])])
+  OVS_GREP_IFELSE([$KSRC/include/net/netfilter/nf_conntrack_core.h], 
[nf_ct_get_tuple],
+  [OVS_DEFINE([HAVE_NF_CT_GET_TUPLE])])
+  OVS_FIND_PARAM_IFELSE([$KSRC/include/net/netfilter/nf_conntrack_core.h],
+[nf_conntrack_in], [net],
+[OVS_DEFINE([HAVE_NF_CONNTRACK_IN_TAKES_NET])])
+  OVS_GREP_IFELSE([$KSRC/include/net/ipv6_frag.h], [IP6_DEFRAG_CONNTRACK_IN],
+  [OVS_DEFINE([HAVE_IPV6_FRAG_H])])
+  OVS_FIND_PARAM_IFELSE([$KSRC/include/net/netfilter/nf_conntrack_l4proto.h],
+[__nf_ct_l4proto_find], [l3proto],
+[OVS_DEFINE([HAVE_NF_CT_L4PROTO_FIND_TAKES_L3PROTO])])
 
   dnl Check for dst_cache and ipv6 lable to use backported tunnel 
infrastructure.
   dnl OVS does not really need ipv6 label field, but its presence signifies 
that
diff --git a/datapath/conntrack.c b/datapath/conntrack.c
index a7dc9e0c3..b9b79e2cc 100644
--- a/datapath/conntrack.c
+++ b/datapath/conntrack.c
@@ -38,6 +38,10 @@
 #include 
 #endif
 
+#if IS_ENABLED(CONFIG_NF_DEFRAG_IPV6) && defined(HAVE_IPV6_FRAG_H)
+#include 
+#endif
+
 #include "datapath.h"
 #include "conntrack.h"
 #include "flow.h"
@@ -645,32 +649,62 @@ static struct nf_conn *
 ovs_ct_find_existing(struct net *net, const struct nf_conntrack_zone *zone,
 u8 l3num, struct sk_buff *skb, bool natted)
 {
-   const struct nf_conntrack_l3proto *l3proto;
const struct nf_conntrack_l4proto *l4proto;
struct 

[ovs-dev] [PATCH 1/2] test: Fix fragment-related tests that fail due to small-sized packets

2019-03-15 Thread Yifeng Sun
These fragment-related tests are failing on later kernels (4.19.x)
because kernel quietly drops any packet fragment that is not the last
but has a size smaller than IPV6_MIN_MTU. This patch fixes
them by increasing their sizes to IPV6_MIN_MTU.

Signed-off-by: Yifeng Sun 
---
 tests/system-traffic.at | 30 +++---
 1 file changed, 15 insertions(+), 15 deletions(-)

diff --git a/tests/system-traffic.at b/tests/system-traffic.at
index b1241812e..42bf09815 100644
--- a/tests/system-traffic.at
+++ b/tests/system-traffic.at
@@ -2611,7 +2611,7 @@ packet-out in_port=1, 
packet=5054000a505400090800453100310011a48
 ])
 
 AT_CHECK([ovs-ofctl bundle br0 bundle.txt])
-# There is one byte of overlap, hence the no packet gets thru. conntrack.
+dnl There is one byte of overlap, hence the no packet gets thru. conntrack.
 AT_CHECK([ovs-appctl dpctl/dump-conntrack | FORMAT_CT(10.1.1.2)], [0], [dnl
 ])
 
@@ -2635,7 +2635,7 @@ packet-out in_port=1, 
packet=5054000a505400090800450001a400012011834
 ])
 
 AT_CHECK([ovs-ofctl bundle br0 bundle.txt])
-# There is one byte of overlap, hence the no packet gets thru. conntrack.
+dnl There is one byte of overlap, hence the no packet gets thru. conntrack.
 AT_CHECK([ovs-appctl dpctl/dump-conntrack | FORMAT_CT(10.1.1.2)], [0], [dnl
 ])
 
@@ -2827,7 +2827,7 @@ ADD_VETH(p0, at_ns0, br0, "fc00::1/96")
 ADD_VETH(p1, at_ns1, br0, "fc00::2/96")
 
 AT_DATA([bundle.txt], [dnl
-packet-out in_port=1, 
packet=5054000a5054000986dd61a02cfffc01fc0211010001000100020008f62900010203040506070809000102030405060708090001020304050607080900010203040506070809000102030405060708090001020304050607080900010203040506070809000102030405060708090001020304050607080900010203040506070809000102030405060708090001020304050607080900010203040506070809000102030405060708090001020304050607080900010203040506070809000102030405060708090001020304050607080900010203040506070809000102030405060708090001020304050607080900010203040506070809000102030405060708090001020304050607080900010203040506070809000102030405060708090001020304050607080900010203040506070809000102030405060708090001020304050607080900010203040506070809000102030405060708090001020304050607080900010203040506070809000102030405060708090001020304050607080900010203040506070809000102030405060708090001020304050607080900010203040506070809,
  actions=ct(commit
 )
+packet-out in_port=1, 
packet=5054000a5054000986dd65002cfffc01fc0211010001000100020008f6290001020304050607080900010203040506070809000102030405060708090001020304050607080900010203040506070809000102030405060708090001020304050607080900010203040506070809000102030405060708090001020304050607080900010203040506070809000102030405060708090001020304050607080900010203040506070809000102030405060708090001020304050607080900010203040506070809000102030405060708090001020304050607080900010203040506070809000102030405060708090001020304050607080900010203040506070809000102030405060708090001020304050607080900010203040506070809000102030405060708090001020304050607080900010203040506070809000102030405060708090001020304050607080900010203040506070809000102030405060708090001020304050607080900010203040506070809000102030405060708090001020304050607080900010203040506070809000102030405060708090001020304050607080900102030405060708090
 
00102030405060708090001020304050607080900010203040506070809000102030405060708090001020304050607080900010203040506070809000102030405060708090001020304050607080900010203040506070809000102030405060708090001020304050607080900010203040506070809000102030405060708090001020304050607080900010203040506070809000102030405060708090001020304050607080900010203040506070809000102030405060708090001020304050607080900010203040506070809000102030405060708090001020304050607080900010203040506070809000102030405060708090001020304050607080900010203040506070809000102030405060708090001020304050607080900010203040506070809000102030405060708090001020304050607080900010203040506070809000102030405060708090001020304050607080900010203040506070809000102030405060708090001020304050607080900010203040506070809001020304050607080900010203040506070809000102030405060708090001020304050607080900010203040506070809000102030405060708090001020304050607080900010203040506070809000102030405060708090001020304050607080900010203040
 

[ovs-dev] [RFC PATCH v2 4/4] L3 N-S support in ovn, avoid chassis redirection as default for vlan backed networks

2019-03-15 Thread Ankur Sharma
Background:
[1] https://mail.openvswitch.org/pipermail/ovs-dev/2018-October/353066.html
[2] 
https://docs.google.com/document/d/1uoQH478wM1OZ16HrxzbOUvk5LvFnfNEWbkPT6Zmm9OU/edit?usp=sharing

This Series:
Layer 2, Layer 3 E-W and Layer 3 N-S (NO NAT) changes for vlan
backed distributed logical router.

This Patch:
a. Add is_chassis_redirect(cr-*) for all VLAN backed logical router
   attached logical switches. This check is done to ensure that
   all the communication with non ovn based endpoints, happens
   only through gateway chassis attached router ports.

b. Return traffic for N-S traffic need not go via redirect chassis
   for VLAN backed networks.
   In the absence of NATing (or any other service provided by a centralized 
chassis),
   we need not redirect the South to North traffic for non overlay traffic.

Signed-off-by: Ankur Sharma 
---
 ovn/northd/ovn-northd.c |  43 +++---
 tests/ovn.at| 204 
 2 files changed, 235 insertions(+), 12 deletions(-)

diff --git a/ovn/northd/ovn-northd.c b/ovn/northd/ovn-northd.c
index bbc893a..0f0e113 100644
--- a/ovn/northd/ovn-northd.c
+++ b/ovn/northd/ovn-northd.c
@@ -5691,6 +5691,20 @@ build_lrouter_flows(struct hmap *datapaths, struct hmap 
*ports,
  * from different chassis. */
 ds_put_format(, " && is_chassis_resident(%s)",
   op->od->l3redirect_port->json_key);
+} else if (op->peer &&
+   op->peer->od->network_type == DP_NETWORK_VLAN) {
+
+   /* For a vlan backed router port, we will always have the
+* is_chassis_resident check. This is because there could be
+* vm/server on vlan network, but not on OVN chassis and could
+* end up arping for router port ip.
+*
+* This check works on the assumption that for OVN chassis VMs,
+* logical switch ARP responder will respond to ARP requests
+* for router port IP.
+*/
+   ds_put_format(, " && is_chassis_resident(\"cr-%s\")",
+ op->key);
 }
 
 ds_clear();
@@ -6645,18 +6659,23 @@ build_lrouter_flows(struct hmap *datapaths, struct hmap 
*ports,
 continue;
 }
 if (od->l3dgw_port && od->l3redirect_port) {
-/* For traffic with outport == l3dgw_port, if the
- * packet did not match any higher priority redirect
- * rule, then the traffic is redirected to the central
- * instance of the l3dgw_port. */
-ds_clear();
-ds_put_format(, "outport == %s",
-  od->l3dgw_port->json_key);
-ds_clear();
-ds_put_format(, "outport = %s; next;",
-  od->l3redirect_port->json_key);
-ovn_lflow_add(lflows, od, S_ROUTER_IN_GW_REDIRECT, 50,
-  ds_cstr(), ds_cstr());
+   /* For VLAN backed networks, default match will not redirect to
+* chassis redirect port. */
+   if (od->l3dgw_port->peer &&
+   od->l3dgw_port->peer->od->network_type == DP_NETWORK_OVERLAY) {
+  /* For traffic with outport == l3dgw_port, if the
+   * packet did not match any higher priority redirect
+   * rule, then the traffic is redirected to the central
+   * instance of the l3dgw_port. */
+  ds_clear();
+  ds_put_format(, "outport == %s",
+od->l3dgw_port->json_key);
+  ds_clear();
+  ds_put_format(, "outport = %s; next;",
+od->l3redirect_port->json_key);
+  ovn_lflow_add(lflows, od, S_ROUTER_IN_GW_REDIRECT, 50,
+ds_cstr(), ds_cstr());
+   }
 
 /* If the Ethernet destination has not been resolved,
  * redirect to the central instance of the l3dgw_port.
diff --git a/tests/ovn.at b/tests/ovn.at
index 6fce847..9e6ad30 100644
--- a/tests/ovn.at
+++ b/tests/ovn.at
@@ -12451,6 +12451,7 @@ test_ip() {
 echo "-- OVN dump --"
 ovn-nbctl show
 ovn-sbctl show
+ovn-sbctl list port_binding
 
 echo "-- hv1 dump --"
 as hv1 ovs-vsctl show
@@ -12579,3 +12580,206 @@ AT_CHECK([as hv2 ovs-appctl fdb/show br-phys | grep 
00:00:01:01:02:07 | grep 100
 OVN_CLEANUP([hv1],[hv2])
 
 AT_CLEANUP
+
+
+AT_SETUP([ovn -- 2 HVs, 2 lports/HV, localnet ports, DVR N-S Ping])
+ovn_start
+
+# In this test cases we create 3 switches, all connected to same
+# physical network (through br-phys on each HV). LS1 and LS2 have
+# 1 VIF each. Each HV has 1 VIF port. The first digit
+# of VIF port name indicates the hypervisor it is bound to, e.g.
+# lp23 means VIF 3 on hv2.
+#
+# All the switches are connected to a logical router "router".
+#
+# Each switch's VLAN tag and their logical 

[ovs-dev] [RFC PATCH v2 3/4] L3 N-S support in ovn, do not replace router port mac on gateway chassis

2019-03-15 Thread Ankur Sharma
Background:
[1] https://mail.openvswitch.org/pipermail/ovs-dev/2018-October/353066.html
[2] 
https://docs.google.com/document/d/1uoQH478wM1OZ16HrxzbOUvk5LvFnfNEWbkPT6Zmm9OU/edit?usp=sharing

This Series:
Layer 2, Layer 3 E-W and Layer 3 N-S (NO NAT) changes for vlan
backed distributed logical router.

This Patch:
a. Do not replace router port mac, if the corrsponding cr- port
   is resident on current chassis.

b. We do not need this, as gateway chassis is where we will advertise
   the router port mac.

Signed-off-by: Ankur Sharma 
---
 ovn/controller/physical.c |  30 --
 ovn/controller/pinctrl.c  |  57 +++--
 ovn/controller/pinctrl.h  |   6 +++
 tests/ovn.at  | 103 +-
 4 files changed, 160 insertions(+), 36 deletions(-)

diff --git a/ovn/controller/physical.c b/ovn/controller/physical.c
index 0fd83ae..71d80e0 100644
--- a/ovn/controller/physical.c
+++ b/ovn/controller/physical.c
@@ -21,6 +21,7 @@
 #include "lflow.h"
 #include "lport.h"
 #include "chassis.h"
+#include "pinctrl.h"
 #include "lib/bundle.h"
 #include "openvswitch/poll-loop.h"
 #include "lib/uuid.h"
@@ -235,8 +236,14 @@ get_zone_ids(const struct sbrec_port_binding *binding,
 }
 
 static void
-put_replace_router_port_mac_flows(const struct sbrec_port_binding 
*localnet_port,
+put_replace_router_port_mac_flows(struct ovsdb_idl_index
+  *sbrec_chassis_by_name,
+  struct ovsdb_idl_index
+  *sbrec_port_binding_by_name,
+  const struct sbrec_port_binding
+  *localnet_port,
   const struct sbrec_chassis *chassis,
+  const struct sset *active_tunnels,
   const struct hmap *local_datapaths,
   struct ofpbuf *ofpacts_p,
   ofp_port_t ofport,
@@ -277,8 +284,22 @@ put_replace_router_port_mac_flows(const struct 
sbrec_port_binding *localnet_port
 char *err_str = NULL;
 struct match match;
 struct ofpact_mac *replace_mac;
+char *cr_peer_name = xasprintf("cr-%s", rport_binding->logical_port);
 
-/* Table 65, priority 150.
+
+if (pinctrl_is_chassis_resident(sbrec_chassis_by_name,
+sbrec_port_binding_by_name,
+chassis, active_tunnels,
+cr_peer_name)) {
+   /* If a router port's chassisredirect port is resident on this 
chassis,
+* then we need not do mac replace. */
+   free(cr_peer_name);
+   continue;
+}
+
+free(cr_peer_name);
+
+   /* Table 65, priority 150.
  * ===
  *
  * Implements output to localnet port.
@@ -793,7 +814,10 @@ consider_port_binding(struct ovsdb_idl_index 
*sbrec_chassis_by_name,
 , ofpacts_p);
 
 if (!strcmp(binding->type, "localnet")) {
-put_replace_router_port_mac_flows(binding, chassis, 
local_datapaths,
+put_replace_router_port_mac_flows(sbrec_chassis_by_name,
+  sbrec_port_binding_by_name,
+  binding, chassis,
+  active_tunnels, local_datapaths,
   ofpacts_p, ofport, flow_table);
 }
 
diff --git a/ovn/controller/pinctrl.c b/ovn/controller/pinctrl.c
index 2a10d1a..72a3d96 100644
--- a/ovn/controller/pinctrl.c
+++ b/ovn/controller/pinctrl.c
@@ -67,13 +67,6 @@ static void destroy_buffered_packets_map(void);
 static void pinctrl_handle_put_mac_binding(const struct flow *md,
const struct flow *headers,
bool is_arp);
-static bool
-pinctrl_is_chassis_resident(struct ovsdb_idl_index *sbrec_chassis_by_name,
-struct ovsdb_idl_index *sbrec_port_binding_by_name,
-const struct sbrec_chassis *chassis,
-const struct sset *active_tunnels,
-const char *port_name);
-
 static void init_put_mac_bindings(void);
 static void destroy_put_mac_bindings(void);
 static void run_put_mac_bindings(
@@ -134,6 +127,31 @@ pinctrl_init(void)
 init_buffered_packets_map();
 }
 
+bool
+pinctrl_is_chassis_resident(struct ovsdb_idl_index *sbrec_chassis_by_name,
+struct ovsdb_idl_index *sbrec_port_binding_by_name,
+const struct sbrec_chassis *chassis,
+const struct sset *active_tunnels,
+const char *port_name)
+{
+const struct sbrec_port_binding *pb
+

[ovs-dev] [RFC PATCH v2 1/4] L3 E-W Support in ovn, replace router port mac with chassis mac.

2019-03-15 Thread Ankur Sharma
Background:
[1] https://mail.openvswitch.org/pipermail/ovs-dev/2018-October/353066.html
[2] 
https://docs.google.com/document/d/1uoQH478wM1OZ16HrxzbOUvk5LvFnfNEWbkPT6Zmm9OU/edit?usp=sharing

This Series:
Layer 2, Layer 3 E-W and Layer 3 N-S (NO NAT) changes for vlan
backed distributed logical router.

This Patch:

L2 :

a. Add 1 more column to the Logical_Switch table in north bound
   schema, to indicate if a logical switch is of type "vlan" or "overlay".
   We will support NULL value in this table as well, to keep it backward
   compatible. NULL value will be treated as "overlay" type by northd.

b. Column name:
   i. network_type: Represents whether network is vlan backed or
   overlay.

c. Update ovn-nbctl ls-add clis to take network type as optional
   input.
   ovn-nbctl ls-add [SWITCH] [TYPE]

d. Add a new ovn-nbctl command to set network type of a logical
   switch.
   ovn-nbctl ls-set-network-type SWITCH vlan|overlay

e. ovn-northd changes to get network_type from northbound database and
   populate the same in external_id column of southbound database as
   following key-value pair:
   network-type = [overlay|vlan]

f. Unit tests to validate above.

L3 :

a. Introduce per physical network chassic mac bindings in ovs.
   For example:
   
ovn-chassis-mac-mappings="physnet1:aa:bb:cc:dd:ee:ff,physnet2:a1:b2:c3:d4:e5:f6"

b. Replace router port mac with a chassis specific mac, by adding a flow
   in table=65, priority=150.
   For example:
   cookie=0x0, duration=67765.830s, table=65, n_packets=0, n_bytes=0,
   idle_age=65534, hard_age=65534, priority=150,reg15=0x1,metadata=0x4,
   dl_src=00:00:01:01:02:03 actions=mod_dl_src:aa:bb:cc:dd:ee:ff,
   mod_vlan_vid:1000,output:16

c. Unit tests to validate above.

Signed-off-by: Ankur Sharma 
---
 ovn/controller/bfd.c|   5 +-
 ovn/controller/binding.c|  12 +--
 ovn/controller/chassis.c|  66 +++-
 ovn/controller/chassis.h|   4 +
 ovn/controller/ovn-controller.8.xml |   7 ++
 ovn/controller/ovn-controller.c |   2 +-
 ovn/controller/ovn-controller.h |   5 +-
 ovn/controller/physical.c   |  96 ++
 ovn/northd/ovn-northd.c |  40 
 ovn/ovn-architecture.7.xml  |  12 +++
 ovn/ovn-nb.ovsschema|   8 +-
 ovn/ovn-nb.xml  |   9 ++
 ovn/ovn-sb.xml  |  15 +++
 ovn/utilities/ovn-nbctl.c   |  45 ++--
 tests/ovn-nbctl.at  |  48 ++---
 tests/ovn-northd.at |  22 
 tests/ovn.at| 197 
 17 files changed, 559 insertions(+), 34 deletions(-)

diff --git a/ovn/controller/bfd.c b/ovn/controller/bfd.c
index 10ab6ac..7e76f22 100644
--- a/ovn/controller/bfd.c
+++ b/ovn/controller/bfd.c
@@ -128,8 +128,9 @@ bfd_travel_gw_related_chassis(
 LIST_FOR_EACH_POP (dp_binding, node, _list) {
 dp = dp_binding->dp;
 free(dp_binding);
-for (size_t i = 0; i < dp->n_peer_dps; i++) {
-const struct sbrec_datapath_binding *pdp = dp->peer_dps[i];
+for (size_t i = 0; i < dp->n_peer_ports; i++) {
+const struct sbrec_datapath_binding *pdp =
+dp->peer_ports[i]->datapath;
 if (!pdp) {
 continue;
 }
diff --git a/ovn/controller/binding.c b/ovn/controller/binding.c
index 74ba127..d286e47 100644
--- a/ovn/controller/binding.c
+++ b/ovn/controller/binding.c
@@ -159,13 +159,11 @@ add_local_datapath__(struct ovsdb_idl_index 
*sbrec_datapath_binding_by_key,
  sbrec_port_binding_by_name,
  peer->datapath, false,
  depth + 1, local_datapaths);
-ld->n_peer_dps++;
-ld->peer_dps = xrealloc(
-ld->peer_dps,
-ld->n_peer_dps * sizeof *ld->peer_dps);
-ld->peer_dps[ld->n_peer_dps - 1] = datapath_lookup_by_key(
-sbrec_datapath_binding_by_key,
-peer->datapath->tunnel_key);
+ld->n_peer_ports++;
+ld->peer_ports = xrealloc(ld->peer_ports,
+  ld->n_peer_ports *
+  sizeof *ld->peer_ports);
+ld->peer_ports[ld->n_peer_ports - 1] = peer;
 }
 }
 }
diff --git a/ovn/controller/chassis.c b/ovn/controller/chassis.c
index 3ea908d..664748e 100644
--- a/ovn/controller/chassis.c
+++ b/ovn/controller/chassis.c
@@ -22,6 +22,7 @@
 #include "lib/vswitch-idl.h"
 #include "openvswitch/dynamic-string.h"
 #include "openvswitch/vlog.h"
+#include "openvswitch/ofp-parse.h"
 #include "ovn/lib/chassis-index.h"
 #include "ovn/lib/ovn-sb-idl.h"
 #include "ovn-controller.h"
@@ -68,6 +69,12 @@ 

[ovs-dev] [RFC PATCH v2 2/4] L3 N-S support in ovn, advertise router port mac from gateway chassis

2019-03-15 Thread Ankur Sharma
Background:
[1] https://mail.openvswitch.org/pipermail/ovs-dev/2018-October/353066.html
[2] 
https://docs.google.com/document/d/1uoQH478wM1OZ16HrxzbOUvk5LvFnfNEWbkPT6Zmm9OU/edit?usp=sharing

This Series:
Layer 2, Layer 3 E-W and Layer 3 N-S (NO NAT) changes for vlan
backed distributed logical router.

This Patch:
a. For N-S (No NAT) case, we will rely on gateway-chassis construct.
   i.e on a logical router, one router port will be assigned gateway
   chassis(s) and this router port becomes the gateway for north to south
   traffic.

b. This patch adds changes to advertise router port (cr-lrp-*) mac on its
   active gateway chassis, by sending GARP.

c. Additionally, patch adds support for sending the GARP series periodically.
   i.e router port mac will be advertised periodically
   (not just when it is realized on a chassis). This is needed because when
   we add NATing support, then south to north traffic will also go via
   gateway chassis.

Signed-off-by: Ankur Sharma 
---
 ovn/controller/pinctrl.c | 173 ---
 ovn/lib/ovn-util.c   |  31 +
 ovn/lib/ovn-util.h   |   6 ++
 3 files changed, 201 insertions(+), 9 deletions(-)

diff --git a/ovn/controller/pinctrl.c b/ovn/controller/pinctrl.c
index 100a20f..2a10d1a 100644
--- a/ovn/controller/pinctrl.c
+++ b/ovn/controller/pinctrl.c
@@ -67,6 +67,13 @@ static void destroy_buffered_packets_map(void);
 static void pinctrl_handle_put_mac_binding(const struct flow *md,
const struct flow *headers,
bool is_arp);
+static bool
+pinctrl_is_chassis_resident(struct ovsdb_idl_index *sbrec_chassis_by_name,
+struct ovsdb_idl_index *sbrec_port_binding_by_name,
+const struct sbrec_chassis *chassis,
+const struct sset *active_tunnels,
+const char *port_name);
+
 static void init_put_mac_bindings(void);
 static void destroy_put_mac_bindings(void);
 static void run_put_mac_bindings(
@@ -114,6 +121,8 @@ static void send_ipv6_ras(
 COVERAGE_DEFINE(pinctrl_drop_put_mac_binding);
 COVERAGE_DEFINE(pinctrl_drop_buffered_packets_map);
 
+#define GARP_DEF_REPEAT_INTERVAL_MS   (3 * 60 * 1000) // 3 mins
+
 void
 pinctrl_init(void)
 {
@@ -2095,6 +2104,8 @@ struct garp_data {
 int backoff; /* Backoff for the next announcement. */
 uint32_t dp_key; /* Datapath used to output this GARP. */
 uint32_t port_key;   /* Port to inject the GARP into. */
+bool is_repeat;  /* Send GARPs continously */
+long long int repeat_interval; /* Interval between GARP bursts in ms */
 };
 
 /* Contains GARPs to be sent. */
@@ -2118,7 +2129,8 @@ destroy_send_garps(void)
 
 static void
 add_garp(const char *name, const struct eth_addr ea, ovs_be32 ip,
- uint32_t dp_key, uint32_t port_key)
+ uint32_t dp_key, uint32_t port_key, bool is_repeat,
+ long long int repeat_interval)
 {
 struct garp_data *garp = xmalloc(sizeof *garp);
 garp->ea = ea;
@@ -2127,15 +2139,19 @@ add_garp(const char *name, const struct eth_addr ea, 
ovs_be32 ip,
 garp->backoff = 1;
 garp->dp_key = dp_key;
 garp->port_key = port_key;
+garp->is_repeat = is_repeat;
+garp->repeat_interval = repeat_interval;
 shash_add(_garp_data, name, garp);
 }
 
 /* Add or update a vif for which GARPs need to be announced. */
 static void
-send_garp_update(const struct sbrec_port_binding *binding_rec,
+send_garp_update(struct ovsdb_idl_index *sbrec_port_binding_by_name,
+ const struct sbrec_port_binding *binding_rec,
  struct shash *nat_addresses)
 {
 volatile struct garp_data *garp = NULL;
+
 /* Update GARP for NAT IP if it exists.  Consider port bindings with type
  * "l3gateway" for logical switch ports attached to gateway routers, and
  * port bindings with type "patch" for logical switch ports attached to
@@ -2157,7 +2173,7 @@ send_garp_update(const struct sbrec_port_binding 
*binding_rec,
 add_garp(name, laddrs->ea,
  laddrs->ipv4_addrs[i].addr,
  binding_rec->datapath->tunnel_key,
- binding_rec->tunnel_key);
+ binding_rec->tunnel_key, false, 0);
 }
 free(name);
 }
@@ -2167,6 +2183,60 @@ send_garp_update(const struct sbrec_port_binding 
*binding_rec,
 return;
 }
 
+/* Update GARPs for local chassisredirect port, if the peer
+ * layer 2 switch is of type vlan.
+ */
+if (!strcmp(binding_rec->type, "chassisredirect")) {
+   struct eth_addr mac;
+   ovs_be32 ip, mask;
+   uint32_t dp_key = 0;
+   uint32_t port_key = 0;
+   const struct sbrec_port_binding *peer_port = NULL;
+   const struct sbrec_port_binding 

[ovs-dev] [RFC PATCH v2 0/4] OVN: Distributed Virtual Router for Vlan Backed Networks

2019-03-15 Thread Ankur Sharma
This series is about enhancing the logical router functionality in OVN to work
with vlan backed logical switches.

Intial proposal was discused here:
[1] https://mail.openvswitch.org/pipermail/ovs-dev/2018-October/353066.html
[2] 
https://docs.google.com/document/d/1uoQH478wM1OZ16HrxzbOUvk5LvFnfNEWbkPT6Zmm9OU/edit?usp=sharing

This series covers following:
a. L2:
   Associate a type with logical switches. Type value could be vlan or overlay.

b. L3 E-W:
   In the absence of encapsulation, we cannot use router port mac as source mac
   (since it is distributed), hence replace the same with a chassis unique mac.

c. L3 N-S:
   Use gateway-chassis construct to respond to ARP requests for router port,
   so that it becomes entry point for all chassis bound traffic coming from
   "external" network.
   Some additional changes, like no need to redirect south to north traffic
   in the absence of NAT etc.

This series does not cover following:
(will be sent out for review in follow up series once this series is 
reviewed/committed)
a. Network Address Translation.
b. Ensuring VMs mac is learnt in underlay network to avoid flooding of L3 flows.

Ankur Sharma (4):
  L3 E-W Support in ovn, replace router port mac with chassis mac.
  L3 N-S support in ovn, advertise router port mac from gateway chassis
  L3 N-S support in ovn, do not replace router port mac on gateway
chassis
  L3 N-S support in ovn, avoid chassis redirection as default for vlan
backed networks

 ovn/controller/bfd.c|   5 +-
 ovn/controller/binding.c|  12 +-
 ovn/controller/chassis.c|  66 -
 ovn/controller/chassis.h|   4 +
 ovn/controller/ovn-controller.8.xml |   7 +
 ovn/controller/ovn-controller.c |   2 +-
 ovn/controller/ovn-controller.h |   5 +-
 ovn/controller/physical.c   | 120 +
 ovn/controller/pinctrl.c| 216 +---
 ovn/controller/pinctrl.h|   6 +
 ovn/lib/ovn-util.c  |  31 +++
 ovn/lib/ovn-util.h  |   6 +
 ovn/northd/ovn-northd.c |  83 +-
 ovn/ovn-architecture.7.xml  |  12 +
 ovn/ovn-nb.ovsschema|   8 +-
 ovn/ovn-nb.xml  |   9 +
 ovn/ovn-sb.xml  |  15 ++
 ovn/utilities/ovn-nbctl.c   |  45 +++-
 tests/ovn-nbctl.at  |  48 +++-
 tests/ovn-northd.at |  22 ++
 tests/ovn.at| 502 
 21 files changed, 1144 insertions(+), 80 deletions(-)

-- 
1.8.3.1

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


Re: [ovs-dev] [patch v6 1/3] conntrack: Fix race for NAT cleanup.

2019-03-15 Thread Darrell Ball
On Fri, Mar 15, 2019 at 4:31 PM Ben Pfaff  wrote:

> On Fri, Mar 15, 2019 at 04:17:34PM -0700, Darrell Ball wrote:
> > On Fri, Mar 15, 2019 at 3:56 PM Ben Pfaff  wrote:
> >
> > > On Fri, Mar 15, 2019 at 03:01:18PM -0700, Darrell Ball wrote:
> > > > Reference lists are not fully protected during cleanup of
> > > > NAT connections where the bucket lock is transiently not held during
> > > > list traversal.  This can lead to referencing freed memory during
> > > > cleaning from multiple contexts.  Fix this by protecting with
> > > > the existing 'cleanup' mutex in the missed cases where 'conn_clean()'
> > > > is called.  'conntrack_flush()' is converted to expiry list traversal
> > > > to support the proper bucket level protection with the 'cleanup'
> mutex.
> > > >
> > > > The NAT exhaustion case cleanup in 'conn_not_found()' is also
> modified
> > > > to avoid the same issue.
> > > >
> > > > Fixes: 286de2729955 ("dpdk: Userspace Datapath: Introduce NAT
> Support.")
> > > > Reported-by: solomon 
> > > > Reported-at:
> > > https://mail.openvswitch.org/pipermail/ovs-dev/2019-March/357056.html
> > > > Tested-by: solomon 
> > > > Signed-off-by: Darrell Ball 
> > > > ---
> > > >
> > > > This patch is targeted for earlier releases as new RCU patches
> > > > inherently don't have this race.
> > > >
> > > > Backport to 2.8.
> > >
> > > Thanks.  I applied this to master, branch-2.11, and branch-2.10.  2.9
> > > and 2.8 had conflicts.
> > >
> >
> > I will create the backport patches for 2.9 and 2.8.
> >
> > Regarding branch 2.8 - it has diverged quite a bit in general from branch
> > >=2.9.
> > This is because of some small features/cosmetic changes that went into
> 2.9.
> > One option would be to bring 2.8 into sync with 2.9 in one patch.
> > Alternatively,
> > backport all dependencies  and fixes separately. Thoughts ?
>
> Usually it's better to backport them separately, because it makes it
> clear at a glance what happened in a list of patches.


yep


> But that can
> sometimes be a lot of trouble, and in that case a single patch can make
> sense.
>

It is the "lot of trouble" part I am trying to avoid. Let me see.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


Re: [ovs-dev] [patch v6 1/3] conntrack: Fix race for NAT cleanup.

2019-03-15 Thread Ben Pfaff
On Fri, Mar 15, 2019 at 04:17:34PM -0700, Darrell Ball wrote:
> On Fri, Mar 15, 2019 at 3:56 PM Ben Pfaff  wrote:
> 
> > On Fri, Mar 15, 2019 at 03:01:18PM -0700, Darrell Ball wrote:
> > > Reference lists are not fully protected during cleanup of
> > > NAT connections where the bucket lock is transiently not held during
> > > list traversal.  This can lead to referencing freed memory during
> > > cleaning from multiple contexts.  Fix this by protecting with
> > > the existing 'cleanup' mutex in the missed cases where 'conn_clean()'
> > > is called.  'conntrack_flush()' is converted to expiry list traversal
> > > to support the proper bucket level protection with the 'cleanup' mutex.
> > >
> > > The NAT exhaustion case cleanup in 'conn_not_found()' is also modified
> > > to avoid the same issue.
> > >
> > > Fixes: 286de2729955 ("dpdk: Userspace Datapath: Introduce NAT Support.")
> > > Reported-by: solomon 
> > > Reported-at:
> > https://mail.openvswitch.org/pipermail/ovs-dev/2019-March/357056.html
> > > Tested-by: solomon 
> > > Signed-off-by: Darrell Ball 
> > > ---
> > >
> > > This patch is targeted for earlier releases as new RCU patches
> > > inherently don't have this race.
> > >
> > > Backport to 2.8.
> >
> > Thanks.  I applied this to master, branch-2.11, and branch-2.10.  2.9
> > and 2.8 had conflicts.
> >
> 
> I will create the backport patches for 2.9 and 2.8.
> 
> Regarding branch 2.8 - it has diverged quite a bit in general from branch
> >=2.9.
> This is because of some small features/cosmetic changes that went into 2.9.
> One option would be to bring 2.8 into sync with 2.9 in one patch.
> Alternatively,
> backport all dependencies  and fixes separately. Thoughts ?

Usually it's better to backport them separately, because it makes it
clear at a glance what happened in a list of patches.  But that can
sometimes be a lot of trouble, and in that case a single patch can make
sense.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


Re: [ovs-dev] [PATCH] Add unixctl option for ovn-northd

2019-03-15 Thread Justin Pettit
It didn't seem like this is different from the original version, so I just 
cherry-picked that back to branch-2.9.

Let me know if I missed something.

--Justin


> On Mar 11, 2019, at 11:35 AM, Mark Michelson  wrote:
> 
> From: Venkata Anil 
> 
> This is a backport to the 2.9 branch of the feature.
> 
> Openstack is requesting this backport in order to have their functional
> suite for OSP13 work properly with OVS 2.9.
> 
> Signed-off-by: Venkata Anil 
> Signed-off-by: Ben Pfaff 
> ---
> lib/automake.mk |  3 ++-
> lib/unixctl.xml | 26 ++
> ovn/northd/ovn-northd.8.xml |  7 +--
> ovn/northd/ovn-northd.c |  9 -
> tests/ovn-northd.at | 39 +++
> 5 files changed, 80 insertions(+), 4 deletions(-)
> create mode 100644 lib/unixctl.xml
> 
> diff --git a/lib/automake.mk b/lib/automake.mk
> index 70461ec8c..73bc4b219 100644
> --- a/lib/automake.mk
> +++ b/lib/automake.mk
> @@ -459,7 +459,8 @@ EXTRA_DIST += \
>   lib/ssl.xml \
>   lib/ssl-bootstrap.xml \
>   lib/table.xml \
> - lib/vlog.xml
> + lib/vlog.xml \
> + lib/unixctl.xml
> 
> MAN_FRAGMENTS += \
>   lib/colors.man \
> diff --git a/lib/unixctl.xml b/lib/unixctl.xml
> new file mode 100644
> index 0..51bfc5faa
> --- /dev/null
> +++ b/lib/unixctl.xml
> @@ -0,0 +1,26 @@
> +
> +
> +  --unixctl=socket
> +  
> +Sets the name of the control socket on which
> +program listens for runtime management commands
> +(see RUNTIME MANAGEMENT COMMANDS, below).  If 
> socket
> +does not begin with /, it is interpreted as relative to
> +@RUNDIR@. If --unixctl is not used at all,
> +the default socket is
> +@RUNDIR@/program.pid.ctl,
> +where pid is program's process ID.
> +  
> +On Windows a local named pipe is used to listen for runtime management
> +commands.  A file is created in the absolute path as pointed by
> +socket or if --unixctl is not used at all,
> +a file is created as program in the configured
> +OVS_RUNDIR directory.  The file exists just to mimic the
> +behavior of a Unix domain socket.
> +  
> +  
> +Specifying none for socket disables the control
> +socket feature.
> +  
> +  
> +
> diff --git a/ovn/northd/ovn-northd.8.xml b/ovn/northd/ovn-northd.8.xml
> index 78df522c9..10ae42cfa 100644
> --- a/ovn/northd/ovn-northd.8.xml
> +++ b/ovn/northd/ovn-northd.8.xml
> @@ -54,8 +54,11 @@
>  xmlns:xi="http://www.w3.org/2003/XInclude"/>
> 
> Other Options
> -
> - xmlns:xi="http://www.w3.org/2003/XInclude"/>
> + + xmlns:xi="http://www.w3.org/2003/XInclude"/>
> +
> + + xmlns:xi="http://www.w3.org/2003/XInclude"/>
> 
> Runtime Management Commands
> 
> diff --git a/ovn/northd/ovn-northd.c b/ovn/northd/ovn-northd.c
> index 82a962b5f..0059cef5d 100644
> --- a/ovn/northd/ovn-northd.c
> +++ b/ovn/northd/ovn-northd.c
> @@ -59,6 +59,7 @@ struct northd_context {
> 
> static const char *ovnnb_db;
> static const char *ovnsb_db;
> +static const char *unixctl_path;
> 
> #define MAC_ADDR_PREFIX 0x0A00ULL
> #define MAC_ADDR_SPACE 0xff
> @@ -239,6 +240,7 @@ Options:\n\
> (default: %s)\n\
>   --ovnsb-db=DATABASE   connect to ovn-sb database at DATABASE\n\
> (default: %s)\n\
> +  --unixctl=SOCKET  override default control socket name\n\
>   -h, --helpdisplay this help message\n\
>   -o, --options list available options\n\
>   -V, --version display version information\n\
> @@ -6701,6 +6703,7 @@ parse_options(int argc OVS_UNUSED, char *argv[] 
> OVS_UNUSED)
> static const struct option long_options[] = {
> {"ovnsb-db", required_argument, NULL, 'd'},
> {"ovnnb-db", required_argument, NULL, 'D'},
> +{"unixctl", required_argument, NULL, 'u'},
> {"help", no_argument, NULL, 'h'},
> {"options", no_argument, NULL, 'o'},
> {"version", no_argument, NULL, 'V'},
> @@ -6732,6 +6735,10 @@ parse_options(int argc OVS_UNUSED, char *argv[] 
> OVS_UNUSED)
> ovnnb_db = optarg;
> break;
> 
> +case 'u':
> +unixctl_path = optarg;
> +break;
> +
> case 'h':
> usage();
> exit(EXIT_SUCCESS);
> @@ -6784,7 +6791,7 @@ main(int argc, char *argv[])
> 
> daemonize_start(false);
> 
> -retval = unixctl_server_create(NULL, );
> +retval = unixctl_server_create(unixctl_path, );
> if (retval) {
> exit(EXIT_FAILURE);
> }
> diff --git a/tests/ovn-northd.at b/tests/ovn-northd.at
> index baa2add41..1878eb2df 100644
> --- a/tests/ovn-northd.at
> +++ b/tests/ovn-northd.at
> @@ -262,3 +262,42 @@ AT_CHECK_UNQUOTED([ovn-sbctl get Port_Binding ${uuid} 
> options:ipv6_ra_prefixes],
> ])
> 
> AT_CLEANUP
> +
> +AT_SETUP([ovn -- test unixctl])
> +ovn_init_db ovn-sb; ovn-sbctl init
> +ovn_init_db ovn-nb; ovn-nbctl init
> 

Re: [ovs-dev] [PATCH] ovsdb raft: Sync commit index to followers without delay.

2019-03-15 Thread Han Zhou
On Fri, Mar 15, 2019 at 3:37 PM Han Zhou  wrote:
>
> On Fri, Mar 15, 2019 at 3:30 PM Ben Pfaff  wrote:
> >
> > On Thu, Mar 14, 2019 at 10:13:56AM -0700, Han Zhou wrote:
> > > From: Han Zhou 
> > >
> > > When update is requested from follower, the leader sends AppendRequest
> > > to all followers and wait until AppendReply received from majority, and
> > > then it will update commit index - the new entry is regarded as committed
> > > in raft log. However, this commit will not be notified to followers
> > > (including the one initiated the request) until next heartbeat (ping
> > > timeout), if no other pending requests. This results in long latency
> > > for updates made through followers, especially when a batch of updates
> > > are requested through the same follower.
> > >
> > > $ time for i in `seq 1 100`; do ovn-nbctl ls-add ls$i; done
> > >
> > > real0m34.154s
> > > user0m0.083s
> > > sys 0m0.250s
> > >
> > > This patch solves the problem by sending heartbeat as soon as the commit
> > > index is updated in leader. It also avoids unnessary heartbeat by 
> > > resetting
> > > the ping timer whenever AppendRequest is broadcasted. With this patch
> > > the performance is improved more than 50 times in same test:
> > >
> > > $ time for i in `seq 1 100`; do ovn-nbctl ls-add ls$i; done
> > >
> > > real0m0.564s
> > > user0m0.080s
> > > sys 0m0.199s
> > >
> > > The parameters in torture test is also adjusted because of the improved
> > > performance, otherwise the tests will all be skipped.
> >
> > The patch seems very reasonable and the concept makes sense, but when I
> > run
> > make -j10 check TESTSUITEFLAGS='-k ovsdb,cluster,torture -j10'
> > it comes near to killing my laptop, with multiple ovsdb-servers going to
> > 100% CPU.  Without the patch, I don't see behavior like that at all.
> >
> > Do you see the same thing?
>
> I think this is caused by the change in torture test case, as
> mentioned in the commit message: The parameters in torture test is
> also adjusted because of the improved
> performance, otherwise the tests will all be skipped. (because all
> clients finishes the tasks at phase 0)
>
> Unlike other tests, I never run torture tests using -j, since it is
> more related to timing and less stable. Now since I increased the
> clients to 20 x 40 in the test, it is likely to kill your laptop by
> using -j10. Do you have any suggestion for this? Maybe I can try keep
> the number of clients small but put some sleep between requests to
> slow them down.

Adding sleep helped. I just sent v2 that keeps original number of
clients (10 x 5) but adds some sleep. I verified with no -j and also
with -j10, all tests passed in both.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


Re: [ovs-dev] [PATCH] lib: added check to prevent int overflow

2019-03-15 Thread Ben Pfaff
On Tue, Mar 12, 2019 at 08:26:43AM -0700, Toms Atteka wrote:
> If enough large input is given ofpact_finish will fail.
> Check was added and error message returned.
> 
> Basic manual testing performed.
> 
> Reported-by:
> https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=12972
> Signed-off-by: Toms Atteka 

Thanks for the fix.

Would you mind adding a helper function that does the check?  It is
better to introduce a new function ofpact_oversized(), or whatever, than
to introduce too many details of the implementation into
learn_parse__().

Did you try to look around for other uses of ofpact_finish_*(), to see
whether other cases could have the same problem?

Thanks,

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


[ovs-dev] [PATCH v2] ovsdb raft: Sync commit index to followers without delay.

2019-03-15 Thread Han Zhou
From: Han Zhou 

When update is requested from follower, the leader sends AppendRequest
to all followers and wait until AppendReply received from majority, and
then it will update commit index - the new entry is regarded as committed
in raft log. However, this commit will not be notified to followers
(including the one initiated the request) until next heartbeat (ping
timeout), if no other pending requests. This results in long latency
for updates made through followers, especially when a batch of updates
are requested through the same follower.

$ time for i in `seq 1 100`; do ovn-nbctl ls-add ls$i; done

real0m34.154s
user0m0.083s
sys 0m0.250s

This patch solves the problem by sending heartbeat as soon as the commit
index is updated in leader. It also avoids unnessary heartbeat by resetting
the ping timer whenever AppendRequest is broadcasted. With this patch
the performance is improved more than 50 times in same test:

$ time for i in `seq 1 100`; do ovn-nbctl ls-add ls$i; done

real0m0.564s
user0m0.080s
sys 0m0.199s

Some sleep is added in torture test cases because of the improved
performance, otherwise the tests will all be skipped.

Signed-off-by: Han Zhou 
---

Notes:
v1->v2: adjust torture test case so that it passes without overload CPU.

 ovsdb/raft.c   | 43 +--
 tests/ovsdb-cluster.at |  3 ++-
 2 files changed, 31 insertions(+), 15 deletions(-)

diff --git a/ovsdb/raft.c b/ovsdb/raft.c
index eee4f33..31e9e72 100644
--- a/ovsdb/raft.c
+++ b/ovsdb/raft.c
@@ -320,7 +320,8 @@ static void raft_send_append_request(struct raft *,
 
 static void raft_become_leader(struct raft *);
 static void raft_become_follower(struct raft *);
-static void raft_reset_timer(struct raft *);
+static void raft_reset_election_timer(struct raft *);
+static void raft_reset_ping_timer(struct raft *);
 static void raft_send_heartbeats(struct raft *);
 static void raft_start_election(struct raft *, bool leadership_transfer);
 static bool raft_truncate(struct raft *, uint64_t new_end);
@@ -376,8 +377,8 @@ raft_alloc(void)
 hmap_init(>add_servers);
 hmap_init(>commands);
 
-raft->ping_timeout = time_msec() + PING_TIME_MSEC;
-raft_reset_timer(raft);
+raft_reset_ping_timer(raft);
+raft_reset_election_timer(raft);
 
 return raft;
 }
@@ -865,7 +866,7 @@ raft_read_log(struct raft *raft)
 }
 
 static void
-raft_reset_timer(struct raft *raft)
+raft_reset_election_timer(struct raft *raft)
 {
 unsigned int duration = (ELECTION_BASE_MSEC
  + random_range(ELECTION_RANGE_MSEC));
@@ -874,6 +875,12 @@ raft_reset_timer(struct raft *raft)
 }
 
 static void
+raft_reset_ping_timer(struct raft *raft)
+{
+raft->ping_timeout = time_msec() + PING_TIME_MSEC;
+}
+
+static void
 raft_add_conn(struct raft *raft, struct jsonrpc_session *js,
   const struct uuid *sid, bool incoming)
 {
@@ -1603,7 +1610,7 @@ raft_start_election(struct raft *raft, bool 
leadership_transfer)
 VLOG_INFO("term %"PRIu64": starting election", raft->term);
 }
 }
-raft_reset_timer(raft);
+raft_reset_election_timer(raft);
 
 struct raft_server *peer;
 HMAP_FOR_EACH (peer, hmap_node, >servers) {
@@ -1782,8 +1789,8 @@ raft_run(struct raft *raft)
 raft_command_complete(raft, cmd, RAFT_CMD_TIMEOUT);
 }
 }
+raft_reset_ping_timer(raft);
 }
-raft->ping_timeout = time_msec() + PING_TIME_MSEC;
 }
 
 /* Do this only at the end; if we did it as soon as we set raft->left or
@@ -1963,6 +1970,7 @@ raft_command_initiate(struct raft *raft,
 s->next_index++;
 }
 }
+raft_reset_ping_timer(raft);
 
 return cmd;
 }
@@ -2313,7 +2321,7 @@ raft_become_follower(struct raft *raft)
 }
 
 raft->role = RAFT_FOLLOWER;
-raft_reset_timer(raft);
+raft_reset_election_timer(raft);
 
 /* Notify clients about lost leadership.
  *
@@ -2387,6 +2395,8 @@ raft_send_heartbeats(struct raft *raft)
 RAFT_CMD_INCOMPLETE, 0);
 }
 }
+
+raft_reset_ping_timer(raft);
 }
 
 /* Initializes the fields in 's' that represent the leader's view of the
@@ -2413,7 +2423,7 @@ raft_become_leader(struct raft *raft)
 raft->role = RAFT_LEADER;
 raft->leader_sid = raft->sid;
 raft->election_timeout = LLONG_MAX;
-raft->ping_timeout = time_msec() + PING_TIME_MSEC;
+raft_reset_ping_timer(raft);
 
 struct raft_server *s;
 HMAP_FOR_EACH (s, hmap_node, >servers) {
@@ -2573,11 +2583,13 @@ raft_get_next_entry(struct raft *raft, struct uuid *eid)
 return data;
 }
 
-static void
+/* Updates commit index in raft log. If commit index is already up-to-date
+ * it does nothing and return false, otherwise, returns true. */
+static bool
 raft_update_commit_index(struct raft *raft, uint64_t new_commit_index)
 {
 if (new_commit_index <= 

Re: [ovs-dev] [patch v6 1/3] conntrack: Fix race for NAT cleanup.

2019-03-15 Thread Darrell Ball
On Fri, Mar 15, 2019 at 3:56 PM Ben Pfaff  wrote:

> On Fri, Mar 15, 2019 at 03:01:18PM -0700, Darrell Ball wrote:
> > Reference lists are not fully protected during cleanup of
> > NAT connections where the bucket lock is transiently not held during
> > list traversal.  This can lead to referencing freed memory during
> > cleaning from multiple contexts.  Fix this by protecting with
> > the existing 'cleanup' mutex in the missed cases where 'conn_clean()'
> > is called.  'conntrack_flush()' is converted to expiry list traversal
> > to support the proper bucket level protection with the 'cleanup' mutex.
> >
> > The NAT exhaustion case cleanup in 'conn_not_found()' is also modified
> > to avoid the same issue.
> >
> > Fixes: 286de2729955 ("dpdk: Userspace Datapath: Introduce NAT Support.")
> > Reported-by: solomon 
> > Reported-at:
> https://mail.openvswitch.org/pipermail/ovs-dev/2019-March/357056.html
> > Tested-by: solomon 
> > Signed-off-by: Darrell Ball 
> > ---
> >
> > This patch is targeted for earlier releases as new RCU patches
> > inherently don't have this race.
> >
> > Backport to 2.8.
>
> Thanks.  I applied this to master, branch-2.11, and branch-2.10.  2.9
> and 2.8 had conflicts.
>

I will create the backport patches for 2.9 and 2.8.

Regarding branch 2.8 - it has diverged quite a bit in general from branch
>=2.9.
This is because of some small features/cosmetic changes that went into 2.9.
One option would be to bring 2.8 into sync with 2.9 in one patch.
Alternatively,
backport all dependencies  and fixes separately. Thoughts ?
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


Re: [ovs-dev] [PATCH] manpages: Highlight --ct-next option.

2019-03-15 Thread Ben Pfaff
On Tue, Mar 12, 2019 at 11:01:03AM -0700, Yi-Hung Wei wrote:
> On Tue, Mar 12, 2019 at 5:53 AM Ilya Maximets  wrote:
> >
> > This makes it look like other options.
> >
> > Signed-off-by: Ilya Maximets 
> > ---
> Thanks for improving this manpage.
> 
> Acked-by: Yi-Hung Wei 

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


[ovs-dev] [PATCH v1] ofp-monitor: Fixed the usage of 'usable_protocols' variable in 'parse_flow_monitor_request' function.

2019-03-15 Thread Ashish Varma
'usable_protocols' is now getting set to OFPUTIL_P_OF10_ANY on return from
'parse_flow_monitor_request' function. The calling function now checks for the
value in this variable against the 'allowed_protocols' variable.
Also a check is added for a match field which is not supported in OpenFlow 1.0
and return an error.
Modified the man page of ovs-ofctl to reflect Flow Monitor support as
OpenFlow 1.0 Nicira extension only.

Signed-off-by: Ashish Varma 
---
 lib/ofp-monitor.c| 8 
 utilities/ovs-ofctl.8.in | 3 ++-
 utilities/ovs-ofctl.c| 8 
 3 files changed, 18 insertions(+), 1 deletion(-)

diff --git a/lib/ofp-monitor.c b/lib/ofp-monitor.c
index aeebd7e..d24ffe5 100644
--- a/lib/ofp-monitor.c
+++ b/lib/ofp-monitor.c
@@ -469,6 +469,8 @@ parse_flow_monitor_request__(struct 
ofputil_flow_monitor_request *fmr,
 fmr->table_id = 0xff;
 match_init_catchall(>match);
 
+/* A match field may reduce the usable protocols. */
+*usable_protocols = OFPUTIL_P_ANY;
 while (ofputil_parse_key_value(, , )) {
 const struct ofp_protocol *p;
 char *error = NULL;
@@ -493,6 +495,10 @@ parse_flow_monitor_request__(struct 
ofputil_flow_monitor_request *fmr,
 } else if (mf_from_name(name)) {
 error = ofp_parse_field(mf_from_name(name), value, port_map,
 >match, usable_protocols);
+if (!error && !(*usable_protocols & OFPUTIL_P_OF10_ANY)) {
+return xasprintf("%s: match field is not supported for "
+ "flow monitor", name);
+}
 } else {
 if (!*value) {
 return xasprintf("%s: field %s missing value", str_, name);
@@ -514,6 +520,8 @@ parse_flow_monitor_request__(struct 
ofputil_flow_monitor_request *fmr,
 return error;
 }
 }
+/* Flow Monitor is supported in OpenFlow 1.0 only. */
+*usable_protocols = OFPUTIL_P_OF10_ANY;
 return NULL;
 }
 
diff --git a/utilities/ovs-ofctl.8.in b/utilities/ovs-ofctl.8.in
index 60b4a1c..cb5c612 100644
--- a/utilities/ovs-ofctl.8.in
+++ b/utilities/ovs-ofctl.8.in
@@ -578,7 +578,8 @@ monitoring will not show any traffic.
 .IP "\fBmonitor \fIswitch\fR [\fImiss-len\fR] [\fBinvalid_ttl\fR] 
[\fBwatch:\fR[\fIspec\fR...]]"
 Connects to \fIswitch\fR and prints to the console all OpenFlow
 messages received.  Usually, \fIswitch\fR should specify the name of a
-bridge in the \fBovs\-vswitchd\fR database.
+bridge in the \fBovs\-vswitchd\fR database. This is available only in
+OpenFlow 1.0 as Nicira extension.
 .IP
 If \fImiss-len\fR is provided, \fBovs\-ofctl\fR sends an OpenFlow ``set
 configuration'' message at connection setup time that requests
diff --git a/utilities/ovs-ofctl.c b/utilities/ovs-ofctl.c
index 63620e4..926a4f6 100644
--- a/utilities/ovs-ofctl.c
+++ b/utilities/ovs-ofctl.c
@@ -2286,6 +2286,14 @@ ofctl_monitor(struct ovs_cmdl_context *ctx)
 ovs_fatal(0, "%s", error);
 }
 
+if (!(usable_protocols & allowed_protocols)) {
+char *allowed_s =
+ofputil_protocols_to_string(allowed_protocols);
+char *usable_s = ofputil_protocols_to_string(usable_protocols);
+ovs_fatal(0, "none of the usable protocols (%s) are among "
+"the allowed protocols (%s)", usable_s, allowed_s);
+}
+
 msg = ofpbuf_new(0);
 ofputil_append_flow_monitor_request(, msg);
 dump_transaction(vconn, msg);
-- 
2.7.4

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


Re: [ovs-dev] [PATCH v1] ofp-protocol: Changed the number of bits in OFPUTIL_P_ANY from 10 to 9.

2019-03-15 Thread Ben Pfaff
On Wed, Mar 13, 2019 at 11:31:05AM -0700, Ashish Varma wrote:
> The removal of support for OpenFlow 1.6 (draft) resulted in the removal of
> "OFPUTIL_P_OF16_OXM 1 << 9". OFPUTIL_P_ANY which represets all protocols will
> now have only 9 valid bits.
> 
> Signed-off-by: Ashish Varma 

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


Re: [ovs-dev] [patch v6 3/3] conntrack: Replace structure copy by memcpy().

2019-03-15 Thread Ben Pfaff
On Fri, Mar 15, 2019 at 03:01:20PM -0700, Darrell Ball wrote:
> There are a few cases where structure copy can be replaced by
> memcpy(), for possible portability benefit.  This is because
> the structures involved have padding and elements of the
> structure are used to generate hashes.
> 
> Signed-off-by: Darrell Ball 

Thanks, applied to master, 2.11, 2.10.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


Re: [ovs-dev] [ovs-dev, v6, 1/3] conntrack: Fix race for NAT cleanup.

2019-03-15 Thread 0-day Robot
Bleep bloop.  Greetings Darrell Ball, I am a robot and I have tried out your 
patch.
Thanks for your contribution.

I encountered some error that I wasn't expecting.  See the details below.


git-am:
Failed to merge in the changes.
Patch failed at 0001 conntrack: Fix race for NAT cleanup.
The copy of the patch that failed is found in:
   
/var/lib/jenkins/jobs/upstream_build_from_pw/workspace/.git/rebase-apply/patch
When you have resolved this problem, run "git am --resolved".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".


Please check this out.  If you feel there has been an error, please email 
acon...@bytheb.org

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


Re: [ovs-dev] [patch v6 2/3] conntrack: Lookup only 'UNNAT conns' in 'nat_clean()'.

2019-03-15 Thread Ben Pfaff
On Fri, Mar 15, 2019 at 03:01:19PM -0700, Darrell Ball wrote:
> When freeing 'UNNAT conns', lookup only 'UNNAT conns' to
> protect against possible address overlap with 'default
> conns' during a DOS attempt.  This is very unlikely, but
> protection is simple.
> 
> Fixes: 286de2729955 ("dpdk: Userspace Datapath: Introduce NAT Support.")
> Signed-off-by: Darrell Ball 
> ---
> 
> This patch is targeted for earlier releases as new RCU patches
> inherently don't have this race.
> 
> Backport to 2.8.

Applied to master, 2.11, 2.10.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


Re: [ovs-dev] [patch v6 1/3] conntrack: Fix race for NAT cleanup.

2019-03-15 Thread Ben Pfaff
On Fri, Mar 15, 2019 at 03:01:18PM -0700, Darrell Ball wrote:
> Reference lists are not fully protected during cleanup of
> NAT connections where the bucket lock is transiently not held during
> list traversal.  This can lead to referencing freed memory during
> cleaning from multiple contexts.  Fix this by protecting with
> the existing 'cleanup' mutex in the missed cases where 'conn_clean()'
> is called.  'conntrack_flush()' is converted to expiry list traversal
> to support the proper bucket level protection with the 'cleanup' mutex.
> 
> The NAT exhaustion case cleanup in 'conn_not_found()' is also modified
> to avoid the same issue.
> 
> Fixes: 286de2729955 ("dpdk: Userspace Datapath: Introduce NAT Support.")
> Reported-by: solomon 
> Reported-at: 
> https://mail.openvswitch.org/pipermail/ovs-dev/2019-March/357056.html
> Tested-by: solomon 
> Signed-off-by: Darrell Ball 
> ---
> 
> This patch is targeted for earlier releases as new RCU patches
> inherently don't have this race.
> 
> Backport to 2.8.

Thanks.  I applied this to master, branch-2.11, and branch-2.10.  2.9
and 2.8 had conflicts.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


Re: [ovs-dev] [PATCH] ovsdb raft: Sync commit index to followers without delay.

2019-03-15 Thread Han Zhou
On Fri, Mar 15, 2019 at 3:30 PM Ben Pfaff  wrote:
>
> On Thu, Mar 14, 2019 at 10:13:56AM -0700, Han Zhou wrote:
> > From: Han Zhou 
> >
> > When update is requested from follower, the leader sends AppendRequest
> > to all followers and wait until AppendReply received from majority, and
> > then it will update commit index - the new entry is regarded as committed
> > in raft log. However, this commit will not be notified to followers
> > (including the one initiated the request) until next heartbeat (ping
> > timeout), if no other pending requests. This results in long latency
> > for updates made through followers, especially when a batch of updates
> > are requested through the same follower.
> >
> > $ time for i in `seq 1 100`; do ovn-nbctl ls-add ls$i; done
> >
> > real0m34.154s
> > user0m0.083s
> > sys 0m0.250s
> >
> > This patch solves the problem by sending heartbeat as soon as the commit
> > index is updated in leader. It also avoids unnessary heartbeat by resetting
> > the ping timer whenever AppendRequest is broadcasted. With this patch
> > the performance is improved more than 50 times in same test:
> >
> > $ time for i in `seq 1 100`; do ovn-nbctl ls-add ls$i; done
> >
> > real0m0.564s
> > user0m0.080s
> > sys 0m0.199s
> >
> > The parameters in torture test is also adjusted because of the improved
> > performance, otherwise the tests will all be skipped.
>
> The patch seems very reasonable and the concept makes sense, but when I
> run
> make -j10 check TESTSUITEFLAGS='-k ovsdb,cluster,torture -j10'
> it comes near to killing my laptop, with multiple ovsdb-servers going to
> 100% CPU.  Without the patch, I don't see behavior like that at all.
>
> Do you see the same thing?

I think this is caused by the change in torture test case, as
mentioned in the commit message: The parameters in torture test is
also adjusted because of the improved
performance, otherwise the tests will all be skipped. (because all
clients finishes the tasks at phase 0)

Unlike other tests, I never run torture tests using -j, since it is
more related to timing and less stable. Now since I increased the
clients to 20 x 40 in the test, it is likely to kill your laptop by
using -j10. Do you have any suggestion for this? Maybe I can try keep
the number of clients small but put some sleep between requests to
slow them down.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


Re: [ovs-dev] [PATCH v3] checkpatch: Normalize exit code for Windows

2019-03-15 Thread Ben Pfaff
On Wed, Mar 13, 2019 at 04:03:46PM +0200, Alin Gabriel Serdean wrote:
> Using python `sys.exit(-1)` on Windows produces mixed results.
> Let's take the following results from different shells:
> CMD
> >python -c "import sys; sys.exit(-1)" & echo %errorlevel%
> 1
> MSYS
> $ python -c "import sys; sys.exit(-1)" && echo $?
> 0
> WSL
> $ python -c "import sys; sys.exit(-1)"; echo $?
> 255
> 
> this results in the following tests to fail:
> checkpatch
> 
>  10: checkpatch - sign-offs  FAILED (checkpatch.at:32)
>  11: checkpatch - parenthesized constructs   FAILED (checkpatch.at:32)
>  12: checkpatch - parenthesized constructs - for FAILED (checkpatch.at:32)
>  13: checkpatch - comments   FAILED (checkpatch.at:32)
> 
> because of:
>  ./checkpatch.at:32: exit code was 0, expected 255
> 
> This patch introduces a positive constant for the default exit code.
> 
> Signed-off-by: Alin Gabriel Serdean 
> Acked-by: Ben Pfaff 
> Acked-by: Aaron Conole 

I'd be inclined to set EXIT_FAILURE to 1 (not 255), because that is what
other OVS utilities do, but it does not really matter.

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


Re: [ovs-dev] [PATCH] ovsdb raft: Sync commit index to followers without delay.

2019-03-15 Thread Ben Pfaff
On Thu, Mar 14, 2019 at 10:13:56AM -0700, Han Zhou wrote:
> From: Han Zhou 
> 
> When update is requested from follower, the leader sends AppendRequest
> to all followers and wait until AppendReply received from majority, and
> then it will update commit index - the new entry is regarded as committed
> in raft log. However, this commit will not be notified to followers
> (including the one initiated the request) until next heartbeat (ping
> timeout), if no other pending requests. This results in long latency
> for updates made through followers, especially when a batch of updates
> are requested through the same follower.
> 
> $ time for i in `seq 1 100`; do ovn-nbctl ls-add ls$i; done
> 
> real0m34.154s
> user0m0.083s
> sys 0m0.250s
> 
> This patch solves the problem by sending heartbeat as soon as the commit
> index is updated in leader. It also avoids unnessary heartbeat by resetting
> the ping timer whenever AppendRequest is broadcasted. With this patch
> the performance is improved more than 50 times in same test:
> 
> $ time for i in `seq 1 100`; do ovn-nbctl ls-add ls$i; done
> 
> real0m0.564s
> user0m0.080s
> sys 0m0.199s
> 
> The parameters in torture test is also adjusted because of the improved
> performance, otherwise the tests will all be skipped.

The patch seems very reasonable and the concept makes sense, but when I
run
make -j10 check TESTSUITEFLAGS='-k ovsdb,cluster,torture -j10'
it comes near to killing my laptop, with multiple ovsdb-servers going to
100% CPU.  Without the patch, I don't see behavior like that at all.

Do you see the same thing?
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


[ovs-dev] [patch v6 3/3] conntrack: Replace structure copy by memcpy().

2019-03-15 Thread Darrell Ball
There are a few cases where structure copy can be replaced by
memcpy(), for possible portability benefit.  This is because
the structures involved have padding and elements of the
structure are used to generate hashes.

Signed-off-by: Darrell Ball 
---

Backport to 2.8.

v6: No change to this patch.
v5: New patch and moved some changes from Patch 1 here.

 lib/conntrack.c | 21 -
 1 file changed, 12 insertions(+), 9 deletions(-)

diff --git a/lib/conntrack.c b/lib/conntrack.c
index 5235690..010cbfb 100644
--- a/lib/conntrack.c
+++ b/lib/conntrack.c
@@ -936,7 +936,7 @@ conn_not_found(struct conntrack *ct, struct dp_packet *pkt,
 nc = 
 memset(nc, 0, sizeof *nc);
 memcpy(>key, >key, sizeof nc->key);
-nc->rev_key = nc->key;
+memcpy(>rev_key, >key, sizeof nc->rev_key);
 conn_key_reverse(>rev_key);
 
 if (ct_verify_helper(helper, ct_alg_ctl)) {
@@ -987,7 +987,7 @@ conn_not_found(struct conntrack *ct, struct dp_packet *pkt,
 
 /* Update nc with nat adjustments made to
  * conn_for_un_nat_copy by nat_select_range_tuple(). */
-*nc = *conn_for_un_nat_copy;
+memcpy(nc, conn_for_un_nat_copy, sizeof *nc);
 }
 conn_for_un_nat_copy->conn_type = CT_CONN_TYPE_UN_NAT;
 conn_for_un_nat_copy->nat_info = NULL;
@@ -1078,8 +1078,8 @@ create_un_nat_conn(struct conntrack *ct, struct conn 
*conn_for_un_nat_copy,
long long now, bool alg_un_nat)
 {
 struct conn *nc = xmemdup(conn_for_un_nat_copy, sizeof *nc);
-nc->key = conn_for_un_nat_copy->rev_key;
-nc->rev_key = conn_for_un_nat_copy->key;
+memcpy(>key, _for_un_nat_copy->rev_key, sizeof nc->key);
+memcpy(>rev_key, _for_un_nat_copy->key, sizeof nc->rev_key);
 uint32_t un_nat_hash = conn_key_hash(>key, ct->hash_basis);
 unsigned un_nat_conn_bucket = hash_to_bucket(un_nat_hash);
 ct_lock_lock(>buckets[un_nat_conn_bucket].lock);
@@ -1268,7 +1268,7 @@ process_one(struct conntrack *ct, struct dp_packet *pkt,
 
 struct conn_lookup_ctx ctx2;
 ctx2.conn = NULL;
-ctx2.key = conn->rev_key;
+memcpy(, >rev_key, sizeof ctx2.key);
 ctx2.hash = conn_key_hash(>rev_key, ct->hash_basis);
 
 ct_lock_unlock(>buckets[bucket].lock);
@@ -1354,7 +1354,7 @@ process_one(struct conntrack *ct, struct dp_packet *pkt,
 
 struct conn conn_for_expectation;
 if (OVS_UNLIKELY((ct_alg_ctl != CT_ALG_CTL_NONE) && conn)) {
-conn_for_expectation = *conn;
+memcpy(_for_expectation, conn, sizeof conn_for_expectation);
 }
 
 ct_lock_unlock(>buckets[bucket].lock);
@@ -2334,8 +2334,10 @@ nat_conn_keys_insert(struct hmap *nat_conn_keys, const 
struct conn *nat_conn,
 
 if (!nat_conn_key_node) {
 struct nat_conn_key_node *nat_conn_key = xzalloc(sizeof *nat_conn_key);
-nat_conn_key->key = nat_conn->rev_key;
-nat_conn_key->value = nat_conn->key;
+memcpy(_conn_key->key, _conn->rev_key,
+   sizeof nat_conn_key->key);
+memcpy(_conn_key->value, _conn->key,
+   sizeof nat_conn_key->value);
 hmap_insert(nat_conn_keys, _conn_key->node,
 conn_key_hash(_conn_key->key, basis));
 return true;
@@ -2823,7 +2825,8 @@ expectation_create(struct conntrack *ct, ovs_be16 
dst_port,
 alg_exp_node->key.dst.port = dst_port;
 alg_exp_node->master_mark = master_conn->mark;
 alg_exp_node->master_label = master_conn->label;
-alg_exp_node->master_key = master_conn->key;
+memcpy(_exp_node->master_key, _conn->key,
+   sizeof alg_exp_node->master_key);
 /* Take the write lock here because it is almost 100%
  * likely that the lookup will fail and
  * expectation_create() will be called below. */
-- 
1.9.1

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


[ovs-dev] [patch v6 1/3] conntrack: Fix race for NAT cleanup.

2019-03-15 Thread Darrell Ball
Reference lists are not fully protected during cleanup of
NAT connections where the bucket lock is transiently not held during
list traversal.  This can lead to referencing freed memory during
cleaning from multiple contexts.  Fix this by protecting with
the existing 'cleanup' mutex in the missed cases where 'conn_clean()'
is called.  'conntrack_flush()' is converted to expiry list traversal
to support the proper bucket level protection with the 'cleanup' mutex.

The NAT exhaustion case cleanup in 'conn_not_found()' is also modified
to avoid the same issue.

Fixes: 286de2729955 ("dpdk: Userspace Datapath: Introduce NAT Support.")
Reported-by: solomon 
Reported-at: 
https://mail.openvswitch.org/pipermail/ovs-dev/2019-March/357056.html
Tested-by: solomon 
Signed-off-by: Darrell Ball 
---

This patch is targeted for earlier releases as new RCU patches
inherently don't have this race.

Backport to 2.8.

v6: Change some comments to lock annotations and added some other comments
to a few functions.
Changed the name of conn_lookup_any() to conn_lookup_def() to
reflect the usage, which is now enforced.

v5: Fix recent version compiler warning (Ilya) about local variable going
out of scope.  I don't think stack memory is reclaimed when block
scope ends, but theoretically some compiler could do it.

Moved "structure copy -> memcpy" changes into a new patch 3.

Add function comment to conn_clean_safe().

v4: Fix exhaustion case cleanup race in conn_not_found() as well.
At the same time, simplify the related code.

v3: Use cleanup_mutex in conntrack_destroy().

v2: Fix typo.



 lib/conntrack.c | 142 ++--
 1 file changed, 98 insertions(+), 44 deletions(-)

diff --git a/lib/conntrack.c b/lib/conntrack.c
index 691782c..dd6e19b 100644
--- a/lib/conntrack.c
+++ b/lib/conntrack.c
@@ -355,7 +355,7 @@ conntrack_destroy(struct conntrack *ct)
 struct conntrack_bucket *ctb = >buckets[i];
 struct conn *conn;
 
-ovs_mutex_destroy(>cleanup_mutex);
+ovs_mutex_lock(>cleanup_mutex);
 ct_lock_lock(>lock);
 HMAP_FOR_EACH_POP (conn, node, >connections) {
 if (conn->conn_type == CT_CONN_TYPE_DEFAULT) {
@@ -365,7 +365,9 @@ conntrack_destroy(struct conntrack *ct)
 }
 hmap_destroy(>connections);
 ct_lock_unlock(>lock);
+ovs_mutex_unlock(>cleanup_mutex);
 ct_lock_destroy(>lock);
+ovs_mutex_destroy(>cleanup_mutex);
 }
 ct_rwlock_wrlock(>resources_lock);
 struct nat_conn_key_node *nat_conn_key_node;
@@ -753,6 +755,27 @@ conn_lookup(struct conntrack *ct, const struct conn_key 
*key, long long now)
 return ctx.conn;
 }
 
+/* Only used when looking up 'CT_CONN_TYPE_DEFAULT' conns. */
+static struct conn *
+conn_lookup_def(const struct conn_key *key,
+const struct conntrack_bucket *ctb, uint32_t hash)
+OVS_REQUIRES(ctb->lock)
+{
+struct conn *conn = NULL;
+
+HMAP_FOR_EACH_WITH_HASH (conn, node, hash, >connections) {
+if (!conn_key_cmp(>key, key)
+&& conn->conn_type == CT_CONN_TYPE_DEFAULT) {
+break;
+}
+if (!conn_key_cmp(>rev_key, key)
+&& conn->conn_type == CT_CONN_TYPE_DEFAULT) {
+break;
+}
+}
+return conn;
+}
+
 static void
 conn_seq_skew_set(struct conntrack *ct, const struct conn_key *key,
   long long now, int seq_skew, bool seq_skew_dir)
@@ -823,6 +846,22 @@ conn_clean(struct conntrack *ct, struct conn *conn,
 }
 }
 
+/* Only called for 'CT_CONN_TYPE_DEFAULT' conns; must be called with no
+ * locks held and upon return no locks are held. */
+static void
+conn_clean_safe(struct conntrack *ct, struct conn *conn,
+struct conntrack_bucket *ctb, uint32_t hash)
+{
+ovs_mutex_lock(>cleanup_mutex);
+ct_lock_lock(>lock);
+conn = conn_lookup_def(>key, ctb, hash);
+if (conn) {
+conn_clean(ct, conn, ctb);
+}
+ct_lock_unlock(>lock);
+ovs_mutex_unlock(>cleanup_mutex);
+}
+
 static bool
 ct_verify_helper(const char *helper, enum ct_alg_ctl_type ct_alg_ctl)
 {
@@ -854,6 +893,7 @@ conn_not_found(struct conntrack *ct, struct dp_packet *pkt,
enum ct_alg_ctl_type ct_alg_ctl)
 {
 struct conn *nc = NULL;
+struct conn connl;
 
 if (!valid_new(pkt, >key)) {
 pkt->md.ct_state = CS_INVALID;
@@ -876,8 +916,9 @@ conn_not_found(struct conntrack *ct, struct dp_packet *pkt,
 }
 
 unsigned bucket = hash_to_bucket(ctx->hash);
-nc = new_conn(>buckets[bucket], pkt, >key, now);
-ctx->conn = nc;
+nc = 
+memset(nc, 0, sizeof *nc);
+memcpy(>key, >key, sizeof nc->key);
 nc->rev_key = nc->key;
 conn_key_reverse(>rev_key);
 
@@ -921,6 +962,7 @@ conn_not_found(struct conntrack *ct, struct dp_packet *pkt,
 ct_rwlock_wrlock(>resources_lock);
 bool nat_res = 

[ovs-dev] [patch v6 2/3] conntrack: Lookup only 'UNNAT conns' in 'nat_clean()'.

2019-03-15 Thread Darrell Ball
When freeing 'UNNAT conns', lookup only 'UNNAT conns' to
protect against possible address overlap with 'default
conns' during a DOS attempt.  This is very unlikely, but
protection is simple.

Fixes: 286de2729955 ("dpdk: Userspace Datapath: Introduce NAT Support.")
Signed-off-by: Darrell Ball 
---

This patch is targeted for earlier releases as new RCU patches
inherently don't have this race.

Backport to 2.8.

v6: Changed comment to lock annotation.
v5: Add fixes tag.
v1->v4: No changes to this patch.

 lib/conntrack.c | 25 +
 1 file changed, 21 insertions(+), 4 deletions(-)

diff --git a/lib/conntrack.c b/lib/conntrack.c
index dd6e19b..5235690 100644
--- a/lib/conntrack.c
+++ b/lib/conntrack.c
@@ -776,6 +776,22 @@ conn_lookup_def(const struct conn_key *key,
 return conn;
 }
 
+static struct conn *
+conn_lookup_unnat(const struct conn_key *key,
+  const struct conntrack_bucket *ctb, uint32_t hash)
+OVS_REQUIRES(ctb->lock)
+{
+struct conn *conn = NULL;
+
+HMAP_FOR_EACH_WITH_HASH (conn, node, hash, >connections) {
+if (!conn_key_cmp(>key, key)
+&& conn->conn_type == CT_CONN_TYPE_UN_NAT) {
+break;
+}
+}
+return conn;
+}
+
 static void
 conn_seq_skew_set(struct conntrack *ct, const struct conn_key *key,
   long long now, int seq_skew, bool seq_skew_dir)
@@ -799,12 +815,13 @@ nat_clean(struct conntrack *ct, struct conn *conn,
 nat_conn_keys_remove(>nat_conn_keys, >rev_key, ct->hash_basis);
 ct_rwlock_unlock(>resources_lock);
 ct_lock_unlock(>lock);
-unsigned bucket_rev_conn =
-hash_to_bucket(conn_key_hash(>rev_key, ct->hash_basis));
+uint32_t hash = conn_key_hash(>rev_key, ct->hash_basis);
+unsigned bucket_rev_conn = hash_to_bucket(hash);
 ct_lock_lock(>buckets[bucket_rev_conn].lock);
 ct_rwlock_wrlock(>resources_lock);
-long long now = time_msec();
-struct conn *rev_conn = conn_lookup(ct, >rev_key, now);
+struct conn *rev_conn = conn_lookup_unnat(>rev_key,
+  >buckets[bucket_rev_conn],
+  hash);
 struct nat_conn_key_node *nat_conn_key_node =
 nat_conn_keys_lookup(>nat_conn_keys, >rev_key,
  ct->hash_basis);
-- 
1.9.1

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


Re: [ovs-dev] [PATCH v2 0/2] ovn-controller: Add a new thread in pinctrl module to process packet-ins

2019-03-15 Thread Ben Pfaff
On Tue, Mar 12, 2019 at 10:00:02PM +0530, nusid...@redhat.com wrote:
> From: Numan Siddique 
> 
> This series attempts to add a new thread in pinctrl module. This thread
> will handle the packet-ins.
> 
> v1 -> v2
> --
>   * Added a new patch p1 to the series suggessted by Mark.
>   * Addressed the review comments from Han and Mark.

Thanks for the series.

Does this depend on some other series?  I get a cascade of errors from
Clang:

../ovn/controller/pinctrl.c:65:18: error: use of undeclared identifier 
'pinctrl_mutex'; did you mean 'pinctrl_run'?
../include/openvswitch/compiler.h:124:45: note: expanded from macro 
'OVS_REQUIRES'
../ovn/controller/pinctrl.h:34:6: note: 'pinctrl_run' declared here
../ovn/controller/pinctrl.c:65:5: error: 'exclusive_locks_required' attribute 
requires arguments whose type is annotated with 'capability' attribute; type 
here is 'void (struct ovsdb_idl_txn *, struct ovsdb_idl_index *, struct 
ovsdb_idl_index *, struct ovsdb_idl_index *, struct ovsdb_idl_index *, struct 
ovsdb_idl_index *, struct ovsdb_idl_index *, const struct sbrec_dns_table *, 
const struct ovsrec_bridge *, const struct sbrec_chassis *, const struct hmap 
*, const struct sset *)' [-Werror,-Wthread-safety-attributes]
../include/openvswitch/compiler.h:124:20: note: expanded from macro 
'OVS_REQUIRES'
../ovn/controller/pinctrl.c:73:18: error: use of undeclared identifier 
'pinctrl_mutex'; did you mean 'pinctrl_run'?
../include/openvswitch/compiler.h:124:45: note: expanded from macro 
'OVS_REQUIRES'
../ovn/controller/pinctrl.h:34:6: note: 'pinctrl_run' declared here
../ovn/controller/pinctrl.c:73:5: error: 'exclusive_locks_required' attribute 
requires arguments whose type is annotated with 'capability' attribute; type 
here is 'void (struct ovsdb_idl_txn *, struct ovsdb_idl_index *, struct 
ovsdb_idl_index *, struct ovsdb_idl_index *, struct ovsdb_idl_index *, struct 
ovsdb_idl_index *, struct ovsdb_idl_index *, const struct sbrec_dns_table *, 
const struct ovsrec_bridge *, const struct sbrec_chassis *, const struct hmap 
*, const struct sset *)' [-Werror,-Wthread-safety-attributes]
../include/openvswitch/compiler.h:124:20: note: expanded from macro 
'OVS_REQUIRES'
../ovn/controller/pinctrl.c:79:18: error: use of undeclared identifier 
'pinctrl_mutex'; did you mean 'pinctrl_run'?
../include/openvswitch/compiler.h:124:45: note: expanded from macro 
'OVS_REQUIRES'
../ovn/controller/pinctrl.h:34:6: note: 'pinctrl_run' declared here
../ovn/controller/pinctrl.c:79:5: error: 'exclusive_locks_required' attribute 
requires arguments whose type is annotated with 'capability' attribute; type 
here is 'void (struct ovsdb_idl_txn *, struct ovsdb_idl_index *, struct 
ovsdb_idl_index *, struct ovsdb_idl_index *, struct ovsdb_idl_index *, struct 
ovsdb_idl_index *, struct ovsdb_idl_index *, const struct sbrec_dns_table *, 
const struct ovsrec_bridge *, const struct sbrec_chassis *, const struct hmap 
*, const struct sset *)' [-Werror,-Wthread-safety-attributes]
../include/openvswitch/compiler.h:124:20: note: expanded from macro 
'OVS_REQUIRES'
../ovn/controller/pinctrl.c:92:18: error: use of undeclared identifier 
'pinctrl_mutex'; did you mean 'pinctrl_run'?
../include/openvswitch/compiler.h:124:45: note: expanded from macro 
'OVS_REQUIRES'
../ovn/controller/pinctrl.h:34:6: note: 'pinctrl_run' declared here
../ovn/controller/pinctrl.c:92:5: error: 'exclusive_locks_required' attribute 
requires arguments whose type is annotated with 'capability' attribute; type 
here is 'void (struct ovsdb_idl_txn *, struct ovsdb_idl_index *, struct 
ovsdb_idl_index *, struct ovsdb_idl_index *, struct ovsdb_idl_index *, struct 
ovsdb_idl_index *, struct ovsdb_idl_index *, const struct sbrec_dns_table *, 
const struct ovsrec_bridge *, const struct sbrec_chassis *, const struct hmap 
*, const struct sset *)' [-Werror,-Wthread-safety-attributes]
../include/openvswitch/compiler.h:124:20: note: expanded from macro 
'OVS_REQUIRES'
../ovn/controller/pinctrl.c:94:18: error: use of undeclared identifier 
'pinctrl_mutex'; did you mean 'pinctrl_run'?
../include/openvswitch/compiler.h:124:45: note: expanded from macro 
'OVS_REQUIRES'
../ovn/controller/pinctrl.h:34:6: note: 'pinctrl_run' declared here
../ovn/controller/pinctrl.c:94:5: error: 'exclusive_locks_required' attribute 
requires arguments whose type is annotated with 'capability' attribute; type 
here is 'void (struct ovsdb_idl_txn *, struct ovsdb_idl_index *, struct 
ovsdb_idl_index *, struct ovsdb_idl_index *, struct ovsdb_idl_index *, struct 
ovsdb_idl_index *, struct ovsdb_idl_index *, const struct sbrec_dns_table *, 
const struct ovsrec_bridge *, const struct sbrec_chassis *, const struct hmap 
*, const struct sset *)' [-Werror,-Wthread-safety-attributes]
../include/openvswitch/compiler.h:124:20: note: expanded from macro 
'OVS_REQUIRES'
../ovn/controller/pinctrl.c:119:18: error: use of undeclared identifier 
'pinctrl_mutex'; did you mean 'pinctrl_run'?

Re: [ovs-dev] [PATCH branch-2.10 0/2] Fix syslog and make travis great again.

2019-03-15 Thread Ben Pfaff
On Thu, Mar 14, 2019 at 09:48:59AM +0100, Simon Horman wrote:
> On Wed, Mar 13, 2019 at 12:06:51PM +0100, Simon Horman wrote:
> > On Tue, Feb 26, 2019 at 04:00:02PM +0300, Ilya Maximets wrote:
> > > First patch is a bugfix backport. Second one fixes the testsuite
> > > jobs on TravisCI failure due to 50 minutes timeout.
> > > 
> > > Both patches needs to be applied to branch-2.10 and backported as far
> > > as possible. I tested them on branches from 2.10 down to 2.6.
> > > 
> > > The second patch disables rsyslog daemon on travis, so the first
> > > fix required to make it work fine in this configuration.
> > > 
> > > Branch 2.11 and master are not affected by the slow syslog issue
> > > because syslog-null is in use for the testsuite invocations.
> > > 
> > > Ilya Maximets (2):
> > >   vlog: Better handle syslog handler exceptions.
> > >   travis: Stop rsyslog before start.
> > 
> > Thanks Ilya,
> > 
> > I have tested these patches and with both applied I now see
> > that travis-ci runs successfully while this was not the case
> > without these patches.
> > 
> > https://travis-ci.org/horms2/ovs/builds/505654239
> > 
> > Tested-by: Simon Horman 
> > 
> > Ben, I'd be happy to go ahead and apply these if there are no objections.
> > Or I'm just as happy for someone else to apply them.
> 
> I have gone ahead and push this series to branch-2.10.

Thanks for handling all of this, Simon.  (And, Ilya, thanks for the
fixes.)
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


Re: [ovs-dev] [PATCH 1/2] dpctl: Stop showing the dpctl/help command.

2019-03-15 Thread Ben Pfaff
On Fri, Mar 15, 2019 at 05:06:01PM +0300, Ilya Maximets wrote:
> 'dpctl/help' command is not registered and could not be called.
> However, 'dpctl/list-commands' prints it as available.
> 
> CC: Ben Pfaff 
> Fixes: 337c45285445 ("dpctl: Fix jump through wild pointer in "dpctl/help".")
> Signed-off-by: Ilya Maximets 

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


Re: [ovs-dev] [PATCH 2/2] dpctl: Change log level for dubug information.

2019-03-15 Thread Ben Pfaff
Doesn't seem particularly useful to me, I suggest that we remove it
entirely instead.

On Fri, Mar 15, 2019 at 06:21:40PM +0300, Ilya Maximets wrote:
> s/dubug/debug/
> 
> On 15.03.2019 17:06, Ilya Maximets wrote:
> > This information is useful only for parser debugging.
> > No need to print it each time to the logs.
> > 
> > CC: Ben Pfaff 
> > Fixes: d1fd1ea91242 ("ovs-dpctl: New --names option to use port names in 
> > flow dumps.")
> > Signed-off-by: Ilya Maximets 
> > ---
> >  lib/dpctl.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/lib/dpctl.c b/lib/dpctl.c
> > index edb753cb4..d60ce1e73 100644
> > --- a/lib/dpctl.c
> > +++ b/lib/dpctl.c
> > @@ -2584,8 +2584,8 @@ dpctl_unixctl_handler(struct unixctl_conn *conn, int 
> > argc, const char *argv[],
> >  if (!set_names) {
> >  dpctl_p.names = dpctl_p.verbosity > 0;
> >  }
> > -VLOG_INFO("set_names=%d verbosity=%d names=%d", set_names,
> > -  dpctl_p.verbosity, dpctl_p.names);
> > +VLOG_DBG("set_names=%d verbosity=%d names=%d", set_names,
> > + dpctl_p.verbosity, dpctl_p.names);
> >  
> >  if (!error) {
> >  dpctl_command_handler *handler = (dpctl_command_handler *) aux;
> > 
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


Re: [ovs-dev] [ovs-discuss] Core dumps generated when running ovs tests in parallel

2019-03-15 Thread Ben Pfaff
On Sat, Mar 16, 2019 at 12:28:31AM +0530, Numan Siddique wrote:
> On my Fedora 29 when ever I run all the ovs tests with "-j5", I see few
> core dumps generated for ovsdb-server and python2.

There are a couple of tests that intentionally do "kill -SEGV", to test
that things work properly in that case.  I suspect you're seeing those.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


[ovs-dev] Core dumps generated when running ovs tests in parallel

2019-03-15 Thread Numan Siddique
Hi,

On my Fedora 29 when ever I run all the ovs tests with "-j5", I see few
core dumps generated for ovsdb-server and python2.

Here's the back trace

[root@nusiddiq ovsdb]# gdb ./ovsdb-server
/opt/core_dumps/core.ovsdb-server.24604
GNU gdb (GDB) Fedora 8.2-6.fc29
...
...
Core was generated by `ovsdb-server --monitor --pidfile --no-db'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x7f813cdfe3e8 in poll () from /lib64/libc.so.6
Missing separate debuginfos, use: dnf debuginfo-install
glibc-2.28-26.fc29.x86_64 libatomic-8.3.1-2.fc29.x86_64
libcap-ng-0.7.9-5.fc29.x86_64 libevent-2.1.8-3.fc29.x86_64
openssl-libs-1.1.1b-2.fc29.x86_64 python3-libs-3.7.2-4.fc29.x86_64
unbound-libs-1.8.3-2.fc29.x86_64 zlib-1.2.11-14.fc29.x86_64
(gdb) bt
#0  0x7f813cdfe3e8 in poll () from /lib64/libc.so.6
#1  0x004453c4 in time_poll (pollfds=pollfds@entry=0xfbb320,
n_pollfds=2, handles=handles@entry=0x0, timeout_when=24471727,
elapsed=elapsed@entry=0x7fff612d09ac) at ../lib/timeval.c:326
#2  0x0043b1c4 in poll_block () at ../include/openvswitch/hmap.h:232
#3  0x00406dd7 in main_loop (is_backup=0x7fff612d0a5e,
exiting=0x7fff612d0a5f, run_process=0x0, remotes=0x7fff612d0ab0,
unixctl=0xfb1420, all_dbs=0x7fff612d0af0, jsonrpc=0xf7eec0,
config=0x7fff612d0b10) at ../ovsdb/ovsdb-server.c:280
#4  main (argc=, argv=) at
../ovsdb/ovsdb-server.c:460


[root@nusiddiq ovsdb]# gdb /usr/bin/python2
/opt/core_dumps/core.python2.26288
GNU gdb (GDB) Fedora 8.2-6.fc29
..
..
Core was generated by `/usr/bin/python2 ../../../../tests/test-daemon.py
--pidfile --monitor'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x7f7074fbeccb in select () from /lib64/libc.so.6
Missing separate debuginfos, use: dnf debuginfo-install
python2-2.7.15-11.fc29.x86_64
(gdb) bt
#0  0x7f7074fbeccb in select () from /lib64/libc.so.6
#1  0x7f7074c50e10 in ?? () from
/usr/lib64/python2.7/lib-dynload/timemodule.so
#2  0x7f70753b114b in PyEval_EvalFrameEx () from
/lib64/libpython2.7.so.1.0
#3  0x7f70753b01ac in PyEval_EvalFrameEx () from
/lib64/libpython2.7.so.1.0
#4  0x7f70753b1902 in PyEval_EvalCodeEx () from
/lib64/libpython2.7.so.1.0
#5  0x7f70753b1b9d in PyEval_EvalCode () from /lib64/libpython2.7.so.1.0
#6  0x7f70753b7b4f in ?? () from /lib64/libpython2.7.so.1.0
#7  0x7f70753b7af8 in PyRun_FileExFlags () from
/lib64/libpython2.7.so.1.0
#8  0x7f70753b790c in PyRun_SimpleFileExFlags () from
/lib64/libpython2.7.so.1.0
#9  0x7f70753bd5ba in Py_Main () from /lib64/libpython2.7.so.1.0
#10 0x7f7074eee413 in __libc_start_main () from /lib64/libc.so.6
#11 0x55c873ddc0ae in _start ()


The glibc version is 2.28 (glibc-2.28-26.fc29.x86_64)

We have seen similar crashes with ovn-controller and ovs-vswitchd in this
BZ - https://bugzilla.redhat.com/show_bug.cgi?id=1685058

And the backtrace goes to libc.

Is anyone aware of this or have any pointers what could be going on here ?

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


[ovs-dev] Cómo redactar documentos ejecutivos

2019-03-15 Thread Ortografía y Redacción
Cursos TOP - Webinar Interactivo – Jueves 04 de Abril

Redacción de documentos ejecutivos 

Este webinar se desarrolla para atender las necesidades comunicativas de los 
profesionales. Funciona como una guía de 
redacción, composición y ortografía necesarias para la adecuada producción de 
textos y llenado de formatos profesionales
 así como para fortalecer las habilidades comunicativas de los ejecutivos para 
un desempeño exitoso en contextos cotidianos,
 organizacionales, académicos y profesionales. 

 Para mayor información, responder sobre este correo con la palabra Redacción + 
los siguientes datos:


NOMBRE:
TELÉFONO:
EMPRESA:
CORREO ALTERNO: 

Llamanos al (045) 55 1554 6630


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


Re: [ovs-dev] [PATCH 2/2] dpctl: Change log level for dubug information.

2019-03-15 Thread Ilya Maximets
s/dubug/debug/

On 15.03.2019 17:06, Ilya Maximets wrote:
> This information is useful only for parser debugging.
> No need to print it each time to the logs.
> 
> CC: Ben Pfaff 
> Fixes: d1fd1ea91242 ("ovs-dpctl: New --names option to use port names in flow 
> dumps.")
> Signed-off-by: Ilya Maximets 
> ---
>  lib/dpctl.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/lib/dpctl.c b/lib/dpctl.c
> index edb753cb4..d60ce1e73 100644
> --- a/lib/dpctl.c
> +++ b/lib/dpctl.c
> @@ -2584,8 +2584,8 @@ dpctl_unixctl_handler(struct unixctl_conn *conn, int 
> argc, const char *argv[],
>  if (!set_names) {
>  dpctl_p.names = dpctl_p.verbosity > 0;
>  }
> -VLOG_INFO("set_names=%d verbosity=%d names=%d", set_names,
> -  dpctl_p.verbosity, dpctl_p.names);
> +VLOG_DBG("set_names=%d verbosity=%d names=%d", set_names,
> + dpctl_p.verbosity, dpctl_p.names);
>  
>  if (!error) {
>  dpctl_command_handler *handler = (dpctl_command_handler *) aux;
> 
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


[ovs-dev] contrer l'arrêt [-SAUV LIFE-]

2019-03-15 Thread Dr Lionel Lamhaut



contrer l'arret









#outlook a { padding:0; }
.ReadMsgBody { width:100%; }
.ExternalClass { width:100%; }
.ExternalClass * { line-height:100%; }
body { 
margin:0;padding:0;-webkit-text-size-adjust:100%;-ms-text-size-adjust:100%; }
table, td { 
border-collapse:collapse;mso-table-lspace:0pt;mso-table-rspace:0pt; }
img { border:0;height:auto;line-height:100%; 
outline:none;text-decoration:none;-ms-interpolation-mode:bicubic; }
p { display:block;margin:13px 0; }



@media only screen and (max-width:480px) {
@-ms-viewport { width:320px; }
@viewport { width:320px; }
}



.outlook-group-fix { width:100% !important; }




@import url(https://fonts.googleapis.com/css?family=Roboto:300,400,500);



@media only screen and (min-width:480px) {
.mj-column-per-100 { width:100% !important; max-width: 100%; }
.mj-column-px-60 { width:60px !important; max-width: 60px; }
.mj-column-px-100 { width:100px !important; max-width: 100px; }
}


@media only screen and (max-width:480px) {
table.full-width-mobile { width: 100% !important; }
td.full-width-mobile { width: auto !important; }
}


.content-wrapper img {
max-width: 100%;
}
.Style1 {font-size: 9px}



































Vous aussi téléchargez sur votre téléphone

l'application GRATUITE : .S.A.U.V. Life

destinée à sauver des vies

Il s'agit d'une application composée d'une communauté de citoyens 
volontaires à la disposition des SAMU et des Pompiers.

En France 40 000 à 60 000 personnes meurent chaque année d'un arrêt 
cardiaque.

Les secours organisés mettent en moyenne 13 minutes pour arriver, 
sachant que chaque minute sans massage cardiaque/défibrillation c'est 10 % de 
survie en moins, notre objectif est de réduire ce délai en faisant intervenir 
des "citoyens sauveteurs".

Formé au nom, tout le monde peut agir et devenir un "citoyen sauveteur" 
tout simplement en téléchargeant notre application GRATUITE.

















   

[ovs-dev] [PATCH 2/2] dpctl: Change log level for dubug information.

2019-03-15 Thread Ilya Maximets
This information is useful only for parser debugging.
No need to print it each time to the logs.

CC: Ben Pfaff 
Fixes: d1fd1ea91242 ("ovs-dpctl: New --names option to use port names in flow 
dumps.")
Signed-off-by: Ilya Maximets 
---
 lib/dpctl.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/dpctl.c b/lib/dpctl.c
index edb753cb4..d60ce1e73 100644
--- a/lib/dpctl.c
+++ b/lib/dpctl.c
@@ -2584,8 +2584,8 @@ dpctl_unixctl_handler(struct unixctl_conn *conn, int 
argc, const char *argv[],
 if (!set_names) {
 dpctl_p.names = dpctl_p.verbosity > 0;
 }
-VLOG_INFO("set_names=%d verbosity=%d names=%d", set_names,
-  dpctl_p.verbosity, dpctl_p.names);
+VLOG_DBG("set_names=%d verbosity=%d names=%d", set_names,
+ dpctl_p.verbosity, dpctl_p.names);
 
 if (!error) {
 dpctl_command_handler *handler = (dpctl_command_handler *) aux;
-- 
2.17.1

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


[ovs-dev] [PATCH 1/2] dpctl: Stop showing the dpctl/help command.

2019-03-15 Thread Ilya Maximets
'dpctl/help' command is not registered and could not be called.
However, 'dpctl/list-commands' prints it as available.

CC: Ben Pfaff 
Fixes: 337c45285445 ("dpctl: Fix jump through wild pointer in "dpctl/help".")
Signed-off-by: Ilya Maximets 
---
 lib/dpctl.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/lib/dpctl.c b/lib/dpctl.c
index baf37b8bc..edb753cb4 100644
--- a/lib/dpctl.c
+++ b/lib/dpctl.c
@@ -1348,6 +1348,10 @@ dpctl_list_commands(int argc OVS_UNUSED, const char 
*argv[] OVS_UNUSED,
 for (; commands->name; commands++) {
 const struct dpctl_command *c = commands;
 
+if (dpctl_p->is_appctl && !strcmp(c->name, "help")) {
+continue;
+}
+
 ds_put_format(, "  %s%-23s %s\n", dpctl_p->is_appctl ? "dpctl/" : 
"",
   c->name, c->usage);
 }
-- 
2.17.1

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


[ovs-dev] [PATCH 0/2] dpctl: Misc fixes.

2019-03-15 Thread Ilya Maximets
Ilya Maximets (2):
  dpctl: Stop showing the dpctl/help command.
  dpctl: Change log level for dubug information.

 lib/dpctl.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

-- 
2.17.1

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


Re: [ovs-dev] [PATCH branch-2.10 0/2] Fix syslog and make travis great again.

2019-03-15 Thread Simon Horman
On Fri, Mar 15, 2019 at 12:28:03PM +0300, Ilya Maximets wrote:
> On 15.03.2019 11:50, Simon Horman wrote:
> > On Thu, Mar 14, 2019 at 01:14:05PM +0300, Ilya Maximets wrote:
> >> On 14.03.2019 11:48, Simon Horman wrote:
> >>> On Wed, Mar 13, 2019 at 12:06:51PM +0100, Simon Horman wrote:
>  On Tue, Feb 26, 2019 at 04:00:02PM +0300, Ilya Maximets wrote:
> > First patch is a bugfix backport. Second one fixes the testsuite
> > jobs on TravisCI failure due to 50 minutes timeout.
> >
> > Both patches needs to be applied to branch-2.10 and backported as far
> > as possible. I tested them on branches from 2.10 down to 2.6.
> >
> > The second patch disables rsyslog daemon on travis, so the first
> > fix required to make it work fine in this configuration.
> >
> > Branch 2.11 and master are not affected by the slow syslog issue
> > because syslog-null is in use for the testsuite invocations.
> >
> > Ilya Maximets (2):
> >   vlog: Better handle syslog handler exceptions.
> >   travis: Stop rsyslog before start.
> 
>  Thanks Ilya,
> 
>  I have tested these patches and with both applied I now see
>  that travis-ci runs successfully while this was not the case
>  without these patches.
> 
>  https://travis-ci.org/horms2/ovs/builds/505654239
> 
>  Tested-by: Simon Horman 
> 
>  Ben, I'd be happy to go ahead and apply these if there are no objections.
>  Or I'm just as happy for someone else to apply them.
> >>>
> >>> I have gone ahead and push this series to branch-2.10.
> >>
> >> Thanks! branch-2.10 is green now.
> >>
> >> BTW, It'll be good to have these patches down to branch-2.6.
> >>
> >> Best regards, Ilya Maximets.
> > 
> > Thanks,
> > 
> > I've gone ahead and pushed these to branch-2.9, branch-2.8, branch-2.7
> > and branch-2.6.
> > 
> > In the case of branch-2.9 and branch-2.8 my testing indicates that
> > travis-ci should now turn green (hooray!).
> > 
> > https://travis-ci.org/horms2/ovs/builds/506251905
> > https://travis-ci.org/horms2/ovs/builds/506252393
> > 
> > In the case of branch-2.7 and branch-2.6, I had to resolve a minor
> > conflict when applying the patches. You may want to check to make sure
> > that I got that right.
> 
> Thanks fro working on this!
> Rebase is minor, looks good.

Likewise, thanks for your help.
We seem to be making good progress.

> > For these branches it seems to make travis-ci happier and there are
> > no more aborted ("!") builds. However, there does still seem to be an
> > unrelated failure so those branches do not turn green.
> > 
> > https://travis-ci.org/horms2/ovs/builds/506253422
> > https://travis-ci.org/horms2/ovs/jobs/506253451
> > 
> > https://travis-ci.org/horms2/ovs/builds/506254580
> > https://travis-ci.org/horms2/ovs/jobs/506254614
> 
> 
> For OSX build we probably need to backport following patch to 2.6 and 2.7:
> 
> commit 10fd9f6e477555ca93d28094c2976b2ea0198798
> Author: Richard Oliver 
> Date:   Sat Oct 28 16:38:30 2017 +0100
> 
> timeval: Check for OS-provided clock_gettime on macOS
> 
> [Problem]
> Compilation error on newer versions of macOS (Sierra onwards) due to
> multiple declarations of clock_gettime.
> 
> [Solution]
> Have configure check for clock_gettime and check this result in
> timeval to avoid incorrectly declaring/defining clock_gettime again.
> 
> [Testing]
> Source code now successfully builds on macOS.
> 
> Signed-off-by: Richard Oliver 
> Signed-off-by: Ben Pfaff 

Thanks,

I've as per your suggestion I have tried applying these (locally) to
branch-2.7 and branch-2.6. Which involved resolving a minor conflict.
Travis-CI is now chewing over this.

https://travis-ci.org/horms2/ovs/builds/506681468
https://travis-ci.org/horms2/ovs/builds/506681370
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


Re: [ovs-dev] [PATCH branch-2.10 0/2] Fix syslog and make travis great again.

2019-03-15 Thread Ilya Maximets
On 15.03.2019 11:50, Simon Horman wrote:
> On Thu, Mar 14, 2019 at 01:14:05PM +0300, Ilya Maximets wrote:
>> On 14.03.2019 11:48, Simon Horman wrote:
>>> On Wed, Mar 13, 2019 at 12:06:51PM +0100, Simon Horman wrote:
 On Tue, Feb 26, 2019 at 04:00:02PM +0300, Ilya Maximets wrote:
> First patch is a bugfix backport. Second one fixes the testsuite
> jobs on TravisCI failure due to 50 minutes timeout.
>
> Both patches needs to be applied to branch-2.10 and backported as far
> as possible. I tested them on branches from 2.10 down to 2.6.
>
> The second patch disables rsyslog daemon on travis, so the first
> fix required to make it work fine in this configuration.
>
> Branch 2.11 and master are not affected by the slow syslog issue
> because syslog-null is in use for the testsuite invocations.
>
> Ilya Maximets (2):
>   vlog: Better handle syslog handler exceptions.
>   travis: Stop rsyslog before start.

 Thanks Ilya,

 I have tested these patches and with both applied I now see
 that travis-ci runs successfully while this was not the case
 without these patches.

 https://travis-ci.org/horms2/ovs/builds/505654239

 Tested-by: Simon Horman 

 Ben, I'd be happy to go ahead and apply these if there are no objections.
 Or I'm just as happy for someone else to apply them.
>>>
>>> I have gone ahead and push this series to branch-2.10.
>>
>> Thanks! branch-2.10 is green now.
>>
>> BTW, It'll be good to have these patches down to branch-2.6.
>>
>> Best regards, Ilya Maximets.
> 
> Thanks,
> 
> I've gone ahead and pushed these to branch-2.9, branch-2.8, branch-2.7
> and branch-2.6.
> 
> In the case of branch-2.9 and branch-2.8 my testing indicates that
> travis-ci should now turn green (hooray!).
> 
> https://travis-ci.org/horms2/ovs/builds/506251905
> https://travis-ci.org/horms2/ovs/builds/506252393
> 
> In the case of branch-2.7 and branch-2.6, I had to resolve a minor
> conflict when applying the patches. You may want to check to make sure
> that I got that right.

Thanks fro working on this!
Rebase is minor, looks good.

> 
> For these branches it seems to make travis-ci happier and there are
> no more aborted ("!") builds. However, there does still seem to be an
> unrelated failure so those branches do not turn green.
> 
> https://travis-ci.org/horms2/ovs/builds/506253422
> https://travis-ci.org/horms2/ovs/jobs/506253451
> 
> https://travis-ci.org/horms2/ovs/builds/506254580
> https://travis-ci.org/horms2/ovs/jobs/506254614


For OSX build we probably need to backport following patch to 2.6 and 2.7:

commit 10fd9f6e477555ca93d28094c2976b2ea0198798
Author: Richard Oliver 
Date:   Sat Oct 28 16:38:30 2017 +0100

timeval: Check for OS-provided clock_gettime on macOS

[Problem]
Compilation error on newer versions of macOS (Sierra onwards) due to
multiple declarations of clock_gettime.

[Solution]
Have configure check for clock_gettime and check this result in
timeval to avoid incorrectly declaring/defining clock_gettime again.

[Testing]
Source code now successfully builds on macOS.

Signed-off-by: Richard Oliver 
Signed-off-by: Ben Pfaff 


Best regards, Ilya Maximets.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


Re: [ovs-dev] [PATCH branch-2.10 0/2] Fix syslog and make travis great again.

2019-03-15 Thread Simon Horman
On Thu, Mar 14, 2019 at 01:14:05PM +0300, Ilya Maximets wrote:
> On 14.03.2019 11:48, Simon Horman wrote:
> > On Wed, Mar 13, 2019 at 12:06:51PM +0100, Simon Horman wrote:
> >> On Tue, Feb 26, 2019 at 04:00:02PM +0300, Ilya Maximets wrote:
> >>> First patch is a bugfix backport. Second one fixes the testsuite
> >>> jobs on TravisCI failure due to 50 minutes timeout.
> >>>
> >>> Both patches needs to be applied to branch-2.10 and backported as far
> >>> as possible. I tested them on branches from 2.10 down to 2.6.
> >>>
> >>> The second patch disables rsyslog daemon on travis, so the first
> >>> fix required to make it work fine in this configuration.
> >>>
> >>> Branch 2.11 and master are not affected by the slow syslog issue
> >>> because syslog-null is in use for the testsuite invocations.
> >>>
> >>> Ilya Maximets (2):
> >>>   vlog: Better handle syslog handler exceptions.
> >>>   travis: Stop rsyslog before start.
> >>
> >> Thanks Ilya,
> >>
> >> I have tested these patches and with both applied I now see
> >> that travis-ci runs successfully while this was not the case
> >> without these patches.
> >>
> >> https://travis-ci.org/horms2/ovs/builds/505654239
> >>
> >> Tested-by: Simon Horman 
> >>
> >> Ben, I'd be happy to go ahead and apply these if there are no objections.
> >> Or I'm just as happy for someone else to apply them.
> > 
> > I have gone ahead and push this series to branch-2.10.
> 
> Thanks! branch-2.10 is green now.
> 
> BTW, It'll be good to have these patches down to branch-2.6.
> 
> Best regards, Ilya Maximets.

Thanks,

I've gone ahead and pushed these to branch-2.9, branch-2.8, branch-2.7
and branch-2.6.

In the case of branch-2.9 and branch-2.8 my testing indicates that
travis-ci should now turn green (hooray!).

https://travis-ci.org/horms2/ovs/builds/506251905
https://travis-ci.org/horms2/ovs/builds/506252393

In the case of branch-2.7 and branch-2.6, I had to resolve a minor
conflict when applying the patches. You may want to check to make sure
that I got that right.

For these branches it seems to make travis-ci happier and there are
no more aborted ("!") builds. However, there does still seem to be an
unrelated failure so those branches do not turn green.

https://travis-ci.org/horms2/ovs/builds/506253422
https://travis-ci.org/horms2/ovs/jobs/506253451

https://travis-ci.org/horms2/ovs/builds/506254580
https://travis-ci.org/horms2/ovs/jobs/506254614

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


[ovs-dev] [PATCH] net: openvswitch: fix missing checks for nla_nest_start

2019-03-15 Thread Kangjie Lu
nla_nest_start may fail and thus deserves a check.
The fix returns -EMSGSIZE when it fails.

Signed-off-by: Kangjie Lu 
---
 net/openvswitch/datapath.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/net/openvswitch/datapath.c b/net/openvswitch/datapath.c
index 45d1469308b0..9dd158ab51b3 100644
--- a/net/openvswitch/datapath.c
+++ b/net/openvswitch/datapath.c
@@ -464,6 +464,10 @@ static int queue_userspace_packet(struct datapath *dp, 
struct sk_buff *skb,
 
if (upcall_info->egress_tun_info) {
nla = nla_nest_start(user_skb, OVS_PACKET_ATTR_EGRESS_TUN_KEY);
+   if (!nla) {
+   err = -EMSGSIZE;
+   goto out;
+   }
err = ovs_nla_put_tunnel_info(user_skb,
  upcall_info->egress_tun_info);
BUG_ON(err);
@@ -472,6 +476,10 @@ static int queue_userspace_packet(struct datapath *dp, 
struct sk_buff *skb,
 
if (upcall_info->actions_len) {
nla = nla_nest_start(user_skb, OVS_PACKET_ATTR_ACTIONS);
+   if (!nla) {
+   err = -EMSGSIZE;
+   goto out;
+   }
err = ovs_nla_put_actions(upcall_info->actions,
  upcall_info->actions_len,
  user_skb);
-- 
2.17.1

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