Re: [ovs-dev] [PATCH 6/7] netfilter: Remove useless param helper of nf_ct_helper_ext_add

2019-05-07 Thread Gao Feng 


At 2019-05-07 05:56:47, "Yifeng Sun"  wrote:
>From: Gao Feng 
>
>Upstream commit:
>commit 440534d3c56be04abfb26850ee882d19d223557a
>Author: Gao Feng 
>Date:   Mon Jul 9 18:06:33 2018 +0800
>
>netfilter: Remove useless param helper of nf_ct_helper_ext_add
>
>The param helper of nf_ct_helper_ext_add is useless now, then remove
>it now.
>
>Signed-off-by: Gao Feng 
>Signed-off-by: Pablo Neira Ayuso 
>
>This patch backports the above upstream patch to OVS.
>
>Cc: Gao Feng 
>Signed-off-by: Yifeng Sun 
>---
> acinclude.m4 |  3 +++
> .../linux/compat/include/net/netfilter/nf_conntrack_helper.h | 12 
> 2 files changed, 15 insertions(+)
>
>diff --git a/acinclude.m4 b/acinclude.m4
>index 4c533bb98949..91e07d871f58 100644
>--- a/acinclude.m4
>+++ b/acinclude.m4
>@@ -938,6 +938,9 @@ AC_DEFUN([OVS_CHECK_LINUX_COMPAT], [
>   [OVS_DEFINE([HAVE_IPV6_FRAG_H])])
>   OVS_GREP_IFELSE([$KSRC/include/net/netfilter/nf_conntrack.h],
>   [nf_ct_invert_tuplepr])
>+  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])])
> 
>   if cmp -s datapath/linux/kcompat.h.new \
> datapath/linux/kcompat.h >/dev/null 2>&1; then
>diff --git a/datapath/linux/compat/include/net/netfilter/nf_conntrack_helper.h 
>b/datapath/linux/compat/include/net/netfilter/nf_conntrack_helper.h
>index 19c35cd95f6f..0b685cc1a05a 100644
>--- a/datapath/linux/compat/include/net/netfilter/nf_conntrack_helper.h
>+++ b/datapath/linux/compat/include/net/netfilter/nf_conntrack_helper.h
>@@ -9,4 +9,16 @@ static inline void nf_conntrack_helper_put(struct 
>nf_conntrack_helper *helper) {
> }
> #endif
> 
>+static inline struct nf_conn_help *
>+rpl_nf_ct_helper_ext_add(struct nf_conn *ct,
>+   struct nf_conntrack_helper *helper, gfp_t gfp)
>+{
>+#ifdef HAVE_NF_CT_HELPER_EXT_ADD_TAKES_HELPER
>+  return nf_ct_helper_ext_add(ct, helper, gfp);
>+#else
>+  return nf_ct_helper_ext_add(ct, gfp);
>+#endif
>+}
>+#define nf_ct_helper_ext_add rpl_nf_ct_helper_ext_add
>+
> #endif /* _NF_CONNTRACK_HELPER_WRAPPER_H */
>-- 
>2.7.4
>

Good for me.

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

Re: [ovs-dev] [PATCH] OVN: fix pinctrl ip buffering for gw router port

2019-05-07 Thread Ben Pfaff 
On Tue, May 07, 2019 at 03:08:52PM +0200, Lorenzo Bianconi wrote:
> Use sb mac binding table to trigger ip buffer dequeueing instead of
> the APR/ND packet reception since the ARP reply can be managed on a
> different chassis if a gw router port is scheduled on a different
> node
> 
> Signed-off-by: Lorenzo Bianconi 

Thanks!

buffered_mac_bindings doesn't seem to really be used as a hash table:
nothing ever searches it.  Should it be a linked list?  Or maybe it's
just an hmap because destroy_buffered_packets() expects that.  Not a big
deal, just a surprise.

I don't think that really matters, and this looked good to me otherwise,
so I applied it to master.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH v6 2/2] OVN: Enable N-S Traffic, Vlan backed DVR

2019-05-07 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:
For North-South traffic, we need a chassis which will respond to
ARP requests for router port coming from outside. For this purpose,
we will reply upon gateway-chassis construct in OVN, on a logical
router port, we will associate one or more chassis as gateway chassis.

One of these chassis would be active at a point and will become
entry point to traffic, bound for end points behind logical router
coming from outside network (North to South).

This patch make some enhancements to gateway chassis implementation
to manage above used case.

A.
Do not replace router port mac with chassis mac on gateway
chassis.
This is done, because:
i. Chassisredirect port is NOT a distributed port, hence
   we need not replace its mac address
  (which same as router port mac).

   ii. ARP cache will be consistent everywhere, i.e just like
   endpoints on OVN chassis will see configured router port
   mac as resolved mac for router port ip, outside endpoints
   will see that as well.

  iii. For implementing Network Address Translation. Although
   not a part of this series. But, follow up series would
   be having this feature and approach would rely upon
   sending packets to redirect chassis using chassis redirect
   router port mac as dest mac.

B.
Advertise router port GARP on gateway chassis.
This is needed, especially if a failover happens and
chassisredirect port moves to a new gateway chassis.
Otherwise, there would be packet drops till outside
router ARPs for router port ip again.

Intention of this GARP is to update top of the rack (TOR)
to direct router port mac to new hypervisor.

Hence, we could have done the same using RARP as well, but
because ovn-controller has implementation for GARP already,
hence it did not look like worthy to add a RARP implementation
just for this.

C.
For South to North traffic, we need not pass through gateway
chassis, if there is no address transalation needed.

For overlay networks, NATing is a must to talk to outside networks.
However, for vlan backed networks, NATing is not a must, and hence
in the absence of NATing configuration we need redirect the packet
to gateway chassis.

Signed-off-by: Ankur Sharma 
---
 ovn/controller/physical.c |  24 +++-
 ovn/controller/pinctrl.c  | 205 +++
 ovn/controller/pinctrl.h  |   6 +
 ovn/lib/ovn-util.c|  31 +
 ovn/lib/ovn-util.h|   6 +
 ovn/northd/ovn-northd.c   |  43 +--
 tests/ovn.at  | 307 +-
 7 files changed, 579 insertions(+), 43 deletions(-)

diff --git a/ovn/controller/physical.c b/ovn/controller/physical.c
index d689e89..2069de1 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,9 +236,12 @@ get_zone_ids(const struct sbrec_port_binding *binding,
 }
 
 static void
-put_replace_router_port_mac_flows(const struct
+put_replace_router_port_mac_flows(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,
@@ -278,8 +282,21 @@ put_replace_router_port_mac_flows(const struct
 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_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.
@@ -792,7 +809,8 @@ consider_port_binding(struct ovsdb_idl_index 
*sbrec_port_binding_by_name,
 , ofpacts_p);
 
 if (!strcmp(binding->type,

[ovs-dev] [PATCH v6 1/2] OVN: Enable E-W Traffic, Vlan backed DVR

2019-05-07 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 3 E-W and Layer 3 N-S (NO NAT) changes for vlan
backed distributed logical router.

This patch:

A.
Key difference between an overlay logical switch and
vlan backed logical switch is that for vlan logical switches
packets are not encapsulated.

Hence, if a distributed router port is connected to vlan type
logical switch, then router port mac as source mac could be
seen from multiple hypervisors. Same  pairs coming
from multiple ports from a top of the rack switch (TOR) perspective
could be seen as a security threat and it could send alarms, drop
the packets or block the ports etc.

This patch addresses the same by introducing the concept of chassis mac.
A chassis mac is CMS provisioned unique mac per chassis. For any routed packet
(i.e source mac is router port mac) going on the wire on a vlan type
logical switch, we will replace its source mac with chassis mac.

This replacing of source mac with chassis mac will happen in table=65
of the logical switch datapath. A flow is added at priority 150, which
matches the source mac and replaces it with chassis mac if the value
is a router port mac.

Example flow:
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

Here, 00:00:01:01:02:03 is router port mac and aa:bb:cc:dd:ee:ff
is chassis mac.

B.
This patch adds one more change of associating "types" with logical
switches. i.e a logical switch could be of type "overlay" or "bridged".
This is done to explicitly call out that on a bridged logical
switch there will no encapsulation.
Just a localnet port's presence is not sufficient, as we do
encap while redirecting the packet to gateway chassis.
By marking the logical switch as bridged, we can either
avoid redirection totally (if there is no NAT) or do redirection
based on router port mac, rather than encap over a tunnel.

Signed-off-by: Ankur Sharma 
---
 ovn/controller/binding.c|  12 +--
 ovn/controller/chassis.c|  64 +++-
 ovn/controller/chassis.h|   4 +
 ovn/controller/ovn-controller.8.xml |  10 ++
 ovn/controller/ovn-controller.c |   2 +-
 ovn/controller/ovn-controller.h |   5 +-
 ovn/controller/physical.c   |  96 ++
 ovn/northd/ovn-northd.c |  38 +++
 ovn/ovn-architecture.7.xml  |  12 +++
 ovn/ovn-nb.ovsschema|  10 +-
 ovn/ovn-nb.xml  |  18 
 ovn/ovn-sb.xml  |  15 +++
 ovn/utilities/ovn-nbctl.c   |  49 +++--
 tests/ovn-nbctl.at  |  48 ++---
 tests/ovn-northd.at |  22 
 tests/ovn.at| 197 
 16 files changed, 570 insertions(+), 32 deletions(-)

diff --git a/ovn/controller/binding.c b/ovn/controller/binding.c
index 404f0e7..e9461ef 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 0f537f1..d029091 100644
--- a/ovn/controller/chassis.c
+++ b/ovn/controller/chassis.c
@@ -23,6 +23,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"
@@ -69,6 +70,12 @@ get_bridge_mappings(const struct smap *ext_ids)
 }
 
 static const char *
+get_chassis_mac_mappings(const struct smap *ext_ids)
+{
+return smap_get_def(ext_ids, "ovn-chassis-mac-mappings", "");
+}
+
+static const char *
 get_cms_options(const struct smap *ext_ids)
 {

[ovs-dev] [PATCH v6 0/2] OVN: Distributed Virtual Router for Vlan Backed Networks

2019-05-07 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 bridged.

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.

v5 -> v6

  * Handled Numan's review comments.


v4 -> v5

  * Changed the network_type value to "bridged" instead of "vlan".

v3 -> v4

  * Improved documentation and commit message.
  * Converted the patchset to 2 patches.
  * Changes in nbctl to NOT set to network_type during logical switch create.
  * Fixed 3 space indentation.

v2 -> v3
-
  * Rebased with TOT.

v1 -> v2
--
  * Fixed unit tests and review comments.

Ankur Sharma (2):
  OVN: Enable E-W Traffic, Vlan backed DVR
  OVN: Enable N-S Traffic, Vlan backed DVR

 ovn/controller/binding.c|  12 +-
 ovn/controller/chassis.c|  64 -
 ovn/controller/chassis.h|   4 +
 ovn/controller/ovn-controller.8.xml |  10 +
 ovn/controller/ovn-controller.c |   2 +-
 ovn/controller/ovn-controller.h |   5 +-
 ovn/controller/physical.c   | 114 
 ovn/controller/pinctrl.c| 205 +--
 ovn/controller/pinctrl.h|   6 +
 ovn/lib/ovn-util.c  |  31 +++
 ovn/lib/ovn-util.h  |   6 +
 ovn/northd/ovn-northd.c |  81 +-
 ovn/ovn-architecture.7.xml  |  12 +
 ovn/ovn-nb.ovsschema|  10 +-
 ovn/ovn-nb.xml  |  18 ++
 ovn/ovn-sb.xml  |  15 ++
 ovn/utilities/ovn-nbctl.c   |  49 +++-
 tests/ovn-nbctl.at  |  48 +++-
 tests/ovn-northd.at |  22 ++
 tests/ovn.at| 502 
 20 files changed, 1145 insertions(+), 71 deletions(-)

-- 
1.8.3.1

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

Re: [ovs-dev] [patch v7] conntrack: Add rcu support.

2019-05-07 Thread Ben Pfaff 
On Mon, May 06, 2019 at 09:20:53AM -0700, Darrell Ball wrote:
> For performance and code simplification reasons, add rcu support for
> conntrack. The array of hmaps is replaced by a cmap as part of this
> conversion.  Using a single map also simplifies the handling of NAT
> and allows the removal of the nat_conn map and friends.  Per connection
> entry locks are introduced, which are needed in a few code paths.
> 
> Signed-off-by: Darrell Ball 
> ---
> 
> v7: Document 'conn' locking better; not using OVS_GUARDED bcoz that
> would require several OVS_NO_THREAD_SAFETY_ANALYSIS to avoid
> clang false positive.
> 
> Use OVS_PACKED_ENUM.

Thanks!

This style of putting the comment before the ; looks odd to me:
enum icmp_state state /* 'conn' lock protected. */;
Normally I see it as:
enum icmp_state state;  /* 'conn' lock protected. */

I don't understand the following comment.  It's needed because it's
used?  That usually goes without saying.

/* Needed because of usage in CMAP_FOR_EACH. */
static void
conn_clean_one(struct conntrack *ct, struct conn *conn)

I am not confident about destruction ordering here.  It appears that
conntrack_destroy() frees 'ct'.  I don't see anything that assures that
a grace period has expired before this.  In the meantime, it seems that
packet processing could access 'ct'.  I think that the same is true for,
e.g., ct_lock.  I guess one way it could be safe if is
conntrack_destroy() requires the caller to have already quiesced packet
processing for a grace period, but that doesn't seem to be documented
and I don't think dpif-netdev does that.

I played around with the formatting for the structs and came up with the
following, which seemed clearer to me.

diff --git a/lib/conntrack-private.h b/lib/conntrack-private.h
index 7af0f9bb0357..3c49eb489b2c 100644
--- a/lib/conntrack-private.h
+++ b/lib/conntrack-private.h
@@ -92,23 +92,25 @@ struct conn {
 struct conn_key key;
 struct conn_key rev_key;
 struct conn_key master_key; /* Only used for orig_tuple support. */
-/* Guards fields that can be updated; this includes protocol specific
- * state. */
-struct ovs_mutex lock;
-long long expiration /* 'conn' lock protected. */;
+
 struct ovs_list exp_node;
 struct cmap_node cm_node;
+
+/* Immutable data. */
 ovs_u128 label;
+uint32_t mark;
 struct nat_action_info_t *nat_info;
 char *alg;
 struct conn *nat_conn; /* The NAT 'conn' context, if there is one. */
-int seq_skew /* 'conn' lock protected. */;
-uint32_t mark;
 enum ct_conn_type conn_type;
-/* TCP sequence skew direction due to NATTing of FTP control messages;
- * true if reply direction. */
-bool seq_skew_dir /* 'conn' lock protected. */;
 bool alg_related; /* True if alg data connection. */
+
+/* Mutable data. */
+struct ovs_mutex lock;  /* Guards all of the following. */
+long long expiration;
+int seq_skew;
+bool seq_skew_dir; /* TCP sequence skew direction due to NATTing of FTP
+* control messages; true if reply direction. */
 };
 
 enum ct_update_res {
@@ -153,28 +155,20 @@ struct conntrack {
 struct cmap conns OVS_GUARDED;
 struct ovs_list exp_lists[N_CT_TM] OVS_GUARDED;
 
-/* Salt for hashing a connection key. */
-uint32_t hash_basis;
-/* The thread performing periodic cleanup of the connection
- * tracker. */
-pthread_t clean_thread;
-/* Latch to destroy the 'clean_thread' */
-struct latch clean_thread_exit;
-
-/* Number of connections currently in the connection tracker. */
-atomic_count n_conn;
-/* Connections limit. When this limit is reached, no new connection
- * will be accepted. */
-atomic_uint n_conn_limit;
-
-/* This lock is used to guard alg_expectations and alg_expectation_refs.
- */
-struct ovs_rwlock resources_lock;
-/* Hash table for alg expectations. Expectations are created
- * by control connections to help create data connections. */
-struct hmap alg_expectations OVS_GUARDED;
-/* Used to lookup alg expectations from the control context. */
-struct hindex alg_expectation_refs OVS_GUARDED;
+uint32_t hash_basis;   /* Salt for hashing a connection key. */
+pthread_t clean_thread;/* Periodically cleans up connection tracker. */
+struct latch clean_thread_exit; /* To destroy the 'clean_thread'. */
+
+/* Counting connections. */
+atomic_count n_conn;/* Number of connections currently tracked. */
+atomic_uint n_conn_limit;   /* Max connections tracked. */
+
+/* Expectations for application level gateways (created by control
+ * connections to help create data connections, e.g. for FTP). */
+struct ovs_rwlock resources_lock; /* Protects fields below. */
+struct hmap alg_expectations OVS_GUARDED; /* Holds struct alg_exp_nodes. */
+struct hindex alg_expectation_refs OVS_GUARDED; /* For lookup from
+

Re: [ovs-dev] [patch v1] tests: Fix IPv4 checksums in zone limit test.

2019-05-07 Thread Ben Pfaff 
On Mon, May 06, 2019 at 02:24:58PM -0700, Yi-Hung Wei wrote:
> On Mon, May 6, 2019 at 9:48 AM Darrell Ball  wrote:
> >
> > Userspace conntrack cares about IPv4 checksums, so this is a
> > prerequisite for adding zone limit support to userspace conntrack.
> >
> > Fixes: 3f1087c70cf9 ("system-traffic: Add conntrack per zone limit test 
> > case.")
> > CC: Yi-Hung Wei 
> > Signed-off-by: Darrell Ball 
> > ---
> 
> Thanks for the fix.
> 
> Acked-by: Yi-Hung Wei 

Thanks, Darrell and Yi-Hung.   I applied this to master.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH v5 1/2] OVN: Enable E-W Traffic, Vlan backed DVR

2019-05-07 Thread Ankur Sharma 
Hi Numan,

Thank you so much for trying out the patch.
Please find my replies inline regarding your test.

For other comments in the code, i will be happy to make the change and v6 will 
have it.

Thanks

Regards,
Ankur



From: Numan Siddique 
Sent: Tuesday, May 7, 2019 10:07 AM
To: Ankur Sharma 
Cc: ovs-dev@openvswitch.org
Subject: Re: [ovs-dev] [PATCH v5 1/2] OVN: Enable E-W Traffic, Vlan backed DVR



On Fri, May 3, 2019 at 3:04 AM Ankur Sharma 
mailto:ankur.sha...@nutanix.com>> wrote:
Background:
[1] https://mail.openvswitch.org/pipermail/ovs-dev/2018-October/353066.html 
[mail.openvswitch.org]
[2] 
https://docs.google.com/document/d/1uoQH478wM1OZ16HrxzbOUvk5LvFnfNEWbkPT6Zmm9OU/edit?usp=sharing
 
[docs.google.com]

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

This patch:

A.
Key difference between an overlay logical switch and
vlan backed logical switch is that for vlan logical switches
packets are not encapsulated.

Hence, if a distributed router port is connected to vlan type
logical switch, then router port mac as source mac could be
seen from multiple hypervisors. Same  pairs coming
from multiple ports from a top of the rack switch (TOR) perspective
could be seen as a security threat and it could send alarms, drop
the packets or block the ports etc.

This patch addresses the same by introducing the concept of chassis mac.
A chassis mac is CMS provisioned unique mac per chassis. For any routed packet
(i.e source mac is router port mac) going on the wire on a vlan type
logical switch, we will replace its source mac with chassis mac.

This replacing of source mac with chassis mac will happen in table=65
of the logical switch datapath. A flow is added at priority 150, which
matches the source mac and replaces it with chassis mac if the value
is a router port mac.

Example flow:
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

Here, 00:00:01:01:02:03 is router port mac and aa:bb:cc:dd:ee:ff
is chassis mac.

B.
This patch adds one more change of associating "types" with logical
switches. i.e a logical switch could be of type "overlay" or "bridged".
This is done to explicitly call out that on a bridged logical
switch there will no encapsulation.
Just a localnet port's presence is not sufficient, as we do
encap while redirecting the packet to gateway chassis.
By marking the logical switch as bridged, we can either
avoid redirection totally (if there is no NAT) or do redirection
based on router port mac, rather than encap over a tunnel.

Hi Ankur,

I applied both the patches in the series and I tested them. For now I have only
tested E/W scenario.

I have one questions.  In my setup, I created 2 bridged logical switches - sw0 
and sw1 and attached
a router to it. I have 2 chassis - c1 and c2.
On c1 mac-bindings are configured as - sw0: c1-sw0-MAC, sw1:c1-sw1-MAC
On c2 mac-bindings are configured as - sw0: c2-sw0-MAC, sw1:c2-sw1-MAC
[ANKUR]: Sorry, a little confused here the chassis mac need not be on per 
logical switch, chassis mac should be configured on per physical bridge basis.


I have a logical port - sw0-port1 (which belongs to sw0 logical switch) with IP 
- 10.0.0.4
and another logical port - sw1-port1 (which belongs to sw1) with IP - 20.0.0.4.

sw0-port1 is bound on chassis c1 and sw1-port1 on chassis c2.

When sw0-port1 (10.0.0.4) pings sw1-port1 (20.0.0.4), the router port 
(20.0.0.1) MAC
is replaced by c1-sw1-MAC in table 65 as expected.

When sw1-port1 receives the packet it will receive the packet as -

 
---
| SRC MAC  (c1-sw1-MAC)  | SRC IP (10.0.0.4)  | DST MAC (sw1-port1 mac) | DST 
IP (20.0.0.4) |
 
---

when sw1-port1 replies for the ping, it sends the packet as -

 

| SRC MAC  (sw1-port1 MAC)  | SRC IP (20.0.0.4)  | DST MAC ( he router port 
(20.0.0.1) MAC  ) | DST IP (10.0.0.4) |

[ovs-dev] Congratulations.

2019-05-07 Thread Mr.Patrick Hermington. 





Dear Winner ,
 We are happy to inform you that your email was selected as on of 
the 5
Lucky winners of €3,500,000.00 (Three Million,five hundred thousand 
Euro)

on the just concluded EUROPEAN LOTTERY CONGRESS held in Antwerp from
26th–29th May 2019. For claims kindly provide the informations below for
verifiction purpose ;
Full Name
Address
Mobile Number
Occupation
Please be advised that your lottery winning ticket number is 
EUL145638/19 .


Regards ,

Mr.Patrick Hermington.
(patrickherming...@zoho.com)
EUROPEAN LOTTERY BOARD ANNOUNCER .
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] OVS/OVN Split initial commits are complete

2019-05-07 Thread Mark Michelson 

On 5/7/19 1:42 PM, Numan Siddique wrote:



On Sat, Apr 27, 2019 at 5:51 AM Justin Pettit > wrote:



 > On Apr 26, 2019, at 2:50 PM, Mark Michelson mailto:mmich...@redhat.com>> wrote:
 >
 > On 4/26/19 3:42 PM, Ben Pfaff wrote:
 >
 >> We need to pick a date (or a trigger) for freezing the OVN parts
of OVS.
 >> I don't know what that date should be.  Thoughts?
 >
 > I'm of the opinion that it should be ASAP. With the new repo
created, it's best for developers to start using the new repo for
their day-to-day development. Adding more commits to the OVS repo at
this point will potentially result in lost work if a maintainer
neglects to get it moved over.

I think we should continue to do development in the OVS repo until
we're certain that the approach being taken is the right one and
that we've got all the pieces in place to fully do OVN development
on its own (e.g., separate mailing list, CI/CD infrastructure,
etc).  Once we have all those pieces in place, then we should delete
the "ovn" branch from the OVS repo.  Having the place where it has
traditionally lived continue on in a zombie state will be confusing,
and possibly problematic if we decide the path we're currently going
down is wrong for some reason.  Those concerns combined with your
imminent paternity lean me towards waiting.

Let's see how things go for the next couple months, and then revisit
if it's time to stop development in the "ovn" branch.  If it goes as
I expect, I'll enthusiastically support that change.


Till we have every thing in place and remove "ovn" folder from the ovs 
repo, the ovn-org/ovn repo would be out of sync w.r.t to OVN related 
patches.
So is it fine if we apply the OVN related patches to the new repo once 
the patch is merged in ovs repo ? If in case we agree to apply these 
patches, will there be any mismatch in

the history ? (like commit id being different).
Or lets sync the ovn-org/ovn repo when we decide to make it official.

Any thoughts ?


What methods exist for syncing the commits in one go? And would such a 
method also preserve commit ids and other history? If it's not too hard 
to perform this, then it's probably the best way to go. I think doing 
everything in one big change is easier than trying to do a bunch of 
small changes as needed.




Thanks
Numan



Thanks,

--Justin




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

[ovs-dev] Logre la motivación de sus empleados

2019-05-07 Thread Salario emocional 
Cursos Esenciales - Webinar Interactivo – Miércoles 19 de Junio

Salario emocional y otras estrategias de Compensación al personal

El salario emocional juega un papel importante en la motivación e implicación 
de la persona respecto a la organización. 
Garantizar el compromiso y permanencia en la empresa, haciendo una adecuada 
gestión del talento, depende del salario emocional.

Objetivos específicos:

• El participante revisará los conceptos básicos relacionados con el salario 
emocional y las estrategias de compensación.
• El participante aprenderá a realizar el plan de acción de un programa 
empresarial basado en el reconocimiento.
• El participante revisará modelos de empresa con políticas eficaces de 
reconocimiento basadas en el salario emocional.

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

NOMBRE:

TELÉFONO:

EMPRESA:

EMAIL ALTERNO: 

Llamanos al (045) 55 1554 6630
www.Innovalearn.mx  

 



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

Re: [ovs-dev] OVS/OVN Split initial commits are complete

2019-05-07 Thread Numan Siddique 
On Sat, Apr 27, 2019 at 5:51 AM Justin Pettit  wrote:

>
> > On Apr 26, 2019, at 2:50 PM, Mark Michelson  wrote:
> >
> > On 4/26/19 3:42 PM, Ben Pfaff wrote:
> >
> >> We need to pick a date (or a trigger) for freezing the OVN parts of OVS.
> >> I don't know what that date should be.  Thoughts?
> >
> > I'm of the opinion that it should be ASAP. With the new repo created,
> it's best for developers to start using the new repo for their day-to-day
> development. Adding more commits to the OVS repo at this point will
> potentially result in lost work if a maintainer neglects to get it moved
> over.
>
> I think we should continue to do development in the OVS repo until we're
> certain that the approach being taken is the right one and that we've got
> all the pieces in place to fully do OVN development on its own (e.g.,
> separate mailing list, CI/CD infrastructure, etc).  Once we have all those
> pieces in place, then we should delete the "ovn" branch from the OVS repo.
> Having the place where it has traditionally lived continue on in a zombie
> state will be confusing, and possibly problematic if we decide the path
> we're currently going down is wrong for some reason.  Those concerns
> combined with your imminent paternity lean me towards waiting.
>
> Let's see how things go for the next couple months, and then revisit if
> it's time to stop development in the "ovn" branch.  If it goes as I expect,
> I'll enthusiastically support that change.
>

Till we have every thing in place and remove "ovn" folder from the ovs
repo, the ovn-org/ovn repo would be out of sync w.r.t to OVN related
patches.
So is it fine if we apply the OVN related patches to the new repo once the
patch is merged in ovs repo ? If in case we agree to apply these patches,
will there be any mismatch in
the history ? (like commit id being different).
Or lets sync the ovn-org/ovn repo when we decide to make it official.

Any thoughts ?

Thanks
Numan




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

Re: [ovs-dev] [PATCH v5 1/2] OVN: Enable E-W Traffic, Vlan backed DVR

2019-05-07 Thread Numan Siddique 
On Fri, May 3, 2019 at 3:04 AM Ankur Sharma 
wrote:

> 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 3 E-W and Layer 3 N-S (NO NAT) changes for vlan
> backed distributed logical router.
>
> This patch:
>
> A.
> Key difference between an overlay logical switch and
> vlan backed logical switch is that for vlan logical switches
> packets are not encapsulated.
>
> Hence, if a distributed router port is connected to vlan type
> logical switch, then router port mac as source mac could be
> seen from multiple hypervisors. Same  pairs coming
> from multiple ports from a top of the rack switch (TOR) perspective
> could be seen as a security threat and it could send alarms, drop
> the packets or block the ports etc.
>
> This patch addresses the same by introducing the concept of chassis mac.
> A chassis mac is CMS provisioned unique mac per chassis. For any routed
> packet
> (i.e source mac is router port mac) going on the wire on a vlan type
> logical switch, we will replace its source mac with chassis mac.
>
> This replacing of source mac with chassis mac will happen in table=65
> of the logical switch datapath. A flow is added at priority 150, which
> matches the source mac and replaces it with chassis mac if the value
> is a router port mac.
>
> Example flow:
> 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
>
> Here, 00:00:01:01:02:03 is router port mac and aa:bb:cc:dd:ee:ff
> is chassis mac.
>
> B.
> This patch adds one more change of associating "types" with logical
> switches. i.e a logical switch could be of type "overlay" or "bridged".
> This is done to explicitly call out that on a bridged logical
> switch there will no encapsulation.
> Just a localnet port's presence is not sufficient, as we do
> encap while redirecting the packet to gateway chassis.
> By marking the logical switch as bridged, we can either
> avoid redirection totally (if there is no NAT) or do redirection
> based on router port mac, rather than encap over a tunnel.
>
>
Hi Ankur,

I applied both the patches in the series and I tested them. For now I have
only
tested E/W scenario.

I have one questions.  In my setup, I created 2 bridged logical switches -
sw0 and sw1 and attached
a router to it. I have 2 chassis - c1 and c2.
On c1 mac-bindings are configured as - sw0: c1-sw0-MAC, sw1:c1-sw1-MAC
On c2 mac-bindings are configured as - sw0: c2-sw0-MAC, sw1:c2-sw1-MAC

I have a logical port - sw0-port1 (which belongs to sw0 logical switch)
with IP - 10.0.0.4
and another logical port - sw1-port1 (which belongs to sw1) with IP -
20.0.0.4.

sw0-port1 is bound on chassis c1 and sw1-port1 on chassis c2.

When sw0-port1 (10.0.0.4) pings sw1-port1 (20.0.0.4), the router port
(20.0.0.1) MAC
is replaced by c1-sw1-MAC in table 65 as expected.

When sw1-port1 receives the packet it will receive the packet as -

 
---
| SRC MAC  (c1-sw1-MAC)  | SRC IP (10.0.0.4)  | DST MAC (sw1-port1 mac) |
DST IP (20.0.0.4) |
 
---


when sw1-port1 replies for the ping, it sends the packet as -

 

| SRC MAC  (sw1-port1 MAC)  | SRC IP (20.0.0.4)  | DST MAC ( he router port
(20.0.0.1) MAC  ) | DST IP (10.0.0.4) |
 


I observed for the packets on the sw1-port1 interface on c2.

When ovn-controller delivers the packet to sw1-port1, shouldn't it replace
the c1-sw1-MAC with the router port (20.0.0.1) MAC  ?
Or it's fine ?

Few comments inline

Thanks
Numan



> Signed-off-by: Ankur Sharma 
> ---
>  ovn/controller/binding.c|  12 +--
>  ovn/controller/chassis.c|  66 +++-
>  ovn/controller/chassis.h|   4 +
>  ovn/controller/ovn-controller.8.xml |  10 ++
>  ovn/controller/ovn-controller.c |   2 +-
>  ovn/controller/ovn-controller.h |   5 +-
>  ovn/controller/physical.c   |  96 ++
>  ovn/northd/ovn-northd.c |  38 +++
>  ovn/ovn-architecture.7.xml  |  12 +++
>  ovn/ovn-nb.ovsschema|  10 +-
>  ovn/ovn-nb.xml  |  18 
>  ovn/ovn-sb.xml  |  15 +++
>  ovn/utilities/ovn-nbctl.c   |  49 +++--
>  tests/ovn-nbctl.at

Re: [ovs-dev] [RFC 0/5] Quicker pmd threads reloads

2019-05-07 Thread David Marchand 
Hello Ilya,

Thanks for looking at this series.

On Mon, May 6, 2019 at 5:22 PM Ilya Maximets  wrote:

> On 30.04.2019 15:17, David Marchand wrote:
> > We have been testing the rebalance code in different situations while
> > having traffic going through OVS.
> > Those tests have shown that part of the observed packets losses is due to
> > some time wasted in signaling/waiting for the pmd threads to reload their
> > polling configurations.
> >
> > This RFC series is an attempt at getting pmd threads reloads quicker and
> > more deterministic.
> >
>
> Do you have some performance data to share?
>

During our testing of rebalance, we were tracking packets losses with
traffic running during a rebalance.

I focused on the cycles spent in the transition between two polling
configurations.
I triggered 1000 rebalances on each patch of this series, with rte_rdtsc()
probes in reconfigure_datapath() / pmd_thread_main().
Between the moment we stop polling in a pmd for a given configuration and
the moment we start polling again in the new configuration:
- before the patches, a pmd would spend 140k/330k/3 000k cycles
(minimum/average/maximum).
- after the patches, a pmd would spend 13k/20k/43k cycles.

Originally, the numbers are highly volatile: I got a 20 000k cycles in a
previous test run (which translated to 28k lost packets with the ofrules I
had).


I had a look at your comments, I will come with the fixes later this week
(tomorrow is off in France).

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

[ovs-dev] Detecte los puntos de vulnerabilidad

2019-05-07 Thread Seguridad y vigilancia 
Cursos TOP - Webinar Interactivo – Miércoles 13 de Junio

Guía de seguridad y vigilancia en centros de trabajo 

La prevención de riesgos laborales establece directrices concretas, para que 
las empresas conformen un sistema preventivo eficaz e integrado 
en sus procesos productivos y a la actividad diaria laboral, garantizando así 
la integridad física y moral de los trabajadores y las instalaciones. 

El participante conocerá, identificara y será capaz de prevenir incidencias y 
riesgos, así como administrar los puntos de vulnerabilidad que 
puedan ocasionar riesgos en su centro de trabajo. 

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


NOMBRE:
TELÉFONO:
EMPRESA:
EMAIL ALTERNO: 

Llamanos al (045) 55 1554 6630
www.Innovalearn.mx
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [RFC 2/5] dpif-netdev: Trigger parallel pmd reloads.

2019-05-07 Thread Ilya Maximets 
On 07.05.2019 16:46, Eelco Chaudron wrote:
> 
> 
> On 30 Apr 2019, at 14:17, David Marchand wrote:
> 
>> pmd reloads are currently serialised in each steps calling
>> reload_affected_pmds.
>> Any pmd processing packets, waiting on a mutex etc... will make other
>> pmd threads wait for a delay that can be undeterministic when syscalls
>> adds up.
>>
>> Switch to a little busy loop on the control thread using an atomic
>> count.
>>
>> Signed-off-by: David Marchand 
>> ---
>>  lib/dpif-netdev.c | 43 ++-
>>  1 file changed, 30 insertions(+), 13 deletions(-)
>>
>> diff --git a/lib/dpif-netdev.c b/lib/dpif-netdev.c
>> index 30774ed..b2b21fd 100644
>> --- a/lib/dpif-netdev.c
>> +++ b/lib/dpif-netdev.c
>> @@ -335,6 +335,9 @@ struct dp_netdev {
>>  /* The time that a packet can wait in output batch for sending. */
>>  atomic_uint32_t tx_flush_interval;
>>
>> +    /* Count of pmds currently reloading */
>> +    atomic_count reloading_pmds;
>> +
>>  /* Meters. */
>>  struct ovs_mutex meter_locks[N_METER_LOCKS];
>>  struct dp_meter *meters[MAX_METERS]; /* Meter bands. */
>> @@ -647,9 +650,6 @@ struct dp_netdev_pmd_thread {
>>  struct ovs_refcount ref_cnt;    /* Every reference must be refcount'ed. 
>> */
>>  struct cmap_node node;  /* In 'dp->poll_threads'. */
>>
>> -    pthread_cond_t cond;    /* For synchronizing pmd thread reload. 
>> */
>> -    struct ovs_mutex cond_mutex;    /* Mutex for condition variable. */
>> -
>>  /* Per thread exact-match cache.  Note, the instance for cpu core
>>   * NON_PMD_CORE_ID can be accessed by multiple threads, and thusly
>>   * need to be protected by 'non_pmd_mutex'.  Every other instance
>> @@ -1525,6 +1525,8 @@ create_dp_netdev(const char *name, const struct 
>> dpif_class *class,
>>  atomic_init(>emc_insert_min, DEFAULT_EM_FLOW_INSERT_MIN);
>>  atomic_init(>tx_flush_interval, DEFAULT_TX_FLUSH_INTERVAL);
>>
>> +    atomic_count_init(>reloading_pmds, 0);
>> +
>>  cmap_init(>poll_threads);
>>  dp->pmd_rxq_assign_cyc = true;
>>
>> @@ -1754,11 +1756,8 @@ dp_netdev_reload_pmd__(struct dp_netdev_pmd_thread 
>> *pmd)
>>  return;
>>  }
>>
>> -    ovs_mutex_lock(>cond_mutex);
>>  seq_change(pmd->reload_seq);
>>  atomic_store_relaxed(>reload, true);
>> -    ovs_mutex_cond_wait(>cond, >cond_mutex);
>> -    ovs_mutex_unlock(>cond_mutex);
>>  }
>>
>>  static uint32_t
>> @@ -4641,9 +4640,27 @@ rxq_scheduling(struct dp_netdev *dp, bool pinned) 
>> OVS_REQUIRES(dp->port_mutex)
>>  }
>>
>>  static void
>> +wait_reloading_pmds(struct dp_netdev *dp)
>> +{
>> +    while (atomic_count_get(>reloading_pmds) != 0) {
>> +    }
>> +}
>> +
>> +static void
>>  reload_affected_pmds(struct dp_netdev *dp)
>>  {
>>  struct dp_netdev_pmd_thread *pmd;
>> +    unsigned int pmd_count = 0;
>> +
>> +    CMAP_FOR_EACH (pmd, node, >poll_threads) {
>> +    if (pmd->core_id == NON_PMD_CORE_ID) {
>> +    continue;
>> +    }
>> +    if (pmd->need_reload) {
>> +    pmd_count++;
>> +    }
>> +    }
>> +    atomic_count_set(>reloading_pmds, pmd_count);
>>  CMAP_FOR_EACH (pmd, node, >poll_threads) {
>>  if (pmd->need_reload) {
>> @@ -4652,6 +4669,10 @@ reload_affected_pmds(struct dp_netdev *dp)
> 
> The above atomic_count_set() is a relaxed set, so is the 
> atomic_store_relaxed(>reload, true) in dp_netdev_reload_pmd__(pmd).
> Which could lead to the PMDs decreasing the dp->reloading_pmd before it’s 
> set. Guess if the correct memory_order is selected for pmd->reload as 
> suggested by Ilya in patch 1/5 it should work.

relaxed memory ordering does not imply any synchronization and will
not be synchronized with 'reload' regardless of its memory ordering.
To guarantee the order, atomic_count_set() must be replaced with
non-relaxed version along with 'reload'.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [RFC 3/5] dpif-netdev: Do not sleep when swapping queues.

2019-05-07 Thread Eelco Chaudron 
This patch look fine to me assuming Ilya’s comments in patch 1 are 
taking care of.


Acked-by: Eelco Chaudron 

On 30 Apr 2019, at 14:18, David Marchand wrote:

When swapping queues from a pmd thread to another (q0 polled by 
pmd0/q1

polled by pmd1 -> q1 polled by pmd0/q0 polled by pmd1), the current
"Step 5" puts both pmds to sleep waiting for the control thread to 
wake

them up later.

Prefer to make them spin in such a case to avoid sleeping an
undeterministic amount of time.

Signed-off-by: David Marchand 
---
 lib/dpif-netdev.c | 47 
++-

 1 file changed, 42 insertions(+), 5 deletions(-)

diff --git a/lib/dpif-netdev.c b/lib/dpif-netdev.c
index b2b21fd..d67cdb5 100644
--- a/lib/dpif-netdev.c
+++ b/lib/dpif-netdev.c
@@ -684,6 +684,7 @@ struct dp_netdev_pmd_thread {
 struct seq *reload_seq;
 uint64_t last_reload_seq;
 atomic_bool reload; /* Do we need to reload ports? */
+atomic_bool wait_for_reload;/* Can we busy wait for the next 
reload? */
 atomic_bool exit;   /* For terminating the pmd 
thread. */

 pthread_t thread;
 unsigned core_id;   /* CPU core id of this pmd 
thread. */

@@ -4893,6 +4894,33 @@ reconfigure_datapath(struct dp_netdev *dp)
 HMAP_FOR_EACH_SAFE (poll, poll_next, node, >poll_list) {
 if (poll->rxq->pmd != pmd) {
 dp_netdev_del_rxq_from_pmd(pmd, poll);
+
+/* This pmd might sleep after this step reload if it 
has no
+ * rxq remaining. Can we tell it to busy wait for new 
rxq at

+ * Step 6 ? */
+if (hmap_count(>poll_list) == 0) {
+HMAP_FOR_EACH (port, node, >ports) {
+int qid;
+
+if (!netdev_is_pmd(port->netdev)) {
+continue;
+}
+
+for (qid = 0; qid < port->n_rxq; qid++) {
+struct dp_netdev_rxq *q = 
>rxqs[qid];

+
+if (q->pmd == pmd) {
+
atomic_store_relaxed(>pmd->wait_for_reload,

+ true);
+break;
+}
+}
+
+if (qid != port->n_rxq) {
+break;
+}
+}
+}
 }
 }
 ovs_mutex_unlock(>port_mutex);
@@ -5410,7 +5438,9 @@ pmd_thread_main(void *f_)
 struct pmd_perf_stats *s = >perf_stats;
 unsigned int lc = 0;
 struct polled_queue *poll_list;
+bool wait_for_reload = false;
 bool exiting;
+bool reload;
 int poll_cnt;
 int i;
 int process_packets = 0;
@@ -5438,9 +5468,16 @@ reload:
 }

 if (!poll_cnt) {
-while (seq_read(pmd->reload_seq) == pmd->last_reload_seq) {
-seq_wait(pmd->reload_seq, pmd->last_reload_seq);
-poll_block();
+/* Don't sleep, control thread will ask for a reload shortly. 
*/

+if (wait_for_reload) {
+do {
+atomic_read_relaxed(>reload, );
+} while (!reload);
+} else {
+while (seq_read(pmd->reload_seq) == pmd->last_reload_seq) 
{

+seq_wait(pmd->reload_seq, pmd->last_reload_seq);
+poll_block();
+}
 }
 lc = UINT_MAX;
 }
@@ -5479,8 +5516,6 @@ reload:
 }

 if (lc++ > 1024) {
-bool reload;
-
 lc = 0;

 coverage_try_clear();
@@ -5500,6 +5535,7 @@ reload:
 ovs_mutex_unlock(>perf_stats.stats_mutex);

 poll_cnt = pmd_load_queues_and_ports(pmd, _list);
+atomic_read_relaxed(>wait_for_reload, _for_reload);
 atomic_read_relaxed(>exit, );
 /* Signal here to make sure the pmd finishes
  * reloading the updated configuration. */
@@ -5834,6 +5870,7 @@ dpif_netdev_enable_upcall(struct dpif *dpif)
 static void
 dp_netdev_pmd_reload_done(struct dp_netdev_pmd_thread *pmd)
 {
+atomic_store_relaxed(>wait_for_reload, false);
 atomic_store_relaxed(>reload, false);
 pmd->last_reload_seq = seq_read(pmd->reload_seq);
 atomic_count_dec(>dp->reloading_pmds);
--
1.8.3.1

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

Re: [ovs-dev] [RFC 2/5] dpif-netdev: Trigger parallel pmd reloads.

2019-05-07 Thread Eelco Chaudron 



On 30 Apr 2019, at 14:17, David Marchand wrote:


pmd reloads are currently serialised in each steps calling
reload_affected_pmds.
Any pmd processing packets, waiting on a mutex etc... will make other
pmd threads wait for a delay that can be undeterministic when syscalls
adds up.

Switch to a little busy loop on the control thread using an atomic
count.

Signed-off-by: David Marchand 
---
 lib/dpif-netdev.c | 43 ++-
 1 file changed, 30 insertions(+), 13 deletions(-)

diff --git a/lib/dpif-netdev.c b/lib/dpif-netdev.c
index 30774ed..b2b21fd 100644
--- a/lib/dpif-netdev.c
+++ b/lib/dpif-netdev.c
@@ -335,6 +335,9 @@ struct dp_netdev {
 /* The time that a packet can wait in output batch for sending. 
*/

 atomic_uint32_t tx_flush_interval;

+/* Count of pmds currently reloading */
+atomic_count reloading_pmds;
+
 /* Meters. */
 struct ovs_mutex meter_locks[N_METER_LOCKS];
 struct dp_meter *meters[MAX_METERS]; /* Meter bands. */
@@ -647,9 +650,6 @@ struct dp_netdev_pmd_thread {
 struct ovs_refcount ref_cnt;/* Every reference must be 
refcount'ed. */

 struct cmap_node node;  /* In 'dp->poll_threads'. */

-pthread_cond_t cond;/* For synchronizing pmd thread 
reload. */
-struct ovs_mutex cond_mutex;/* Mutex for condition variable. 
*/

-
 /* Per thread exact-match cache.  Note, the instance for cpu core
  * NON_PMD_CORE_ID can be accessed by multiple threads, and 
thusly

  * need to be protected by 'non_pmd_mutex'.  Every other instance
@@ -1525,6 +1525,8 @@ create_dp_netdev(const char *name, const struct 
dpif_class *class,

 atomic_init(>emc_insert_min, DEFAULT_EM_FLOW_INSERT_MIN);
 atomic_init(>tx_flush_interval, DEFAULT_TX_FLUSH_INTERVAL);

+atomic_count_init(>reloading_pmds, 0);
+
 cmap_init(>poll_threads);
 dp->pmd_rxq_assign_cyc = true;

@@ -1754,11 +1756,8 @@ dp_netdev_reload_pmd__(struct 
dp_netdev_pmd_thread *pmd)

 return;
 }

-ovs_mutex_lock(>cond_mutex);
 seq_change(pmd->reload_seq);
 atomic_store_relaxed(>reload, true);
-ovs_mutex_cond_wait(>cond, >cond_mutex);
-ovs_mutex_unlock(>cond_mutex);
 }

 static uint32_t
@@ -4641,9 +4640,27 @@ rxq_scheduling(struct dp_netdev *dp, bool 
pinned) OVS_REQUIRES(dp->port_mutex)

 }

 static void
+wait_reloading_pmds(struct dp_netdev *dp)
+{
+while (atomic_count_get(>reloading_pmds) != 0) {
+}
+}
+
+static void
 reload_affected_pmds(struct dp_netdev *dp)
 {
 struct dp_netdev_pmd_thread *pmd;
+unsigned int pmd_count = 0;
+
+CMAP_FOR_EACH (pmd, node, >poll_threads) {
+if (pmd->core_id == NON_PMD_CORE_ID) {
+continue;
+}
+if (pmd->need_reload) {
+pmd_count++;
+}
+}
+atomic_count_set(>reloading_pmds, pmd_count);
 CMAP_FOR_EACH (pmd, node, >poll_threads) {
 if (pmd->need_reload) {
@@ -4652,6 +4669,10 @@ reload_affected_pmds(struct dp_netdev *dp)


The above atomic_count_set() is a relaxed set, so is the 
atomic_store_relaxed(>reload, true) in dp_netdev_reload_pmd__(pmd).
Which could lead to the PMDs decreasing the dp->reloading_pmd before 
it’s set. Guess if the correct memory_order is selected for 
pmd->reload as suggested by Ilya in patch 1/5 it should work.



 pmd->need_reload = false;
 }
 }
+
+if (pmd_count != 0) {
+wait_reloading_pmds(dp);
+}
 }

 static void
@@ -5813,11 +5834,9 @@ dpif_netdev_enable_upcall(struct dpif *dpif)
 static void
 dp_netdev_pmd_reload_done(struct dp_netdev_pmd_thread *pmd)
 {
-ovs_mutex_lock(>cond_mutex);
 atomic_store_relaxed(>reload, false);
 pmd->last_reload_seq = seq_read(pmd->reload_seq);
-xpthread_cond_signal(>cond);
-ovs_mutex_unlock(>cond_mutex);
+atomic_count_dec(>dp->reloading_pmds);
 }

 /* Finds and refs the dp_netdev_pmd_thread on core 'core_id'.  
Returns
@@ -5902,8 +5921,6 @@ dp_netdev_configure_pmd(struct 
dp_netdev_pmd_thread *pmd, struct dp_netdev *dp,

 pmd->reload_seq = seq_create();
 pmd->last_reload_seq = seq_read(pmd->reload_seq);
 atomic_init(>reload, false);
-xpthread_cond_init(>cond, NULL);
-ovs_mutex_init(>cond_mutex);
 ovs_mutex_init(>flow_mutex);
 ovs_mutex_init(>port_mutex);
 cmap_init(>flow_table);
@@ -5946,8 +5963,6 @@ dp_netdev_destroy_pmd(struct 
dp_netdev_pmd_thread *pmd)

 cmap_destroy(>flow_table);
 ovs_mutex_destroy(>flow_mutex);
 seq_destroy(pmd->reload_seq);
-xpthread_cond_destroy(>cond);
-ovs_mutex_destroy(>cond_mutex);
 ovs_mutex_destroy(>port_mutex);
 free(pmd);
 }
@@ -5967,7 +5982,9 @@ dp_netdev_del_pmd(struct dp_netdev *dp, struct 
dp_netdev_pmd_thread *pmd)

 ovs_mutex_unlock(>non_pmd_mutex);
 } else {
 atomic_store_relaxed(>exit, true);
+atomic_count_set(>reloading_pmds, 1);
 dp_netdev_reload_pmd__(pmd);
+wait_reloading_pmds(dp);

[ovs-dev] [PATCH] OVN: fix pinctrl ip buffering for gw router port

2019-05-07 Thread Lorenzo Bianconi 
Use sb mac binding table to trigger ip buffer dequeueing instead of
the APR/ND packet reception since the ARP reply can be managed on a
different chassis if a gw router port is scheduled on a different
node

Signed-off-by: Lorenzo Bianconi 
---
 ovn/controller/pinctrl.c | 113 +++
 tests/ovn.at |  11 ++--
 2 files changed, 72 insertions(+), 52 deletions(-)

diff --git a/ovn/controller/pinctrl.c b/ovn/controller/pinctrl.c
index 2ae79cfd4..4f1991d29 100644
--- a/ovn/controller/pinctrl.c
+++ b/ovn/controller/pinctrl.c
@@ -149,6 +149,11 @@ static struct pinctrl pinctrl;
 
 static void init_buffered_packets_map(void);
 static void destroy_buffered_packets_map(void);
+static void
+run_buffered_binding(struct ovsdb_idl_index *sbrec_port_binding_by_datapath,
+ struct ovsdb_idl_index *sbrec_mac_binding_by_lport_ip,
+ const struct hmap *local_datapaths)
+OVS_REQUIRES(pinctrl_mutex);
 
 static void pinctrl_handle_put_mac_binding(const struct flow *md,
const struct flow *headers,
@@ -164,8 +169,6 @@ static void run_put_mac_bindings(
 OVS_REQUIRES(pinctrl_mutex);
 static void wait_put_mac_bindings(struct ovsdb_idl_txn *ovnsb_idl_txn);
 static void flush_put_mac_bindings(void);
-static void buffer_put_mac_bindings(void);
-static void destroy_buffered_mac_bindings(void);
 static void send_mac_binding_buffered_pkts(struct rconn *swconn)
 OVS_REQUIRES(pinctrl_mutex);
 
@@ -321,6 +324,7 @@ struct buffered_packets {
 
 /* key */
 struct in6_addr ip;
+struct eth_addr ea;
 
 long long int timestamp;
 
@@ -329,15 +333,17 @@ struct buffered_packets {
 };
 
 static struct hmap buffered_packets_map;
+static struct hmap buffered_mac_bindings;
 
 static void
 init_buffered_packets_map(void)
 {
 hmap_init(_packets_map);
+hmap_init(_mac_bindings);
 }
 
 static void
-destroy_buffered_packets(struct buffered_packets *bp)
+destroy_buffered_packets(struct buffered_packets *bp, struct hmap *map)
 {
 struct buffer_info *bi;
 
@@ -348,7 +354,7 @@ destroy_buffered_packets(struct buffered_packets *bp)
 
 bp->head = (bp->head + 1) % BUFFER_QUEUE_DEPTH;
 }
-hmap_remove(_packets_map, >hmap_node);
+hmap_remove(map, >hmap_node);
 free(bp);
 }
 
@@ -357,9 +363,14 @@ destroy_buffered_packets_map(void)
 {
 struct buffered_packets *bp, *next;
 HMAP_FOR_EACH_SAFE (bp, next, hmap_node, _packets_map) {
-destroy_buffered_packets(bp);
+destroy_buffered_packets(bp, _packets_map);
 }
 hmap_destroy(_packets_map);
+
+HMAP_FOR_EACH_SAFE (bp, next, hmap_node, _mac_bindings) {
+destroy_buffered_packets(bp, _mac_bindings);
+}
+hmap_destroy(_mac_bindings);
 }
 
 static void
@@ -426,7 +437,7 @@ buffered_packets_map_gc(void)
 
 HMAP_FOR_EACH_SAFE (cur_qp, next_qp, hmap_node, _packets_map) {
 if (now > cur_qp->timestamp + BUFFER_MAP_TIMEOUT) {
-destroy_buffered_packets(cur_qp);
+destroy_buffered_packets(cur_qp, _packets_map);
 }
 }
 }
@@ -1851,7 +1862,6 @@ pinctrl_handler(void *arg_)
 }
 }
 
-buffered_packets_map_gc();
 rconn_run_wait(swconn);
 rconn_recv_wait(swconn);
 send_garp_wait(send_garp_time);
@@ -1903,6 +1913,9 @@ pinctrl_run(struct ovsdb_idl_txn *ovnsb_idl_txn,
 prepare_ipv6_ras(sbrec_port_binding_by_datapath,
  sbrec_port_binding_by_name, local_datapaths);
 sync_dns_cache(dns_table);
+run_buffered_binding(sbrec_port_binding_by_datapath,
+ sbrec_mac_binding_by_lport_ip,
+ local_datapaths);
 ovs_mutex_unlock(_mutex);
 }
 
@@ -2249,7 +2262,6 @@ pinctrl_destroy(void)
 destroy_ipv6_ras();
 destroy_buffered_packets_map();
 destroy_put_mac_bindings();
-destroy_buffered_mac_bindings();
 destroy_dns_cache();
 seq_destroy(pinctrl_main_seq);
 seq_destroy(pinctrl_handler_seq);
@@ -2283,13 +2295,11 @@ struct put_mac_binding {
 
 /* Contains "struct put_mac_binding"s. */
 static struct hmap put_mac_bindings;
-static struct hmap buffered_mac_bindings;
 
 static void
 init_put_mac_bindings(void)
 {
 hmap_init(_mac_bindings);
-hmap_init(_mac_bindings);
 }
 
 static void
@@ -2299,17 +2309,6 @@ destroy_put_mac_bindings(void)
 hmap_destroy(_mac_bindings);
 }
 
-static void
-destroy_buffered_mac_bindings(void)
-{
-struct put_mac_binding *pmb;
-HMAP_FOR_EACH_POP (pmb, hmap_node, _mac_bindings) {
-   free(pmb);
-}
-
-hmap_destroy(_mac_bindings);
-}
-
 static struct put_mac_binding *
 pinctrl_find_put_mac_binding(uint32_t dp_key, uint32_t port_key,
  const struct in6_addr *ip_key, uint32_t hash)
@@ -2372,17 +2371,10 @@ static void
 send_mac_binding_buffered_pkts(struct rconn *swconn)
 OVS_REQUIRES(pinctrl_mutex)
 {
-struct put_mac_binding *pmb;
 struct

[ovs-dev] [PATCH v3 0/3] netdev: Dynamic per-port Flow API + Offload Split Up.

2019-05-07 Thread Ilya Maximets 
This is the combined patch-set for dynamic flow API along with
the further work about splitting up netdev offloading from the
generic netdev related code and making different netdev flow
offloading implementations more or less consistent.

Version 3:
  * Fixed uninitialized 'error' in provider register function.
  * Fixed opposite bahaviour of .init_flow_api for dpdk due
to wrong bool to int conversion.
  * Sanity checked with all 3 available offload providers:
dummy, tc and dpdk.

Version 2:
  * No functional changes.
  * Patches combined in a single patch-set.
  * Fixed non-alphabetical order of files in mk file.
  * Added Acks from Ben.

For patch #1 since RFC:
  * Fixed sparce build.
  * Some logs turned from INFO to DBG.
  * Enabled HW offloading on non-Linux systems
(For testing with dummy provider).


Ilya Maximets (3):
  netdev: Dynamic per-port Flow API.
  netdev: Split up netdev offloading to separate module.
  netdev-offload: Rename offload providers.

 lib/automake.mk   |   9 +-
 lib/dpdk.c|   2 +
 lib/dpif-netdev.c |   1 +
 lib/dpif-netlink.c|   1 +
 lib/netdev-dpdk.c |  25 +-
 lib/netdev-dpdk.h |   3 +
 lib/netdev-dummy.c|  24 +-
 lib/netdev-linux.c|   3 -
 lib/netdev-linux.h|  10 -
 ...v-rte-offloads.c => netdev-offload-dpdk.c} |  56 +-
 lib/netdev-offload-provider.h | 105 +++
 ...tdev-tc-offloads.c => netdev-offload-tc.c} |  42 +-
 lib/netdev-offload.c  | 658 ++
 lib/netdev-offload.h  | 126 
 lib/netdev-provider.h |  88 +--
 lib/netdev-rte-offloads.h |  57 --
 lib/netdev-tc-offloads.h  |  44 --
 lib/netdev-vport.c|   6 +-
 lib/netdev.c  | 465 +
 lib/netdev.h  |  57 --
 tests/dpif-netdev.at  |   4 +-
 tests/ofproto-macros.at   |   1 -
 vswitchd/bridge.c |   1 +
 23 files changed, 1026 insertions(+), 762 deletions(-)
 rename lib/{netdev-rte-offloads.c => netdev-offload-dpdk.c} (93%)
 create mode 100644 lib/netdev-offload-provider.h
 rename lib/{netdev-tc-offloads.c => netdev-offload-tc.c} (98%)
 create mode 100644 lib/netdev-offload.c
 create mode 100644 lib/netdev-offload.h
 delete mode 100644 lib/netdev-rte-offloads.h
 delete mode 100644 lib/netdev-tc-offloads.h

-- 
2.17.1

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

[ovs-dev] [PATCH v3 3/3] netdev-offload: Rename offload providers.

2019-05-07 Thread Ilya Maximets 
Flow API providers renamed to be consistent with parent module
'netdev-offload' and look more like each other.

'_rte_' replaced with more convenient '_dpdk_'.

We'll have following structure:

  Common code:
lib/netdev-offload-provider.h
lib/netdev-offload.c
lib/netdev-offload.h

  Providers:
lib/netdev-offload-tc.c
lib/netdev-offload-dpdk.c

'netdev-offload-dummy' still resides inside netdev-dummy, but it
makes no much sence to move it out of there.

Signed-off-by: Ilya Maximets 
Acked-by: Ben Pfaff 
---
 lib/automake.mk   |  4 +--
 lib/dpdk.c|  2 +-
 lib/netdev-dummy.c|  4 +--
 ...v-rte-offloads.c => netdev-offload-dpdk.c} | 30 +--
 lib/netdev-offload-provider.h |  4 +--
 ...tdev-tc-offloads.c => netdev-offload-tc.c} |  5 ++--
 lib/netdev.c  |  2 +-
 7 files changed, 25 insertions(+), 26 deletions(-)
 rename lib/{netdev-rte-offloads.c => netdev-offload-dpdk.c} (96%)
 rename lib/{netdev-tc-offloads.c => netdev-offload-tc.c} (99%)

diff --git a/lib/automake.mk b/lib/automake.mk
index b2d90da4e..27bc376c0 100644
--- a/lib/automake.mk
+++ b/lib/automake.mk
@@ -394,7 +394,7 @@ lib_libopenvswitch_la_SOURCES += \
lib/if-notifier.h \
lib/netdev-linux.c \
lib/netdev-linux.h \
-   lib/netdev-tc-offloads.c \
+   lib/netdev-offload-tc.c \
lib/netlink-conntrack.c \
lib/netlink-conntrack.h \
lib/netlink-notifier.c \
@@ -414,7 +414,7 @@ if DPDK_NETDEV
 lib_libopenvswitch_la_SOURCES += \
lib/dpdk.c \
lib/netdev-dpdk.c \
-   lib/netdev-rte-offloads.c
+   lib/netdev-offload-dpdk.c
 else
 lib_libopenvswitch_la_SOURCES += \
lib/dpdk-stub.c
diff --git a/lib/dpdk.c b/lib/dpdk.c
index a253bef71..fc89a0931 100644
--- a/lib/dpdk.c
+++ b/lib/dpdk.c
@@ -443,7 +443,7 @@ dpdk_init__(const struct smap *ovs_other_config)
 
 /* Finally, register the dpdk classes */
 netdev_dpdk_register();
-netdev_register_flow_api_provider(_dpdk_offloads);
+netdev_register_flow_api_provider(_offload_dpdk);
 return true;
 }
 
diff --git a/lib/netdev-dummy.c b/lib/netdev-dummy.c
index 18eed4cf4..f0c0fbae8 100644
--- a/lib/netdev-dummy.c
+++ b/lib/netdev-dummy.c
@@ -1581,7 +1581,7 @@ netdev_dummy_offloads_init_flow_api(struct netdev *netdev)
 return is_dummy_class(netdev->netdev_class) ? 0 : EOPNOTSUPP;
 }
 
-static const struct netdev_flow_api netdev_dummy_offloads = {
+static const struct netdev_flow_api netdev_offload_dummy = {
 .type = "dummy",
 .flow_put = netdev_dummy_flow_put,
 .flow_del = netdev_dummy_flow_del,
@@ -2034,7 +2034,7 @@ netdev_dummy_register(enum dummy_level level)
 netdev_register_provider(_internal_class);
 netdev_register_provider(_pmd_class);
 
-netdev_register_flow_api_provider(_dummy_offloads);
+netdev_register_flow_api_provider(_offload_dummy);
 
 netdev_vport_tunnel_register();
 }
diff --git a/lib/netdev-rte-offloads.c b/lib/netdev-offload-dpdk.c
similarity index 96%
rename from lib/netdev-rte-offloads.c
rename to lib/netdev-offload-dpdk.c
index b5f16b68d..01e900461 100644
--- a/lib/netdev-rte-offloads.c
+++ b/lib/netdev-offload-dpdk.c
@@ -27,7 +27,7 @@
 #include "packets.h"
 #include "uuid.h"
 
-VLOG_DEFINE_THIS_MODULE(netdev_rte_offloads);
+VLOG_DEFINE_THIS_MODULE(netdev_offload_dpdk);
 
 /* Thread-safety
  * =
@@ -411,7 +411,7 @@ add_flow_rss_action(struct flow_actions *actions,
 }
 
 static int
-netdev_rte_offloads_add_flow(struct netdev *netdev,
+netdev_offload_dpdk_add_flow(struct netdev *netdev,
  const struct match *match,
  struct nlattr *nl_actions OVS_UNUSED,
  size_t actions_len OVS_UNUSED,
@@ -617,7 +617,7 @@ out:
  * Check if any unsupported flow patterns are specified.
  */
 static int
-netdev_rte_offloads_validate_flow(const struct match *match)
+netdev_offload_dpdk_validate_flow(const struct match *match)
 {
 struct match match_zero_wc;
 const struct flow *masks = >wc.masks;
@@ -686,7 +686,7 @@ err:
 }
 
 static int
-netdev_rte_offloads_destroy_flow(struct netdev *netdev,
+netdev_offload_dpdk_destroy_flow(struct netdev *netdev,
  const ovs_u128 *ufid,
  struct rte_flow *rte_flow)
 {
@@ -707,7 +707,7 @@ netdev_rte_offloads_destroy_flow(struct netdev *netdev,
 }
 
 static int
-netdev_rte_offloads_flow_put(struct netdev *netdev, struct match *match,
+netdev_offload_dpdk_flow_put(struct netdev *netdev, struct match *match,
  struct nlattr *actions, size_t actions_len,
  const ovs_u128 *ufid, struct offload_info *info,
  struct dpif_flow_stats *stats OVS_UNUSED)
@@ -721,23 +721,23 @@ netdev_rte_offloads_flow_put(struct netdev *netdev, 
struct match

[ovs-dev] [PATCH v3 1/3] netdev: Dynamic per-port Flow API.

2019-05-07 Thread Ilya Maximets 
Current issues with Flow API:

* OVS calls offloading functions regardless of successful
  flow API initialization. (ex. on init_flow_api failure)
* Static initilaization of Flow API for a netdev_class forbids
  having different offloading types for different instances
  of netdev with the same netdev_class. (ex. different vports in
  'system' and 'netdev' datapaths at the same time)

Solution:

* Move Flow API from the netdev_class to netdev instance.
* Make Flow API dynamic, i.e. probe the APIs and choose the
  suitable one.

Side effects:

* Flow API providers localized as possible in their modules.
* Now we have an ability to make runtime checks. For example,
  we could check if particular device supports features we
  need, like if dpdk device supports RSS+MARK action.

Signed-off-by: Ilya Maximets 
---
 lib/automake.mk   |   2 +-
 lib/dpdk.c|   2 +
 lib/netdev-dpdk.c |  24 +++-
 lib/netdev-dpdk.h |   3 +
 lib/netdev-dummy.c|  24 +++-
 lib/netdev-linux.c|   3 -
 lib/netdev-linux.h|  10 --
 lib/netdev-offload-provider.h |  99 +++
 lib/netdev-provider.h |  67 +--
 lib/netdev-rte-offloads.c |  40 +-
 lib/netdev-rte-offloads.h |  41 +--
 lib/netdev-tc-offloads.c  |  39 --
 lib/netdev-tc-offloads.h  |  44 ---
 lib/netdev-vport.c|   6 +-
 lib/netdev.c  | 221 +++---
 tests/dpif-netdev.at  |   4 +-
 tests/ofproto-macros.at   |   1 -
 17 files changed, 398 insertions(+), 232 deletions(-)
 create mode 100644 lib/netdev-offload-provider.h
 delete mode 100644 lib/netdev-tc-offloads.h

diff --git a/lib/automake.mk b/lib/automake.mk
index cc5dccf39..c70fda3f8 100644
--- a/lib/automake.mk
+++ b/lib/automake.mk
@@ -137,6 +137,7 @@ lib_libopenvswitch_la_SOURCES = \
lib/namemap.c \
lib/netdev-dpdk.h \
lib/netdev-dummy.c \
+   lib/netdev-offload-provider.h \
lib/netdev-provider.h \
lib/netdev-rte-offloads.h \
lib/netdev-vport.c \
@@ -393,7 +394,6 @@ lib_libopenvswitch_la_SOURCES += \
lib/netdev-linux.c \
lib/netdev-linux.h \
lib/netdev-tc-offloads.c \
-   lib/netdev-tc-offloads.h \
lib/netlink-conntrack.c \
lib/netlink-conntrack.h \
lib/netlink-notifier.c \
diff --git a/lib/dpdk.c b/lib/dpdk.c
index dc6171546..6c6298635 100644
--- a/lib/dpdk.c
+++ b/lib/dpdk.c
@@ -34,6 +34,7 @@
 #include "dirs.h"
 #include "fatal-signal.h"
 #include "netdev-dpdk.h"
+#include "netdev-rte-offloads.h"
 #include "openvswitch/dynamic-string.h"
 #include "openvswitch/vlog.h"
 #include "ovs-numa.h"
@@ -442,6 +443,7 @@ dpdk_init__(const struct smap *ovs_other_config)
 
 /* Finally, register the dpdk classes */
 netdev_dpdk_register();
+netdev_dpdk_flow_api_register();
 return true;
 }
 
diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c
index 47153dc60..c06c9ef81 100644
--- a/lib/netdev-dpdk.c
+++ b/lib/netdev-dpdk.c
@@ -4204,6 +4204,27 @@ unlock:
 return err;
 }
 
+bool
+netdev_dpdk_flow_api_supported(struct netdev *netdev)
+{
+struct netdev_dpdk *dev;
+bool ret = false;
+
+if (!is_dpdk_class(netdev->netdev_class)) {
+goto out;
+}
+
+dev = netdev_dpdk_cast(netdev);
+ovs_mutex_lock(>mutex);
+if (dev->type == DPDK_DEV_ETH) {
+/* TODO: Check if we able to offload some minimal flow. */
+ret = true;
+}
+ovs_mutex_unlock(>mutex);
+out:
+return ret;
+}
+
 int
 netdev_dpdk_rte_flow_destroy(struct netdev *netdev,
  struct rte_flow *rte_flow,
@@ -4268,8 +4289,7 @@ netdev_dpdk_rte_flow_create(struct netdev *netdev,
 .get_features = netdev_dpdk_get_features,   \
 .get_status = netdev_dpdk_get_status,   \
 .reconfigure = netdev_dpdk_reconfigure, \
-.rxq_recv = netdev_dpdk_rxq_recv,   \
-DPDK_FLOW_OFFLOAD_API
+.rxq_recv = netdev_dpdk_rxq_recv
 
 static const struct netdev_class dpdk_class = {
 .type = "dpdk",
diff --git a/lib/netdev-dpdk.h b/lib/netdev-dpdk.h
index 9bbb8d8d6..60631c4f0 100644
--- a/lib/netdev-dpdk.h
+++ b/lib/netdev-dpdk.h
@@ -34,6 +34,9 @@ struct rte_flow_action;
 
 void netdev_dpdk_register(void);
 void free_dpdk_buf(struct dp_packet *);
+
+bool netdev_dpdk_flow_api_supported(struct netdev *);
+
 int
 netdev_dpdk_rte_flow_destroy(struct netdev *netdev,
  struct rte_flow *rte_flow,
diff --git a/lib/netdev-dummy.c b/lib/netdev-dummy.c
index 3f90ffa09..18eed4cf4 100644
--- a/lib/netdev-dummy.c
+++ b/lib/netdev-dummy.c
@@ -24,6 +24,7 @@
 #include "dp-packet.h"
 #include "dpif-netdev.h"
 #include "flow.h"
+#include "netdev-offload-provider.h"
 #include "netdev-provider.h"
 #include "netdev-vport.h"
 #include "odp-util.h"
@@ -1523,10 +1524,6 @@ exit:
 return error ? -1 : 0;
 }
 
-#define DUMMY_FLOW_OFFLOAD_API

[ovs-dev] [PATCH v3 2/3] netdev: Split up netdev offloading to separate module.

2019-05-07 Thread Ilya Maximets 
New module 'netdev-offload' created to manage different flow API
implementations. All the generic and provider independent code moved
there from the 'netdev' module.

Flow API providers further encapsulated.

The only function that was changed is 'netdev_any_oor'.
Now it uses offloading related hmap instead of common 'netdev_shash'.

Signed-off-by: Ilya Maximets 
Acked-by: Ben Pfaff 
---
 lib/automake.mk   |   3 +-
 lib/dpdk.c|   4 +-
 lib/dpif-netdev.c |   1 +
 lib/dpif-netlink.c|   1 +
 lib/netdev-dpdk.c |   1 -
 lib/netdev-offload-provider.h |   6 +
 lib/netdev-offload.c  | 658 ++
 lib/netdev-offload.h  | 126 +++
 lib/netdev-provider.h |  21 +-
 lib/netdev-rte-offloads.c |   8 +-
 lib/netdev-rte-offloads.h |  22 --
 lib/netdev.c  | 594 +-
 lib/netdev.h  |  57 ---
 vswitchd/bridge.c |   1 +
 14 files changed, 801 insertions(+), 702 deletions(-)
 create mode 100644 lib/netdev-offload.c
 create mode 100644 lib/netdev-offload.h
 delete mode 100644 lib/netdev-rte-offloads.h

diff --git a/lib/automake.mk b/lib/automake.mk
index c70fda3f8..b2d90da4e 100644
--- a/lib/automake.mk
+++ b/lib/automake.mk
@@ -137,9 +137,10 @@ lib_libopenvswitch_la_SOURCES = \
lib/namemap.c \
lib/netdev-dpdk.h \
lib/netdev-dummy.c \
+   lib/netdev-offload.c \
+   lib/netdev-offload.h \
lib/netdev-offload-provider.h \
lib/netdev-provider.h \
-   lib/netdev-rte-offloads.h \
lib/netdev-vport.c \
lib/netdev-vport.h \
lib/netdev-vport-private.h \
diff --git a/lib/dpdk.c b/lib/dpdk.c
index 6c6298635..a253bef71 100644
--- a/lib/dpdk.c
+++ b/lib/dpdk.c
@@ -34,7 +34,7 @@
 #include "dirs.h"
 #include "fatal-signal.h"
 #include "netdev-dpdk.h"
-#include "netdev-rte-offloads.h"
+#include "netdev-offload-provider.h"
 #include "openvswitch/dynamic-string.h"
 #include "openvswitch/vlog.h"
 #include "ovs-numa.h"
@@ -443,7 +443,7 @@ dpdk_init__(const struct smap *ovs_other_config)
 
 /* Finally, register the dpdk classes */
 netdev_dpdk_register();
-netdev_dpdk_flow_api_register();
+netdev_register_flow_api_provider(_dpdk_offloads);
 return true;
 }
 
diff --git a/lib/dpif-netdev.c b/lib/dpif-netdev.c
index 5a6f2abac..4ad04fdd3 100644
--- a/lib/dpif-netdev.c
+++ b/lib/dpif-netdev.c
@@ -50,6 +50,7 @@
 #include "ipf.h"
 #include "latch.h"
 #include "netdev.h"
+#include "netdev-offload.h"
 #include "netdev-provider.h"
 #include "netdev-vport.h"
 #include "netlink.h"
diff --git a/lib/dpif-netlink.c b/lib/dpif-netlink.c
index c554666ac..ba80a0079 100644
--- a/lib/dpif-netlink.c
+++ b/lib/dpif-netlink.c
@@ -38,6 +38,7 @@
 #include "fat-rwlock.h"
 #include "flow.h"
 #include "netdev-linux.h"
+#include "netdev-offload.h"
 #include "netdev-provider.h"
 #include "netdev-vport.h"
 #include "netdev.h"
diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c
index c06c9ef81..6ea618951 100644
--- a/lib/netdev-dpdk.c
+++ b/lib/netdev-dpdk.c
@@ -47,7 +47,6 @@
 #include "dpif-netdev.h"
 #include "fatal-signal.h"
 #include "netdev-provider.h"
-#include "netdev-rte-offloads.h"
 #include "netdev-vport.h"
 #include "odp-util.h"
 #include "openvswitch/dynamic-string.h"
diff --git a/lib/netdev-offload-provider.h b/lib/netdev-offload-provider.h
index ceeaa50b0..2634efca0 100644
--- a/lib/netdev-offload-provider.h
+++ b/lib/netdev-offload-provider.h
@@ -19,6 +19,8 @@
 #define NETDEV_FLOW_API_PROVIDER_H 1
 
 #include "flow.h"
+#include "netdev-offload.h"
+#include "openvswitch/netdev.h"
 #include "openvswitch/types.h"
 #include "packets.h"
 
@@ -92,6 +94,10 @@ int netdev_unregister_flow_api_provider(const char *type);
 extern const struct netdev_flow_api netdev_tc_offloads;
 #endif
 
+#ifdef DPDK_NETDEV
+extern const struct netdev_flow_api netdev_dpdk_offloads;
+#endif
+
 #ifdef  __cplusplus
 }
 #endif
diff --git a/lib/netdev-offload.c b/lib/netdev-offload.c
new file mode 100644
index 0..e4279f6b9
--- /dev/null
+++ b/lib/netdev-offload.c
@@ -0,0 +1,658 @@
+/*
+ * Copyright (c) 2008 - 2014, 2016, 2017 Nicira, Inc.
+ * Copyright (c) 2019 Samsung Electronics Co.,Ltd.
+ *
+ * Licensed under the Apache License, Version 2.0 (the "License");
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at:
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+#include 
+#include "netdev-offload.h"
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "cmap.h"