date:20170706

Re: [ovs-dev] [PATCH v3 1/3] dpif-netdev: Incremental addition/deletion of PMD threads.

2017-07-06 Thread Ilya Maximets

On 07.07.2017 07:33, Darrell Ball wrote:
> 
> 
> On 6/15/17, 4:36 AM, "Ilya Maximets"  wrote:
> 
> Currently, change of 'pmd-cpu-mask' is very heavy operation.
> It requires destroying of all the PMD threads and creating
> them back. After that, all the threads will sleep until
> ports' redistribution finished.
> 
> This patch adds ability to not stop the datapath while
> adjusting number/placement of PMD threads. All not affected
> threads will forward traffic without any additional latencies.
> 
> id-pool created for static tx queue ids to keep them sequential
> in a flexible way. non-PMD thread will always have
> static_tx_qid = 0 as it was before.
> 
> Signed-off-by: Ilya Maximets 
> Tested-by: Mark Kavanagh 
> Acked-by: Mark Kavanagh 
> ---
>  lib/dpif-netdev.c | 146 
> +++---
>  tests/pmd.at  |   2 +-
>  2 files changed, 108 insertions(+), 40 deletions(-)
> 
> diff --git a/lib/dpif-netdev.c b/lib/dpif-netdev.c
> index 2f224db..c0bcca0 100644
> --- a/lib/dpif-netdev.c
> +++ b/lib/dpif-netdev.c
> @@ -48,6 +48,7 @@
>  #include "fat-rwlock.h"
>  #include "flow.h"
>  #include "hmapx.h"
> +#include "id-pool.h"
>  #include "latch.h"
>  #include "netdev.h"
>  #include "netdev-vport.h"
> @@ -278,6 +279,9 @@ struct dp_netdev {
>  
>  /* Stores all 'struct dp_netdev_pmd_thread's. */
>  struct cmap poll_threads;
> +/* id pool for per thread static_tx_qid. */
> +struct id_pool *tx_qid_pool;
> +struct ovs_mutex tx_qid_pool_mutex;
>  
>  /* Protects the access of the 'struct dp_netdev_pmd_thread'
>   * instance for non-pmd thread. */
> @@ -563,7 +567,7 @@ struct dp_netdev_pmd_thread {
>  /* Queue id used by this pmd thread to send packets on all netdevs if
>   * XPS disabled for this netdev. All static_tx_qid's are unique and 
> less
>   * than 'cmap_count(dp->poll_threads)'. */
> -const int static_tx_qid;
> +uint32_t static_tx_qid;
>  
>  struct ovs_mutex port_mutex;/* Mutex for 'poll_list' and 
> 'tx_ports'. */
>  /* List of rx queues to poll. */
> @@ -643,6 +647,8 @@ static struct dp_netdev_pmd_thread 
> *dp_netdev_get_pmd(struct dp_netdev *dp,
>unsigned core_id);
>  static struct dp_netdev_pmd_thread *
>  dp_netdev_pmd_get_next(struct dp_netdev *dp, struct cmap_position *pos);
> +static void dp_netdev_del_pmd(struct dp_netdev *dp,
> +  struct dp_netdev_pmd_thread *pmd);
>  static void dp_netdev_destroy_all_pmds(struct dp_netdev *dp, bool 
> non_pmd);
>  static void dp_netdev_pmd_clear_ports(struct dp_netdev_pmd_thread *pmd);
>  static void dp_netdev_add_port_tx_to_pmd(struct dp_netdev_pmd_thread 
> *pmd,
> @@ -1182,10 +1188,17 @@ create_dp_netdev(const char *name, const struct 
> dpif_class *class,
>  atomic_init(>emc_insert_min, DEFAULT_EM_FLOW_INSERT_MIN);
>  
>  cmap_init(>poll_threads);
> +
> +ovs_mutex_init(>tx_qid_pool_mutex);
> +/* We need 1 Tx queue for each possible core + 1 for non-PMD 
> threads. */
> +dp->tx_qid_pool = id_pool_create(0, ovs_numa_get_n_cores() + 1);
> +
>  ovs_mutex_init_recursive(>non_pmd_mutex);
>  ovsthread_key_create(>per_pmd_key, NULL);
>  
>  ovs_mutex_lock(>port_mutex);
> +/* non-PMD will be created before all other threads and will
> + * allocate static_tx_qid = 0. */
>  dp_netdev_set_nonpmd(dp);
>  
>  error = do_add_port(dp, name, dpif_netdev_port_open_type(dp->class,
> @@ -1280,6 +1293,9 @@ dp_netdev_free(struct dp_netdev *dp)
>  dp_netdev_destroy_all_pmds(dp, true);
>  cmap_destroy(>poll_threads);
>  
> +ovs_mutex_destroy(>tx_qid_pool_mutex);
> +id_pool_destroy(dp->tx_qid_pool);
> +
>  ovs_mutex_destroy(>non_pmd_mutex);
>  ovsthread_key_delete(dp->per_pmd_key);
>  
> @@ -3296,12 +3312,29 @@ rxq_scheduling(struct dp_netdev *dp, bool pinned) 
> OVS_REQUIRES(dp->port_mutex)
>  }
>  
>  static void
> +reload_affected_pmds(struct dp_netdev *dp)
> +{
> +struct dp_netdev_pmd_thread *pmd;
> +
> +CMAP_FOR_EACH (pmd, node, >poll_threads) {
> +if (pmd->need_reload) {
> +dp_netdev_reload_pmd__(pmd);
> +pmd->need_reload = false;
> +}
> +}
> +}
> +
> +static void
>  reconfigure_pmd_threads(struct dp_netdev *dp)
>  OVS_REQUIRES(dp->port_mutex)
>  {
>  struct dp_netdev_pmd_thread *pmd;
>  struct ovs_numa_dump *pmd_cores;
>

Re: [ovs-dev] [PATCH v3 3/3] dpif-netdev: Don't uninit emc on reload.

2017-07-06 Thread Darrell Ball

This should provide benefit in the common case.

On 6/15/17, 4:36 AM, "Ilya Maximets"  wrote:

There are many reasons for reloading of pmd threads:
* reconfiguration of one of the ports.
* Adjusting of static_tx_qid.
* Adding new tx/rx ports.

In many cases EMC is still useful after reload and uninit
will only lead to unnecessary upcalls/classifier lookups.

Such behaviour slows down the datapath. Uninit itself slows
down the reload path. All this factors leads to additional
unexpected latencies/drops on events not directly connected
to current PMD thread.

Lets not uninitialize emc cache on reload path.
'emc_cache_slow_sweep()' and replacements should free all
the old/unwanted entries.

Signed-off-by: Ilya Maximets 
Acked-by: Cian Ferriter 
Tested-by: Cian Ferriter 
---
 lib/dpif-netdev.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/dpif-netdev.c b/lib/dpif-netdev.c
index d2443da..e7ab306 100644
--- a/lib/dpif-netdev.c
+++ b/lib/dpif-netdev.c
@@ -3794,9 +3794,9 @@ pmd_thread_main(void *f_)
 ovs_numa_thread_setaffinity_core(pmd->core_id);
 dpdk_set_lcore_id(pmd->core_id);
 poll_cnt = pmd_load_queues_and_ports(pmd, _list);
+emc_cache_init(>flow_cache);
 reload:
 pmd_alloc_static_tx_qid(pmd);
-emc_cache_init(>flow_cache);
 
 /* List port/core affinity */
 for (i = 0; i < poll_cnt; i++) {
@@ -3843,13 +3843,13 @@ reload:
  * reloading the updated configuration. */
 dp_netdev_pmd_reload_done(pmd);
 
-emc_cache_uninit(>flow_cache);
 pmd_free_static_tx_qid(pmd);
 
 if (!exiting) {
 goto reload;
 }
 
+emc_cache_uninit(>flow_cache);
 free(poll_list);
 pmd_free_cached_ports(pmd);
 return NULL;
-- 
2.7.4



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

Re: [ovs-dev] [PATCH v2 2/3] dpif-netdev: Avoid port's reconfiguration on pmd-cpu-mask changes.

2017-07-06 Thread Darrell Ball



On 5/30/17, 7:12 AM, "Ilya Maximets"  wrote:

Reconfiguration of HW NICs may lead to packet drops.
In current model all physical ports will be reconfigured each
time number of PMD threads changed. Since we not stopping
threads on pmd-cpu-mask changes, this patch will help to further
decrease port's downtime by setting the maximum possible number
of wanted tx queues to avoid unnecessary reconfigurations.

Signed-off-by: Ilya Maximets 
---
 lib/dpif-netdev.c | 26 +-
 1 file changed, 21 insertions(+), 5 deletions(-)

diff --git a/lib/dpif-netdev.c b/lib/dpif-netdev.c
index 596d133..79db770 100644
--- a/lib/dpif-netdev.c
+++ b/lib/dpif-netdev.c
@@ -3453,7 +3453,7 @@ reconfigure_datapath(struct dp_netdev *dp)
 {
 struct dp_netdev_pmd_thread *pmd;
 struct dp_netdev_port *port;
-int wanted_txqs;
+int needed_txqs, wanted_txqs;
 
 dp->last_reconfigure_seq = seq_read(dp->reconfigure_seq);
 
@@ -3461,7 +3461,15 @@ reconfigure_datapath(struct dp_netdev *dp)
  * on the system and the user configuration. */
 reconfigure_pmd_threads(dp);
 
-wanted_txqs = cmap_count(>poll_threads);
+/* We need 1 Tx queue for each thread to avoid locking, but we will try
+ * to allocate the maximum possible value to minimize the number of 
port
+ * reconfigurations. */
+needed_txqs = cmap_count(>poll_threads);
+/* (n_cores + 1) is the maximum that we might need to have.
+ * Additional queue is for non-PMD threads. */
+wanted_txqs = ovs_numa_get_n_cores();
+ovs_assert(wanted_txqs != OVS_CORE_UNSPEC);
+wanted_txqs++;

I don’t think PMD mask changes are common, so this patch is trying to optimize 
a 
rare disruptive event that can/will be scheduled by the administrator.

Based on the actual number of queues supported and the number of cores present,
this optimization may or may not work. It is unpredictable whether there will 
be benefit
in a particular case from the user POV.
If I were the administrator, I would try to error on the conservative side 
anyways if I could
not predict the result.

Did I miss something ?

 /* The number of pmd threads might have changed, or a port can be new:
  * adjust the txqs. */
@@ -3474,9 +3482,17 @@ reconfigure_datapath(struct dp_netdev *dp)
 
 /* Check for all the ports that need reconfiguration.  We cache this in
  * 'port->reconfigure', because netdev_is_reconf_required() can change 
at
- * any time. */
+ * any time.
+ * Also mark for reconfiguration all ports which will likely change 
their
+ * 'dynamic_txqs' parameter. It's required to stop using them before
+ * changing this setting and it's simpler to mark ports here and allow
+ * 'pmd_remove_stale_ports' to remove them from threads. There will be
+ * no actual reconfiguration in 'port_reconfigure' because it's
+ * unnecessary.  */
 HMAP_FOR_EACH (port, node, >ports) {
-if (netdev_is_reconf_required(port->netdev)) {
+if (netdev_is_reconf_required(port->netdev)
+|| (port->dynamic_txqs
+!=  netdev_n_txq(port->netdev) < needed_txqs)) {
 port->need_reconfigure = true;
 }
 }
@@ -3510,7 +3526,7 @@ reconfigure_datapath(struct dp_netdev *dp)
 seq_change(dp->port_seq);
 port_destroy(port);
 } else {
-port->dynamic_txqs = netdev_n_txq(port->netdev) < wanted_txqs;
+port->dynamic_txqs = netdev_n_txq(port->netdev) < needed_txqs;
 }
 }
 
-- 
2.7.4



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

Re: [ovs-dev] [PATCH v3 1/3] dpif-netdev: Incremental addition/deletion of PMD threads.

2017-07-06 Thread Darrell Ball



On 6/15/17, 4:36 AM, "Ilya Maximets"  wrote:

Currently, change of 'pmd-cpu-mask' is very heavy operation.
It requires destroying of all the PMD threads and creating
them back. After that, all the threads will sleep until
ports' redistribution finished.

This patch adds ability to not stop the datapath while
adjusting number/placement of PMD threads. All not affected
threads will forward traffic without any additional latencies.

id-pool created for static tx queue ids to keep them sequential
in a flexible way. non-PMD thread will always have
static_tx_qid = 0 as it was before.

Signed-off-by: Ilya Maximets 
Tested-by: Mark Kavanagh 
Acked-by: Mark Kavanagh 
---
 lib/dpif-netdev.c | 146 
+++---
 tests/pmd.at  |   2 +-
 2 files changed, 108 insertions(+), 40 deletions(-)

diff --git a/lib/dpif-netdev.c b/lib/dpif-netdev.c
index 2f224db..c0bcca0 100644
--- a/lib/dpif-netdev.c
+++ b/lib/dpif-netdev.c
@@ -48,6 +48,7 @@
 #include "fat-rwlock.h"
 #include "flow.h"
 #include "hmapx.h"
+#include "id-pool.h"
 #include "latch.h"
 #include "netdev.h"
 #include "netdev-vport.h"
@@ -278,6 +279,9 @@ struct dp_netdev {
 
 /* Stores all 'struct dp_netdev_pmd_thread's. */
 struct cmap poll_threads;
+/* id pool for per thread static_tx_qid. */
+struct id_pool *tx_qid_pool;
+struct ovs_mutex tx_qid_pool_mutex;
 
 /* Protects the access of the 'struct dp_netdev_pmd_thread'
  * instance for non-pmd thread. */
@@ -563,7 +567,7 @@ struct dp_netdev_pmd_thread {
 /* Queue id used by this pmd thread to send packets on all netdevs if
  * XPS disabled for this netdev. All static_tx_qid's are unique and 
less
  * than 'cmap_count(dp->poll_threads)'. */
-const int static_tx_qid;
+uint32_t static_tx_qid;
 
 struct ovs_mutex port_mutex;/* Mutex for 'poll_list' and 
'tx_ports'. */
 /* List of rx queues to poll. */
@@ -643,6 +647,8 @@ static struct dp_netdev_pmd_thread 
*dp_netdev_get_pmd(struct dp_netdev *dp,
   unsigned core_id);
 static struct dp_netdev_pmd_thread *
 dp_netdev_pmd_get_next(struct dp_netdev *dp, struct cmap_position *pos);
+static void dp_netdev_del_pmd(struct dp_netdev *dp,
+  struct dp_netdev_pmd_thread *pmd);
 static void dp_netdev_destroy_all_pmds(struct dp_netdev *dp, bool non_pmd);
 static void dp_netdev_pmd_clear_ports(struct dp_netdev_pmd_thread *pmd);
 static void dp_netdev_add_port_tx_to_pmd(struct dp_netdev_pmd_thread *pmd,
@@ -1182,10 +1188,17 @@ create_dp_netdev(const char *name, const struct 
dpif_class *class,
 atomic_init(>emc_insert_min, DEFAULT_EM_FLOW_INSERT_MIN);
 
 cmap_init(>poll_threads);
+
+ovs_mutex_init(>tx_qid_pool_mutex);
+/* We need 1 Tx queue for each possible core + 1 for non-PMD threads. 
*/
+dp->tx_qid_pool = id_pool_create(0, ovs_numa_get_n_cores() + 1);
+
 ovs_mutex_init_recursive(>non_pmd_mutex);
 ovsthread_key_create(>per_pmd_key, NULL);
 
 ovs_mutex_lock(>port_mutex);
+/* non-PMD will be created before all other threads and will
+ * allocate static_tx_qid = 0. */
 dp_netdev_set_nonpmd(dp);
 
 error = do_add_port(dp, name, dpif_netdev_port_open_type(dp->class,
@@ -1280,6 +1293,9 @@ dp_netdev_free(struct dp_netdev *dp)
 dp_netdev_destroy_all_pmds(dp, true);
 cmap_destroy(>poll_threads);
 
+ovs_mutex_destroy(>tx_qid_pool_mutex);
+id_pool_destroy(dp->tx_qid_pool);
+
 ovs_mutex_destroy(>non_pmd_mutex);
 ovsthread_key_delete(dp->per_pmd_key);
 
@@ -3296,12 +3312,29 @@ rxq_scheduling(struct dp_netdev *dp, bool pinned) 
OVS_REQUIRES(dp->port_mutex)
 }
 
 static void
+reload_affected_pmds(struct dp_netdev *dp)
+{
+struct dp_netdev_pmd_thread *pmd;
+
+CMAP_FOR_EACH (pmd, node, >poll_threads) {
+if (pmd->need_reload) {
+dp_netdev_reload_pmd__(pmd);
+pmd->need_reload = false;
+}
+}
+}
+
+static void
 reconfigure_pmd_threads(struct dp_netdev *dp)
 OVS_REQUIRES(dp->port_mutex)
 {
 struct dp_netdev_pmd_thread *pmd;
 struct ovs_numa_dump *pmd_cores;
+struct ovs_numa_info_core *core;
+struct hmapx to_delete = HMAPX_INITIALIZER(_delete);
+struct hmapx_node *node;
 bool changed = false;
+bool need_to_adjust_static_tx_qids = false;
 
 /* The pmd threads should be started only if there's a pmd

Re: [ovs-dev] 答复: 答复: 答复: [PATCH] pkt reassemble: fix kernel panic for ovs reassemble

2017-07-06 Thread 王志克

Hi Greg,

Any progress?

Thanks.

Br,
Wang Zhike

-Original Message-
From: Greg Rose [mailto:gvrose8...@gmail.com] 
Sent: Friday, June 30, 2017 1:23 AM
To: 王志克
Cc: d...@openvswitch.org; Joe Stringer
Subject: Re: 答复: [ovs-dev] 答复: 答复: [PATCH] pkt reassemble: fix kernel panic for 
ovs reassemble

On 06/28/2017 05:53 PM, 王志克 wrote:
> Hi Greg,
> 
> I just download offical tar bar:
> wget http://openvswitch.org/releases/openvswitch-2.6.0.tar.gz
> 
> Then compiling as below: ( I do not see any compiling issue)
> 
> ./configure --with-linux=/lib/modules/$(uname -r)/build
> make
> make install
> make modules_install
> 
> Br,
> Wang Zhike

Weird... below is what I get at the compile phase when I follow the same steps. 
 Let me
try a completely fresh installation of Centos 7.2 on a new VM.  Perhaps 
something has muddled
the build environments for the VM I'm using.

I'll try that and see if I can get something going.

Thanks,

- Greg

In file included from include/net/inet_sock.h:24:0,
  from include/net/ip.h:30,
  from 
/home/gvrose/prj/openvswitch-2.6.0/datapath/linux/compat/include/net/ip.h:4,
  from 
/home/gvrose/prj/openvswitch-2.6.0/datapath/linux/compat/include/linux/netfilter_ipv6.h:7,
  from 
/home/gvrose/prj/openvswitch-2.6.0/datapath/linux/actions.c:25:
/home/gvrose/prj/openvswitch-2.6.0/datapath/linux/compat/include/linux/netdevice.h:125:34:
 error: conflicting types for 
netdev_notifier_info_to_dev
  static inline struct net_device *netdev_notifier_info_to_dev(void *info)
   ^
In file included from 
/home/gvrose/prj/openvswitch-2.6.0/datapath/linux/compat/include/linux/netdevice.h:4:0,
  from include/net/inet_sock.h:24,
  from include/net/ip.h:30,
  from 
/home/gvrose/prj/openvswitch-2.6.0/datapath/linux/compat/include/net/ip.h:4,
  from 
/home/gvrose/prj/openvswitch-2.6.0/datapath/linux/compat/include/linux/netfilter_ipv6.h:7,
  from 
/home/gvrose/prj/openvswitch-2.6.0/datapath/linux/actions.c:25:
include/linux/netdevice.h:2257:1: note: previous definition of 
netdev_notifier_info_to_dev was here
  netdev_notifier_info_to_dev(const struct netdev_notifier_info *info)
  ^
In file included from include/uapi/linux/if_arp.h:26:0,
  from include/linux/if_arp.h:27,
  from 
/home/gvrose/prj/openvswitch-2.6.0/datapath/linux/datapath.c:23:
/home/gvrose/prj/openvswitch-2.6.0/datapath/linux/compat/include/linux/netdevice.h:125:34:
 error: conflicting types for 
netdev_notifier_info_to_dev
  static inline struct net_device *netdev_notifier_info_to_dev(void *info)
   ^
In file included from 
/home/gvrose/prj/openvswitch-2.6.0/datapath/linux/compat/include/linux/netdevice.h:4:0,
  from include/uapi/linux/if_arp.h:26,
  from include/linux/if_arp.h:27,
  from 
/home/gvrose/prj/openvswitch-2.6.0/datapath/linux/datapath.c:23:
include/linux/netdevice.h:2257:1: note: previous definition of 
netdev_notifier_info_to_dev was here
  netdev_notifier_info_to_dev(const struct netdev_notifier_info *info)
  ^
In file included from 
/home/gvrose/prj/openvswitch-2.6.0/datapath/linux/dp_notify.c:19:0:
/home/gvrose/prj/openvswitch-2.6.0/datapath/linux/compat/include/linux/netdevice.h:125:34:
 error: conflicting types for 
netdev_notifier_info_to_dev
  static inline struct net_device *netdev_notifier_info_to_dev(void *info)
   ^
In file included from 
/home/gvrose/prj/openvswitch-2.6.0/datapath/linux/compat/include/linux/netdevice.h:4:0,
  from 
/home/gvrose/prj/openvswitch-2.6.0/datapath/linux/dp_notify.c:19:
include/linux/netdevice.h:2257:1: note: previous definition of 
netdev_notifier_info_to_dev was here
  netdev_notifier_info_to_dev(const struct netdev_notifier_info *info)
  ^
In file included from include/net/sock.h:51:0,
  from 
/home/gvrose/prj/openvswitch-2.6.0/datapath/linux/compat/include/net/sock.h:4,
  from include/linux/tcp.h:23,
  from 
/home/gvrose/prj/openvswitch-2.6.0/datapath/linux/conntrack.c:21:
/home/gvrose/prj/openvswitch-2.6.0/datapath/linux/compat/include/linux/netdevice.h:125:34:
 error: conflicting types for 
netdev_notifier_info_to_dev
  static inline struct net_device *netdev_notifier_info_to_dev(void *info)
   ^
In file included from 
/home/gvrose/prj/openvswitch-2.6.0/datapath/linux/compat/include/linux/netdevice.h:4:0,
  from include/net/sock.h:51,
  from 
/home/gvrose/prj/openvswitch-2.6.0/datapath/linux/compat/include/net/sock.h:4,
  from include/linux/tcp.h:23,
  from 
/home/gvrose/prj/openvswitch-2.6.0/datapath/linux/conntrack.c:21:
include/linux/netdevice.h:2257:1: note: previous definition of

[ovs-dev] [PATCH] datapath: enable VxLAN-gpe port creation in compat mode

2017-07-06 Thread Yi Yang

In compat mode, ovs can't create L3 VxLAN-gpe port in old
kernels if port creation failed by rtnetlink, this patch
enables old kernels to create L3 VxLAN-gpe port.

Signed-off-by: Yi Yang 
---
 datapath/vport-vxlan.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/datapath/vport-vxlan.c b/datapath/vport-vxlan.c
index 7beaf6e..fbde91f 100644
--- a/datapath/vport-vxlan.c
+++ b/datapath/vport-vxlan.c
@@ -52,6 +52,18 @@ static int vxlan_get_options(const struct vport *vport, 
struct sk_buff *skb)
return -EMSGSIZE;
 
nla_nest_end(skb, exts);
+   } else if (vxlan->flags & VXLAN_F_GPE) {
+   struct nlattr *exts;
+
+   exts = nla_nest_start(skb, OVS_TUNNEL_ATTR_EXTENSION);
+   if (!exts)
+   return -EMSGSIZE;
+
+   if (vxlan->flags & VXLAN_F_GPE &&
+   nla_put_flag(skb, OVS_VXLAN_EXT_GPE))
+   return -EMSGSIZE;
+
+   nla_nest_end(skb, exts);
}
 
return 0;
@@ -59,6 +71,7 @@ static int vxlan_get_options(const struct vport *vport, 
struct sk_buff *skb)
 
 static const struct nla_policy exts_policy[OVS_VXLAN_EXT_MAX + 1] = {
[OVS_VXLAN_EXT_GBP] = { .type = NLA_FLAG, },
+   [OVS_VXLAN_EXT_GPE] = { .type = NLA_FLAG, },
 };
 
 static int vxlan_configure_exts(struct vport *vport, struct nlattr *attr,
@@ -77,6 +90,8 @@ static int vxlan_configure_exts(struct vport *vport, struct 
nlattr *attr,
 
if (exts[OVS_VXLAN_EXT_GBP])
conf->flags |= VXLAN_F_GBP;
+   else if (exts[OVS_VXLAN_EXT_GPE])
+   conf->flags |= VXLAN_F_GPE;
 
return 0;
 }
-- 
2.1.0

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

Re: [ovs-dev] [PATCH v2] dpif-netlink: convert packet_type netlink attribute

2017-07-06 Thread Yang, Yi Y

Eric, I verified this one, ptap unit tests and nsh tests passed without any 
change, so it seems it is better than the original one you did.

-Original Message-
From: Eric Garver [mailto:e...@erig.me] 
Sent: Friday, July 7, 2017 3:44 AM
To: Zoltán Balogh 
Cc: Yang, Yi Y ; 'd...@openvswitch.org' 

Subject: Re: [ovs-dev] [PATCH v2] dpif-netlink: convert packet_type netlink 
attribute

On Thu, Jul 06, 2017 at 01:14:31PM +, Zoltán Balogh wrote:
> Hi Eric,
> 
> Thank you for clarifying. 
> 
> ...
> [OVS_FLOW_ATTR_KEY]
> ...
> [OVS_KEY_ATTR_IPV4] = ...
> ...
> [OVS_KEY_ATTR_ETHERTYPE] = ...  <--- the one inserted
> 
> I have not found any API that would extend a nested attribute. 
> Maybe I'm wrong, but I thought 'buf' holds a single nested attribute. If this 
> is true, isn't possible to add the ethertype to it and increase its size?

I gave it a try and realized it doesn't matter.

During the upcall we pass back the same key that the kernel gave us, with the 
exception that we also fill in wildcard info. See
upcall_xlate() and ukey_create_from_upcall(). This is why my original patch 
works. It caused odp_flow_key_from_mask() to fill the ETHERTYPE for the mask.

So I think this can only be solved in one of two places:

  1) odp_flow_key_from_mask(), as my original patch did.
- This sets the wildcard for all dpifs, including userspace/netdev.
  2) xlate_wc_init() and xlate_wc_finish().
- Here we can limit by dpif type.

Neither which is particularly pleasing. I gave #2 a try. see patch below. It 
works for both check-kernel and check-system-userspace. It does not force 
eth_type() for userspace.

What do you think?

Eric.

--->8---

diff --git a/ofproto/ofproto-dpif-xlate.c b/ofproto/ofproto-dpif-xlate.c index 
1f4fe1dd6725..f3074c78c4b2 100644
--- a/ofproto/ofproto-dpif-xlate.c
+++ b/ofproto/ofproto-dpif-xlate.c
@@ -6129,7 +6129,10 @@ xlate_wc_init(struct xlate_ctx *ctx)
 /* Some fields we consider to always be examined. */
 WC_MASK_FIELD(ctx->wc, packet_type);
 WC_MASK_FIELD(ctx->wc, in_port);
-if (is_ethernet(>xin->flow, NULL)) {
+if (is_ethernet(>xin->flow, NULL)
+|| (pt_ns(ctx->xin->flow.packet_type) == OFPHTN_ETHERTYPE
+&& !strcmp(dpif_normalize_type(dpif_type(ctx->xbridge->dpif)),
+   "system"))) {
 WC_MASK_FIELD(ctx->wc, dl_type);
 }
 if (is_ip_any(>xin->flow)) {
@@ -6163,7 +6166,12 @@ xlate_wc_finish(struct xlate_ctx *ctx)
 if (ctx->xin->upcall_flow->packet_type != htonl(PT_ETH)) {
 ctx->wc->masks.dl_dst = eth_addr_zero;
 ctx->wc->masks.dl_src = eth_addr_zero;
-ctx->wc->masks.dl_type = 0;
+/* Kernel uses ETHERTYPE to implicitly mean packet_type(1, x) */
+if (pt_ns(ctx->xin->upcall_flow->packet_type) != OFPHTN_ETHERTYPE
+|| strcmp(dpif_normalize_type(dpif_type(ctx->xbridge->dpif)),
+  "system")) {
+ctx->wc->masks.dl_type = 0;
+}
 }

 /* ICMPv4 and ICMPv6 have 8-bit "type" and "code" fields.  struct flow
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH v3 3/6] ovn: l3ha, handling of multiple gateway chassis

2017-07-06 Thread Russell Bryant

I'm not done reviewing this, but I figured I'd send out what I have so
far.  I'll continue tomorrow.


On Wed, Jul 5, 2017 at 9:45 AM, Miguel Angel Ajo  wrote:

Some minor commit message typos:

> This patch handles multiple gateway_chassis with in chassisredirect

s/with in/within/

> ports, any gateway with a chassis redirect port will implement the

s/, any/. Any/

s/chassis redirect/chassisredirect/

> rules to de-encapsulate incomming packets for such port.

s/incomming/incoming/


a question about this ... the L3 HA design doc mentions how it's
important for gateways to drop packets unless they are the current
active gateway.  The commit message implies that all gateway chassis
will have the flows for receiving traffic, even if they are not the
active gateway chassis.  What's the intended behavior with this series
right now?  and do any later patches change it?

>
> And hosts targetting a remote chassisredirect port will setup a

s/targetting/targeting/

> bundle(active_backup, ..) action to each tunnel port, in the given
> priority order.

maybe note that a future patch will enable BFD to detect when a remote
gateway chassis is no longer reachable?

>
> Signed-off-by: Miguel Angel Ajo 
> Signed-off-by: Venkata Anil Kommaddi 

This will need a Co-authored-by header as well for Anil.

> ---
>  ovn/controller/automake.mk  |   2 +
>  ovn/controller/binding.c|  13 +-
>  ovn/controller/binding.h|   1 +
>  ovn/controller/gchassis.c   | 176 +
>  ovn/controller/gchassis.h   |  63 
>  ovn/controller/lflow.c  |   7 +-
>  ovn/controller/lport.h  |   4 +
>  ovn/controller/ovn-controller.c |  15 +-
>  ovn/controller/physical.c   | 124 ---
>  ovn/controller/physical.h   |   4 +-
>  tests/ovn.at| 330 
> +++-
>  11 files changed, 710 insertions(+), 29 deletions(-)
>  create mode 100644 ovn/controller/gchassis.c
>  create mode 100644 ovn/controller/gchassis.h
>
> diff --git a/ovn/controller/automake.mk b/ovn/controller/automake.mk
> index 8c6a787..d3828f5 100644
> --- a/ovn/controller/automake.mk
> +++ b/ovn/controller/automake.mk
> @@ -6,6 +6,8 @@ ovn_controller_ovn_controller_SOURCES = \
> ovn/controller/chassis.h \
> ovn/controller/encaps.c \
> ovn/controller/encaps.h \
> +   ovn/controller/gchassis.c \
> +   ovn/controller/gchassis.h \
> ovn/controller/lflow.c \
> ovn/controller/lflow.h \
> ovn/controller/lport.c \
> diff --git a/ovn/controller/binding.c b/ovn/controller/binding.c
> index bb76608..f5526fd 100644
> --- a/ovn/controller/binding.c
> +++ b/ovn/controller/binding.c
> @@ -15,6 +15,7 @@
>
>  #include 
>  #include "binding.h"
> +#include "gchassis.h"
>  #include "lflow.h"
>  #include "lport.h"
>
> @@ -26,6 +27,7 @@
>  #include "lib/vswitch-idl.h"
>  #include "openvswitch/hmap.h"
>  #include "openvswitch/vlog.h"
> +#include "ovn/lib/chassis-index.h"
>  #include "ovn/lib/ovn-sb-idl.h"
>  #include "ovn-controller.h"
>
> @@ -394,12 +396,15 @@ consider_local_datapath(struct controller_ctx *ctx,
> false, local_datapaths);
>  }
>  } else if (!strcmp(binding_rec->type, "chassisredirect")) {
> -const char *chassis_id = smap_get(_rec->options,
> -  "redirect-chassis");
> -our_chassis = chassis_id && !strcmp(chassis_id, chassis_rec->name);
> -if (our_chassis) {
> +if (gateway_chassis_in_pb_contains(binding_rec, chassis_rec)) {
>  add_local_datapath(ldatapaths, lports, binding_rec->datapath,
> false, local_datapaths);
> +/* XXX this should only be set to true if our chassis
> + * (chassis_rec) is the master for this chassisredirect port
> + * but for now we'll bind it only when not bound, this is
> + * handled in subsequent patches */
> +our_chassis = !binding_rec->chassis ||
> +chassis_rec == binding_rec->chassis;

There seems to be a bit of a race condition here.  Multiple configured
gateway chassis for a port will see that this is unbound all at the
same time and they will all try to bind it.  It's not defined which
one would end up having the port bound.  I know this gets changed in a
future patch, though.

One possible change for this stage of series would be to always only
have the highest priority gateway_chassis be the one to bind the port.

>  }
>  } else if (!strcmp(binding_rec->type, "l3gateway")) {
>  const char *chassis_id = smap_get(_rec->options,
> diff --git a/ovn/controller/binding.h b/ovn/controller/binding.h
> index 3bfa7d1..136b3a7 100644
> --- a/ovn/controller/binding.h
> +++ b/ovn/controller/binding.h
> @@ -20,6 +20,7 @@
>  #include 
>
>  struct controller_ctx;
> +struct

Re: [ovs-dev] [PATCH v4 0/7] Packet type aware pipeline

2017-07-06 Thread Yang, Yi Y

I think it needs root privilege to run.

-Original Message-
From: ovs-dev-boun...@openvswitch.org [mailto:ovs-dev-boun...@openvswitch.org] 
On Behalf Of Darrell Ball
Sent: Friday, July 7, 2017 5:06 AM
To: Eric Garver 
Cc: 'd...@openvswitch.org' ; simon.hor...@netronome.com; 
Jiri Benc 
Subject: Re: [ovs-dev] [PATCH v4 0/7] Packet type aware pipeline

btw, I asked Andy to check on his Trusty system and he observes the same 
failure. 

On 7/6/17, 1:39 PM, "Darrell Ball"  wrote:



On 7/6/17, 1:22 PM, "Eric Garver"  wrote:

On Thu, Jul 06, 2017 at 03:59:51PM +, Darrell Ball wrote:
> Patch 4 added unit tests
> One test was added to system userspace.
> I ran it many times and it has never passed.
> Is something missing in the test or supporting code ?

Works for me. Maybe there is a timing problem?

Thanks
There are races in the system tests, but those tests will pass on a second 
attempt.
This is 100% failure.

OVS: current master (fb16fec66498)

Tip of master - same for me

Kernel: 4.12.0-rc7+

I tried 2 kernels 4.2.0 and 3.19 – always fails in both.

OS: RHEL 7.4-ish

I really hope the distro is not relevant here
If you have reason to think so, pls speak up


> 
> ## -- ##
> ## openvswitch 2.7.90 test suite. ##
> ## -- ##
>  94: ptap - triangle bridge setup with L2 and L3 GRE tunnels FAILED 
(system-userspace-packet-type-aware.at:344)
> 
> ## - ##
> ## Test results. ##
> ## - ##
> 
> ERROR: 1 test was run,
> 1 failed unexpectedly.
> ## --- ##
> ## system-userspace-testsuite.log was created. ##
> ## --- ##
> 
> Please send `tests/system-userspace-testsuite.log' and all 
information you think might help:
> 
>To: 
>Subject: [openvswitch 2.7.90] system-userspace-testsuite: 94 failed
> 
> You may investigate any problem if you feel able to do so, in which
> case the test suite provides a good starting point.  Its output may
> be found below `tests/system-userspace-testsuite.dir'.
> 
> make: *** [check-system-userspace] Error 1
> make: Leaving directory `/home/dball/openvswitch/ovs/_gcc'
> 
> 
> 
> 
> On 6/27/17, 2:29 PM, "ovs-dev-boun...@openvswitch.org on behalf of 
Ben Pfaff"  wrote:
> 
> On Fri, Jun 23, 2017 at 04:47:48PM +, Zoltán Balogh wrote:
> > 
> > This series was started by Ben Pfaff, v3 can be found here:
> > 
https://urldefense.proofpoint.com/v2/url?u=https-3A__patchwork.ozlabs.org_patch_778070_=DwIFAw=uilaK90D4TOVoH58JNXRgQ=BVhFA09CGX7JQ5Ih-uZnsw=YZOYZFR6QorkvkAZXXYPq7Z9SWuK0lZg9EH6ND2me04=01fMZLg-sq_Rf_2X9TcxmtDN0Vx2hS2v4BABA77en0w=
 
> > 
https://urldefense.proofpoint.com/v2/url?u=https-3A__patchwork.ozlabs.org_patch_778071_=DwIFAw=uilaK90D4TOVoH58JNXRgQ=BVhFA09CGX7JQ5Ih-uZnsw=YZOYZFR6QorkvkAZXXYPq7Z9SWuK0lZg9EH6ND2me04=5fpQZh33OQ_0AGjRuJNQqvS-1E6yhFoD5TxUoLayzwM=
 
> > 
https://urldefense.proofpoint.com/v2/url?u=https-3A__patchwork.ozlabs.org_patch_778076_=DwIFAw=uilaK90D4TOVoH58JNXRgQ=BVhFA09CGX7JQ5Ih-uZnsw=YZOYZFR6QorkvkAZXXYPq7Z9SWuK0lZg9EH6ND2me04=rqnhEoIuJ9rECQaXZafZGrAW9us8y184GCexqK8VUxQ=
 
> > 
https://urldefense.proofpoint.com/v2/url?u=https-3A__patchwork.ozlabs.org_patch_778072_=DwIFAw=uilaK90D4TOVoH58JNXRgQ=BVhFA09CGX7JQ5Ih-uZnsw=YZOYZFR6QorkvkAZXXYPq7Z9SWuK0lZg9EH6ND2me04=p5Fnh2SQ8fUrNF0V8ChNRQyQLmbjiuvKRd1UUwE93s8=
 
> > 
https://urldefense.proofpoint.com/v2/url?u=https-3A__patchwork.ozlabs.org_patch_778074_=DwIFAw=uilaK90D4TOVoH58JNXRgQ=BVhFA09CGX7JQ5Ih-uZnsw=YZOYZFR6QorkvkAZXXYPq7Z9SWuK0lZg9EH6ND2me04=02CPoSKkiGGsFX4neL8TpGa75VUPaaeNYWz_2WbqBsQ=
 
> > 
https://urldefense.proofpoint.com/v2/url?u=https-3A__patchwork.ozlabs.org_patch_778073_=DwIFAw=uilaK90D4TOVoH58JNXRgQ=BVhFA09CGX7JQ5Ih-uZnsw=YZOYZFR6QorkvkAZXXYPq7Z9SWuK0lZg9EH6ND2me04=eMl7m4NpJSD07nXTN_oOdQFvysmJnclSRw39GgGg9BQ=
 
> > 
https://urldefense.proofpoint.com/v2/url?u=https-3A__patchwork.ozlabs.org_patch_778075_=DwIFAw=uilaK90D4TOVoH58JNXRgQ=BVhFA09CGX7JQ5Ih-uZnsw=YZOYZFR6QorkvkAZXXYPq7Z9SWuK0lZg9EH6ND2me04=71zSrD_kcUjZwuKvjfeqam_rdCpeXuxtm4TW_SsZ_3w=
 
> > 
> > Ben's series is based on this one:
> >

Re: [ovs-dev] GTP support to OVS upstream

2017-07-06 Thread Yang, Yi Y

Joe, thank you for your clarification, it will significantly reduce ovs tunnel 
implementation dependency on Linux kernel if we just use udp tunnel in kernel, 
anyway userspace tunnel implementations are also some duplicates of kernel 
tunnel implementations less or more:-)

I think it will simplify ovs tunnel implementation and maintenance if we use 
generic encap & decap framework to do tunnel encap & decap and move such 
processing into OpenFlow pipeline.

-Original Message-
From: Joe Stringer [mailto:j...@ovn.org] 
Sent: Thursday, July 6, 2017 10:25 PM
To: Yang, Yi Y 
Cc: Wieger IJntema ; d...@openvswitch.org
Subject: Re: [ovs-dev] GTP support to OVS upstream

On 5 July 2017 at 03:54, Yang, Yi Y  wrote:
> I remember OpenFlow 1.6 spec (not finalized) proposes to use OpenFlow actions 
> to do GTP-u encapsulation and decapsulation, current OvS tunnel 
> implementation can't support the third kind of use case (don't encap & decap, 
> just parse, match and forward), MEC (ETSI Molibe/Multi-access Edge Computing) 
> the third kind of use case.
>
> I'm wondering if it is feasible to implement a generic UDP tunnel in OvS, let 
> Openflow do encap /decap/parse, now ovs master has fully supported L3 
> tunnel port and PTAP(Packet type aware pipeline), we have posted out generic 
> encap & decap actions implementation, once ovs officially merges them, ovs 
> can support generic encap & decap action, we can base on them to implement 
> GTP-u encap & decap, then it will be better if we can implement a generic UDP 
> tunnel, ovs can add UDP tunnel ports with different UDP port to handle 
> different tunnel protocol, I think this will be the best way to handle the 
> aforementioned three kinds of use cases.

When it comes to the OVS userspace datapath, this seems like it maps pretty 
well to how things are already being done. When it comes to kernel APIs though 
there's a bunch of considerations around minimizing code duplication with the 
rest of the code, restricting scope/size creep of the module, and expectations 
of how long the API is supported. I think further discussion is necessary in 
that space to determine whether the OVS kernel module should really follow this 
model or not.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

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

2017-07-06 Thread Russell Bryant

On Thu, Jul 6, 2017 at 2:15 PM, Han Zhou  wrote:
> Despite the original motivation of this change, I found the patch valuable
> for data-plane performance.
>
> When localnet port is used for communication between 2 ports of same
> lswitch (basic provider network scenario), without the patch, each flow is
> tracked in conntrack table twice. With the patch, it improve the
> performance in 2 ways:
>
> 1) It reduces 50% of conntrack operations
>
> 2) It reduces 50% number of entries in conntrack table, which also helps
> reducing conntrack cost
>
> I had some tests for TCP_CRR, it improves performance for 5 - 10%.
> Discussed in today's ovn meeting and we agreed it is valid optimization
> because localnet port is used as transport, not the real end-point to
> protect.
>
> @Qianyu, would it be good to revise the patch on the commit message to put
> it as an optimization for conntrack performance? The current commit message
> is not true because it is not a supported scenario for now, and the "fix"
> is not complete, either. The new scenaro would worth a separate discussion.
> What do you think?

While the localnet port is not an endpoint, it did seem useful to me
to be able to define security policy there as that is the first place
traffic enters from "outside" of OVN.  We could potentially drop
traffic sooner, before sending it over to the final endpoint on
another chassis.  Based on a quick review of the discussion, it does
seem like dropping it is the better choice for now.

If the security aspect is desired later, perhaps we could solve it
another way by supporting ACLs associated with the L3 gateway sitting
between an OVN logical network and a physical network (localnet
network).

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

Re: [ovs-dev] [PATCH] Makefiles: Fail build for flake8 only when configured with --enable-Werror.

2017-07-06 Thread Russell Bryant

On Thu, Jul 6, 2017 at 6:12 PM, Ben Pfaff  wrote:
> flake8 checking is useful.  Until now, it always failed the build for any
> flake8 errors.  This is too aggressive, for the same reason that always
> failing the build for any compiler warnings is too aggressive: compilers
> change over time and asynchronously from OVS itself.  Thus, if we release
> some version of OVS today, even if it's flake8-clean today, it might not
> be flake8-clean tomorrow, even with the same settings.  We don't want to
> have to track flake8 warnings on every release branch.
>
> Thus, this adopts the same policy for compiler warnings: always report
> them, but only fail the build if --enable-Werror was configured.  Usually
> just developers use that configure option, and they're prepared to deal
> with the fallout.
>
> Signed-off-by: Ben Pfaff 


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

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

2017-07-06 Thread wang . qianyu

Hi Han

Thanks for the reiew job.

I will revise the commit message in new patch.

Qianyu

Han Zhou
2017/07/07 02:15

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

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

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

1) It reduces 50% of conntrack operations

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

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

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

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

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

Thanks for your review.

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

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

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

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

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

Mickey

Thanks!

Mickey Spiegel
2017/06/30 12:31

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

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

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

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

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

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

There is a big difference between:
1) bridging between

[ovs-dev] [PATCH v2] netdev-linux: Replace sendmsg with sendmmsg in netdev_linux_send

2017-07-06 Thread Zhenyu Gao

Sendmmsg can reduce cpu cycles in sending packets to kernel.
Replace sendmsg with sendmmsg in function netdev_linux_send to send
batch packets if sendmmsg is available.

If kernel side doesn't support sendmmsg, will fallback to sendmsg.

netserver
||
||
|  container |
|veth|
  |
  |||
  |---veth-|   dpdk-ovs |  netperf
   ||  |--|
   |dpdk|  | bare-metal   |
 | |--|
 |  |
 |  |
pnic---pnic

Netperf was consumed to test the performance:

1)cmd:netperf -H remote-container -t UDP_STREAM -l 60 -- -m 1400
result: netserver received 2383.21Mb(sendmsg)/2551.64Mb(sendmmsg)

2)cmd:netperf -H remote-container -t UDP_STREAM -l 60 -- -m 60
result: netserver received 109.72Mb(sendmsg)/115.18Mb(sendmmsg)

Sendmmsg show about 6% improvement in netperf UDP testing.

Signed-off-by: Zhenyu Gao 
---
 configure.ac   |  2 +-
 lib/netdev-linux.c | 71 --
 2 files changed, 70 insertions(+), 3 deletions(-)

diff --git a/configure.ac b/configure.ac
index 6404b5f..b02c7c4 100644
--- a/configure.ac
+++ b/configure.ac
@@ -106,7 +106,7 @@ AC_CHECK_DECLS([sys_siglist], [], [], [[#include 
]])
 AC_CHECK_MEMBERS([struct stat.st_mtim.tv_nsec, struct stat.st_mtimensec],
   [], [], [[#include ]])
 AC_CHECK_MEMBERS([struct ifreq.ifr_flagshigh], [], [], [[#include ]])
-AC_CHECK_FUNCS([mlockall strnlen getloadavg statvfs getmntent_r])
+AC_CHECK_FUNCS([mlockall strnlen getloadavg statvfs getmntent_r sendmmsg])
 AC_CHECK_HEADERS([mntent.h sys/statvfs.h linux/types.h linux/if_ether.h 
stdatomic.h])
 AC_CHECK_HEADERS([net/if_mib.h], [], [], [[#include 
 #include ]])
diff --git a/lib/netdev-linux.c b/lib/netdev-linux.c
index 1b88775..b90a22a 100644
--- a/lib/netdev-linux.c
+++ b/lib/netdev-linux.c
@@ -1187,6 +1187,54 @@ netdev_linux_rxq_drain(struct netdev_rxq *rxq_)
 }
 }
 
+static inline int
+netdev_linux_sock_batch_send(int sock, struct msghdr *msg,
+ struct dp_packet_batch *batch)
+{
+int error = 0;
+ssize_t retval;
+uint32_t resend_idx = 0;
+struct mmsghdr *mmsg;
+struct iovec *iov;
+
+mmsg = xmalloc(sizeof(*mmsg) * batch->count);
+iov = xmalloc(sizeof(*iov) * batch->count);
+
+for (int i = 0; i < batch->count; i++) {
+const void *data = dp_packet_data(batch->packets[i]);
+size_t size = dp_packet_size(batch->packets[i]);
+
+/* Truncate the packet if it is configured. */
+size -= dp_packet_get_cutlen(batch->packets[i]);
+
+iov[i].iov_base = CONST_CAST(void *, data);
+iov[i].iov_len = size;
+mmsg[i].msg_hdr = *msg;
+mmsg[i].msg_hdr.msg_iov = [i];
+}
+
+resend_batch:
+retval = sendmmsg(sock, mmsg + resend_idx,
+  batch->count - resend_idx, 0);
+if (retval < 0) {
+if (errno == EINTR) {
+goto resend_batch;
+}
+/* The Linux AF_PACKET implementation never blocks waiting for
+ * room for packets, instead returning ENOBUFS.  Translate this
+ * into EAGAIN for the caller. */
+error = errno == ENOBUFS ? EAGAIN : errno;
+} else if (retval != batch->count - resend_idx) {
+   /* Send remain packets again. */
+resend_idx += retval;
+goto resend_batch;
+}
+
+free(mmsg);
+free(iov);
+return error;
+}
+
 /* Sends 'buffer' on 'netdev'.  Returns 0 if successful, otherwise a positive
  * errno value.  Returns EAGAIN without blocking if the packet cannot be queued
  * immediately.  Returns EMSGSIZE if a partial packet was transmitted or if
@@ -1207,6 +1255,9 @@ netdev_linux_send(struct netdev *netdev_, int qid 
OVS_UNUSED,
 struct sockaddr_ll sll;
 struct msghdr msg;
 if (!is_tap_netdev(netdev_)) {
+#ifdef HAVE_SENDMMSG
+static bool try_sendmmsg = true;
+#endif
 sock = af_packet_sock();
 if (sock < 0) {
 error = -sock;
@@ -1231,6 +1282,21 @@ netdev_linux_send(struct netdev *netdev_, int qid 
OVS_UNUSED,
 msg.msg_control = NULL;
 msg.msg_controllen = 0;
 msg.msg_flags = 0;
+
+#ifdef HAVE_SENDMMSG
+if (try_sendmmsg) {
+/* Try batch sending to socket */
+error = netdev_linux_sock_batch_send(sock, , batch);
+if (error == ENOSYS) {
+/* Linux kernel does not implement this function */
+try_sendmmsg = false;
+VLOG_WARN("Linux kernel doesn't implement sendmmsg, "
+  "going to consume sendmsg");
+} else {
+goto check_error;
+}
+}
+#endif
 }
 
 /* 'i' is incremented only if there's no error */
@@ -1290,9

[ovs-dev] [PATCH v1] vswitchd: Fix IFACE_STAT name error in iface_refresh_stats

2017-07-06 Thread Zhenyu Gao

The element of rx_1024_to_1522_packets has wrong name(rx_1024_to_1518_packets).
Change it from rx_1024_to_1518_packets to rx_1024_to_1522_packets, it should
record packets between 1024 to 1522.

The element of tx_1024_to_1522_packets has wrong name(tx_1024_to_1518_packets).
Change it from tx_1024_to_1518_packets to tx_1024_to_1522_packets, it should
record packets between 1024 to 1522.

Signed-off-by: Zhenyu Gao 
---
 vswitchd/bridge.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/vswitchd/bridge.c b/vswitchd/bridge.c
index 8336d70..b9fb8e6 100644
--- a/vswitchd/bridge.c
+++ b/vswitchd/bridge.c
@@ -2369,14 +2369,14 @@ iface_refresh_stats(struct iface *iface)
 IFACE_STAT(rx_128_to_255_packets,   "rx_128_to_255_packets")\
 IFACE_STAT(rx_256_to_511_packets,   "rx_256_to_511_packets")\
 IFACE_STAT(rx_512_to_1023_packets,  "rx_512_to_1023_packets")   \
-IFACE_STAT(rx_1024_to_1522_packets, "rx_1024_to_1518_packets")  \
+IFACE_STAT(rx_1024_to_1522_packets, "rx_1024_to_1522_packets")  \
 IFACE_STAT(rx_1523_to_max_packets,  "rx_1523_to_max_packets")   \
 IFACE_STAT(tx_1_to_64_packets,  "tx_1_to_64_packets")   \
 IFACE_STAT(tx_65_to_127_packets,"tx_65_to_127_packets") \
 IFACE_STAT(tx_128_to_255_packets,   "tx_128_to_255_packets")\
 IFACE_STAT(tx_256_to_511_packets,   "tx_256_to_511_packets")\
 IFACE_STAT(tx_512_to_1023_packets,  "tx_512_to_1023_packets")   \
-IFACE_STAT(tx_1024_to_1522_packets, "tx_1024_to_1518_packets")  \
+IFACE_STAT(tx_1024_to_1522_packets, "tx_1024_to_1522_packets")  \
 IFACE_STAT(tx_1523_to_max_packets,  "tx_1523_to_max_packets")   \
 IFACE_STAT(tx_multicast_packets,"tx_multicast_packets") \
 IFACE_STAT(rx_broadcast_packets,"rx_broadcast_packets") \
-- 
1.8.3.1

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

Re: [ovs-dev] [PATCH] conntrack : Use Rx checksum offload feature on DPDK ports for conntrack.

2017-07-06 Thread Darrell Ball

This has been updated and I will be reviewing the changes

Thanks Darrell

On 7/6/17, 4:59 PM, "Ben Pfaff"  wrote:

Do you still intend to look closer?

On Tue, Jun 06, 2017 at 04:40:14PM +, Darrell Ball wrote:
> I did a first pass, but I will look thru. it more carefully and test it.
> The benefit is smaller than I had hoped, even in a simple case, but the 
code delta is also simple.
> 
> Thanks Darrell
> 
> On 6/6/17, 3:45 AM, "ovs-dev-boun...@openvswitch.org on behalf of 
Chandran, Sugesh"  wrote:
> 
> Ping!. 
> Any other comments on this patch??
> 
> 
> Regards
> _Sugesh
> 
> 
> > -Original Message-
> > From: Fischetti, Antonio
> > Sent: Friday, May 26, 2017 11:05 AM
> > To: Chandran, Sugesh ; ovs-
> > d...@openvswitch.org
> > Subject: RE: [ovs-dev] [PATCH] conntrack : Use Rx checksum offload 
feature
> > on DPDK ports for conntrack.
> > 
> > Hi Sugesh,
> > it looks good to me, it makes sense to leverage the csum info when 
present.
> > 
> > I've tested it with the firewall rules - see below for details - I 
saw a ~+3%
> > improvement in my testbench with 10 UDP connections.
> > 
> > Traffic Gen: IXIA IxExplorer
> > 10 UDP different flows, 64B pkts
> > 
> > Original OvS:   3.0 Mpps
> > With this Patch: 3.1 Mpps
> > 
> > 
> > Below some details of my testbench.
> > 
> > ===
> > 
> > BUILD
> > -
> > make -j 28 CFLAGS="-O2 -march=native -g"
> > 
> > #I didn't use intrinsics, I expect in that case the benefit will be 
smaller.
> > 
> > FLOW DUMP
> > -
> > NXST_FLOW reply (xid=0x4):
> >  cookie=0x0, duration=0.064s, table=0, n_packets=0, n_bytes=0, 
idle_age=0,
> > priority=100,ct_state=-trk,ip actions=ct(table=1)  cookie=0x0,
> > duration=0.075s, table=0, n_packets=0, n_bytes=0, idle_age=0,
> > priority=10,arp actions=NORMAL  cookie=0x0, duration=0.085s, 
table=0,
> > n_packets=0, n_bytes=0, idle_age=0, priority=1 actions=drop  
cookie=0x0,
> > duration=0.054s, table=1, n_packets=0, n_bytes=0, idle_age=0,
> > ct_state=+new+trk,ip,in_port=1 actions=ct(commit),output:2  
cookie=0x0,
> > duration=0.033s, table=1, n_packets=0, n_bytes=0, idle_age=0,
> > ct_state=+new+trk,ip,in_port=2 actions=drop  cookie=0x0, 
duration=0.043s,
> > table=1, n_packets=0, n_bytes=0, idle_age=0,
> > ct_state=+est+trk,ip,in_port=1 actions=output:2  cookie=0x0,
> > duration=0.023s, table=1, n_packets=0, n_bytes=0, idle_age=0,
> > ct_state=+est+trk,ip,in_port=2 actions=output:1
> > 
> > HugePages_Total:   20480
> > HugePages_Free:20480
> > HugePages_Rsvd:0
> > HugePages_Surp:0
> > ___
> > DPDK: HEAD detached at v16.11
> > OvS:  On my local branch ConnTrack_01
> > ___
> > 
> >PID PSR COMMAND %CPU
> >  20509   0 ovsdb-server 0.0
> >  20522   2 ovs-vswitchd78.1
> >  20522   4 pmd62   80.8
> >  20522   5 pmd61   71.6
> > 
> > PDM threads:  2
> > 
> > configured_tx_queues=3,
> > configured_tx_queues=3,
> > 
> > 
> > Regards,
> > Antonio
> > 
> > 
> > Acked-by: Antonio Fischetti 
> > 
> > 
> > > -Original Message-
> > > From: ovs-dev-boun...@openvswitch.org [mailto:ovs-dev-
> > > boun...@openvswitch.org] On Behalf Of Sugesh Chandran
> > > Sent: Thursday, May 25, 2017 10:11 PM
> > > To: ovs-dev@openvswitch.org
> > > Subject: [ovs-dev] [PATCH] conntrack : Use Rx checksum offload 
feature
> > > on DPDK ports for conntrack.
> > >
> > > Avoiding checksum validation in conntrack module if it is already
> > > verified in DPDK physical NIC ports.
> > >
> > > Signed-off-by: Sugesh Chandran 
> > > ---
> > >  lib/conntrack.c | 58
> > > 
> > > -
> > >  1 file changed, 37 insertions(+), 21 deletions(-)
> > >
> > > diff --git a/lib/conntrack.c b/lib/conntrack.c index 
cb30ac7..af6a372
> > > 100644
> > > --- a/lib/conntrack.c
> > >

Re: [ovs-dev] [PATCH] submitting-patches: Update test and documentation recommendations.

2017-07-06 Thread Darrell Ball



On 5/18/17, 5:32 AM, "ovs-dev-boun...@openvswitch.org on behalf of Ben Pfaff" 
 wrote:

Rationale:

- "make distcheck" is not as necessary anymore because we have a build-time
  check that fails if files in the repository are not distributed.

- xenserver has not been important for years, so remove the specific
  callout.

- We already have an informal custom of adding tests for new feaures and
  bug fixes, so codify it.

- Add note about updating NEWS.

Signed-off-by: Ben Pfaff 
---
 .../internals/contributing/submitting-patches.rst  | 25 
+++---
 1 file changed, 12 insertions(+), 13 deletions(-)

diff --git a/Documentation/internals/contributing/submitting-patches.rst 
b/Documentation/internals/contributing/submitting-patches.rst
index edbc1aa8d9ff..4f7ca0304034 100644
--- a/Documentation/internals/contributing/submitting-patches.rst
+++ b/Documentation/internals/contributing/submitting-patches.rst
@@ -44,29 +44,28 @@ particular:
 - A patch should make one logical change.  Don't make multiple, logically
   unconnected changes to disparate subsystems in a single patch.
 
-- A patch that adds or removes user-visible features should also update the
-  appropriate user documentation or manpages.  Check "Feature Deprecation
-  Guidelines" section in this document if you intend to remove user-visible
-  feature.
+- A patch that adds or removes user-visible features should also
+  update the appropriate user documentation or manpages.  Consider
+  adding an item to NEWS for nontrivial changes.  Check "Feature
+  Deprecation Guidelines" section in this document if you intend to
+  remove user-visible feature.
 
 Testing is also important:
 
-- A patch that modifies existing code should be tested with ``make
-  check`` before submission.  Refer to the `install guide`, under 
"Self-Tests",
-  for more information.
+- Test a patch that modifies existing code with ``make check`` before
+  submission.  Refer to the `install guide`, under "Self-Tests", for
+  more information.

I think “Testing” is under Documentation and the label is “Unit Tests”
I cannot find the title “Self-Tests”, but admittedly, I have little patience.

Maybe checking the system tests (kernel and userspace) should be strongly 
suggested, 
if not an expectation.

 
-- A patch that adds or deletes files should also be tested with ``make
+- Consider testing a patch that adds or deletes files with ``make
   distcheck`` before submission.
 
 - A patch that modifies Linux kernel code should be at least build-tested 
on
   various Linux kernel versions before submission.  I suggest versions 
3.10 and
   whatever the current latest release version is at the time.
 
-- A patch that modifies the ofproto or vswitchd code should be tested in at
-  least simple cases before submission.
-
-- A patch that modifies xenserver code should be tested on XenServer before
-  submission.
+- A patch that adds a new feature should add appropriate tests for the
+  feature.  A bug fix patch should preferably add a test that would
+  fail if the bug recurs.
 
 If you are using GitHub, then you may utilize the travis-ci.org CI build 
system
 by linking your GitHub repository to it. This will run some of the above 
tests
-- 
2.10.2

___
dev mailing list
d...@openvswitch.org

https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddev=DwICAg=uilaK90D4TOVoH58JNXRgQ=BVhFA09CGX7JQ5Ih-uZnsw=vV-qzeme225zuTayBoQVI5Qb9Cx0DZaeSRShNoyY1W8=6Vk6zDH4PRJGGw3UKXtOVXyIlJ3grOlwabbxT-K4wFE=
 


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

72 matches

Mail list logo