[ovs-dev] [PATCH] ovn-nb/sbctl: add inactivity probe in ovn-nb/sbctl set-connection

[Guoshuai Li]

From: Dong Jun 

This patch can set inactivity probe for connection by command
ovn-nbctl set-connection inactivity_probe=3 ptcp:6641:0.0.0.0
ovn-sbctl set-connection inactivity_probe=3 ptcp:6642:0.0.0.0

Signed-off-by: Guoshuai Li 
---
 ovn/utilities/ovn-nbctl.8.xml |  2 +-
 ovn/utilities/ovn-nbctl.c | 28 
 ovn/utilities/ovn-sbctl.c | 33 ++---
 3 files changed, 51 insertions(+), 12 deletions(-)

diff --git a/ovn/utilities/ovn-nbctl.8.xml b/ovn/utilities/ovn-nbctl.8.xml
index 7f4b3aba8..c2373c5bf 100644
--- a/ovn/utilities/ovn-nbctl.8.xml
+++ b/ovn/utilities/ovn-nbctl.8.xml
@@ -866,7 +866,7 @@
   Deletes the configured connection(s).
   
 
-  set-connection target...
+  set-connection inactivity_probe 
target...
   
   Sets the configured manager target or targets.
   
diff --git a/ovn/utilities/ovn-nbctl.c b/ovn/utilities/ovn-nbctl.c
index 80fb97cd4..e25275bc9 100644
--- a/ovn/utilities/ovn-nbctl.c
+++ b/ovn/utilities/ovn-nbctl.c
@@ -446,7 +446,8 @@ DHCP Options commands:\n\
 Connection commands:\n\
   get-connection print the connections\n\
   del-connection delete the connections\n\
-  set-connection TARGET...   set the list of connections to TARGET...\n\
+  set-connection [INACTIVITY_PROBE] TARGET...\n\
+ set the list of connections to TARGET...\n\
 \n\
 SSL commands:\n\
   get-ssl print the SSL configuration\n\
@@ -3491,6 +3492,7 @@ pre_connection(struct ctl_context *ctx)
 {
 ovsdb_idl_add_column(ctx->idl, _nb_global_col_connections);
 ovsdb_idl_add_column(ctx->idl, _connection_col_target);
+ovsdb_idl_add_column(ctx->idl, _connection_col_inactivity_probe);
 }
 
 static void
@@ -3506,7 +3508,16 @@ cmd_get_connection(struct ctl_context *ctx)
 svec_init();
 
 NBREC_CONNECTION_FOR_EACH(conn, ctx->idl) {
-svec_add(, conn->target);
+if (conn->n_inactivity_probe) {
+char *s;
+s = xasprintf("inactivity_probe=%"PRId64" %s",
+  conn->inactivity_probe[0],
+  conn->target);
+svec_add(, s);
+free(s);
+} else {
+svec_add(, conn->target);
+}
 }
 
 svec_sort_unique();
@@ -3544,17 +3555,25 @@ insert_connections(struct ctl_context *ctx, char 
*targets[], size_t n)
 const struct nbrec_nb_global *nb_global = nbrec_nb_global_first(ctx->idl);
 struct nbrec_connection **connections;
 size_t i, conns=0;
+int64_t inactivity_probe = 0;
 
 /* Insert each connection in a new row in Connection table. */
 connections = xmalloc(n * sizeof *connections);
 for (i = 0; i < n; i++) {
-if (stream_verify_name(targets[i]) &&
+if (!strncmp(targets[i], "inactivity_probe=", 17)) {
+inactivity_probe = (int64_t)atoll(targets[i] + 17);
+continue;
+} else if (stream_verify_name(targets[i]) &&
pstream_verify_name(targets[i])) {
 VLOG_WARN("target type \"%s\" is possibly erroneous", targets[i]);
 }
 
 connections[conns] = nbrec_connection_insert(ctx->txn);
 nbrec_connection_set_target(connections[conns], targets[i]);
+if (inactivity_probe) {
+nbrec_connection_set_inactivity_probe(connections[conns],
+  _probe, 1);
+}
 conns++;
 }
 
@@ -4065,7 +4084,8 @@ static const struct ctl_command_syntax nbctl_commands[] = 
{
 /* Connection commands. */
 {"get-connection", 0, 0, "", pre_connection, cmd_get_connection, NULL, "", 
RO},
 {"del-connection", 0, 0, "", pre_connection, cmd_del_connection, NULL, "", 
RW},
-{"set-connection", 1, INT_MAX, "TARGET...", pre_connection, 
cmd_set_connection,
+{"set-connection", 1, INT_MAX, "[INACTIVITY_PROBE] TARGET...",
+ pre_connection, cmd_set_connection,
  NULL, "", RW},
 
 /* SSL commands. */
diff --git a/ovn/utilities/ovn-sbctl.c b/ovn/utilities/ovn-sbctl.c
index c2fd18338..a53b36561 100644
--- a/ovn/utilities/ovn-sbctl.c
+++ b/ovn/utilities/ovn-sbctl.c
@@ -317,7 +317,8 @@ Logical flow commands:\n\
 Connection commands:\n\
   get-connection print the connections\n\
   del-connection delete the connections\n\
-  set-connection TARGET...   set the list of connections to TARGET...\n\
+  set-connection [INACTIVITY_PROBE] [READ/WRITE] [ROLE] TARGET...\n\
+ set the list of connections to TARGET...\n\
 \n\
 SSL commands:\n\
   get-ssl print the SSL configuration\n\
@@ -954,6 +955,7 @@ pre_connection(struct ctl_context *ctx)
 ovsdb_idl_add_column(ctx->idl, _connection_col_target);
 ovsdb_idl_add_column(ctx->idl, _connection_col_read_only);
 ovsdb_idl_add_column(ctx->idl, _connection_col_role);
+

[ovs-dev] [PATCH 3/3] use flow_table as indirect table

[yipeng wang]

From: Yipeng Wang 

It is not memory efficient to store pointers in the distributor.
In this commit, we store a 2 Byte index which is the index into
flow_table. If the flow table is larger than 2^16, the rules
store in the high index entry will not be cached in distributor.
We assume rule count is usually not that large.

In cmap, we add two APIs to support find flow by index and find
index by flow. Since flow table is a cuckoo hash, it is possible
that keys are moved around and also table is rehashed.
In such case, distributor will have misses and
refresh by itself. However, this should not happen frequently and
distributor as a cache should not cause functional error.

Comparing to commit 1, this commit reduce cache/memory requirement by half.
DFC sweeping is also removed to simplify the code since DFC does not hold
pointers to flow any more.

Signed-off-by: Yipeng Wang 
---
 lib/cmap.c|  62 ++
 lib/cmap.h|   5 +++
 lib/dpif-netdev.c | 127 --
 3 files changed, 113 insertions(+), 81 deletions(-)

diff --git a/lib/cmap.c b/lib/cmap.c
index 07719a8..248f26b 100644
--- a/lib/cmap.c
+++ b/lib/cmap.c
@@ -373,6 +373,68 @@ cmap_find(const struct cmap *cmap, uint32_t hash)
hash);
 }
 
+struct cmap_node *
+cmap_find_by_index(const struct cmap *cmap, uint16_t index)
+{
+const struct cmap_impl *impl = cmap_get_impl(cmap);
+
+uint32_t b = index / CMAP_K;
+uint32_t e = index % CMAP_K;
+
+if (b > impl->mask) {
+return NULL;
+}
+
+const struct cmap_bucket *bucket = >buckets[b];
+
+return cmap_node_next(>nodes[e]);
+}
+
+uint16_t
+cmap_find_index(const struct cmap *cmap, uint32_t hash)
+{
+const struct cmap_impl *impl = cmap_get_impl(cmap);
+uint32_t h1 = rehash(impl, hash);
+uint32_t h2 = other_hash(h1);
+
+uint32_t b_index1 = h1 & impl->mask;
+uint32_t b_index2 = h2 & impl->mask;
+
+uint32_t c1, c2;
+uint32_t index = UINT32_MAX;
+
+const struct cmap_bucket *b1 = >buckets[b_index1];
+const struct cmap_bucket *b2 = >buckets[b_index2];
+
+do {
+do {
+c1 = read_even_counter(b1);
+for (int i = 0; i < CMAP_K; i++) {
+if (b1->hashes[i] == hash) {
+index = b_index1 * CMAP_K + i;
+ }
+}
+} while (OVS_UNLIKELY(counter_changed(b1, c1)));
+if (index != UINT32_MAX) {
+break;
+}
+do {
+c2 = read_even_counter(b2);
+for (int i = 0; i < CMAP_K; i++) {
+if (b2->hashes[i] == hash) {
+index = b_index2 * CMAP_K + i;
+}
+}
+} while (OVS_UNLIKELY(counter_changed(b2, c2)));
+
+if (index != UINT32_MAX) {
+break;
+}
+} while (OVS_UNLIKELY(counter_changed(b1, c1)));
+
+return (index >= UINT16_MAX) ? UINT16_MAX : (uint16_t)index;
+}
+
 /* Looks up multiple 'hashes', when the corresponding bit in 'map' is 1,
  * and sets the corresponding pointer in 'nodes', if the hash value was
  * found from the 'cmap'.  In other cases the 'nodes' values are not changed,
diff --git a/lib/cmap.h b/lib/cmap.h
index 8bfb6c0..0266aea 100644
--- a/lib/cmap.h
+++ b/lib/cmap.h
@@ -145,6 +145,11 @@ size_t cmap_replace(struct cmap *, struct cmap_node 
*old_node,
 const struct cmap_node *cmap_find(const struct cmap *, uint32_t hash);
 struct cmap_node *cmap_find_protected(const struct cmap *, uint32_t hash);
 
+struct cmap_node *
+cmap_find_by_index(const struct cmap *cmap, uint16_t index);
+uint16_t
+cmap_find_index(const struct cmap *cmap, uint32_t hash);
+
 /* Looks up multiple 'hashes', when the corresponding bit in 'map' is 1,
  * and sets the corresponding pointer in 'nodes', if the hash value was
  * found from the 'cmap'.  In other cases the 'nodes' values are not changed,
diff --git a/lib/dpif-netdev.c b/lib/dpif-netdev.c
index 08fee86..d9dd20c 100644
--- a/lib/dpif-netdev.c
+++ b/lib/dpif-netdev.c
@@ -175,13 +175,12 @@ struct emc_cache {
 
 struct dfc_bucket {
 uint16_t sig[DFC_ENTRY_PER_BUCKET];
-struct dp_netdev_flow *flow[DFC_ENTRY_PER_BUCKET];
+uint16_t flow_idx[DFC_ENTRY_PER_BUCKET];
 };
 
 struct dfc_cache {
 struct emc_cache emc_cache;
 struct dfc_bucket buckets[DFC_BUCKET_CNT];
-int sweep_idx;
 };
 
 
@@ -722,7 +721,6 @@ dpif_netdev_xps_revalidate_pmd(const struct 
dp_netdev_pmd_thread *pmd,
 static int dpif_netdev_xps_get_tx_qid(const struct dp_netdev_pmd_thread *pmd,
   struct tx_port *tx);
 
-static inline bool dfc_entry_alive(struct dp_netdev_flow *flow);
 static void emc_clear_entry(struct emc_entry *ce);
 static void dfc_clear_entry(struct dfc_bucket *b, int idx);
 
@@ -752,10 +750,9 @@ dfc_cache_init(struct dfc_cache *flow_cache)
 emc_cache_init(_cache->emc_cache);
 for (i = 

[ovs-dev] [PATCH 1/3] dpif-netdev: Refactor datapath flow cache

[yipeng wang]

From: Jan Scheurich 

This is a rebase of Jan's previous patch with some fixes
[PATCH] dpif-netdev: Refactor datapath flow cache
https://mail.openvswitch.org/pipermail/ovs-dev/2017-November/341066.html

So far the netdev datapath uses an 8K EMC to speed up the lookup of
frequently used flows by comparing the parsed packet headers against
the miniflow of a cached flow, using 13 bits of the packet RSS hash
as index. The EMC is too small for many applications with 100K or more
parallel packet flows so that EMC threshing actually degrades performance.
Furthermore, the size of struct miniflow and the flow copying cost
prevents us from making it much larger.

At the same time the lookup cost of the megaflow classifier (DPCLS) is
increasing as the number of frequently hit subtables grows with the
complexity of pipeline and the number of recirculations.

To close the performance gap for many parallel flows, this patch
introduces the datapath flow cache (DFC) with 1M entries as lookup
stage between EMC and DPCLS. It directly maps 20 bits of the RSS hash
to a pointer to the last hit megaflow entry and performs a masked
comparison of the packet flow with the megaflow key to confirm the
hit. This avoids the costly DPCLS lookup even for very large number of
parallel flows with a small memory overhead.

Due the large size of the DFC and the low risk of DFC thrashing, any
DPCLS hit immediately inserts an entry in the DFC so that subsequent
packets get speeded up. The DFC, thus, accelerate also short-lived
flows.

To further accelerate the lookup of few elephant flows, every DFC hit
triggers a probabilistic EMC insertion of the flow. As the DFC entry is
already in place the default EMC insertion probability can be reduced to
1/1000 to minimize EMC thrashing should there still be many fat flows.
The inverse EMC insertion probability remains configurable.

The EMC implementation is simplified by removing the possibility to
store a flow in two slots, as there is no particular reason why two
flows should systematically collide (the RSS hash is not symmetric).
The maximum size of the EMC flow key is limited to 256 bytes to reduce
the memory footprint. This should be sufficient to hold most real life
packet flow keys. Larger flows are not installed in the EMC.

The pmd-stats-show command is enhanced to show both EMC and DFC hits
separately.

The sweep speed for cleaning up obsolete EMC and DFC flow entries and
freeing dead megaflow entries is increased. With a typical PMD cycle
duration of 100us under load and checking one DFC entry per cycle, the
DFC sweep should normally complete within in 100s.

In PVP performance tests with an L3 pipeline over VXLAN we determined the
optimal EMC size to be 16K entries to obtain a uniform speedup compared
to the master branch over the full range of parallel flows. The measurement
below is for 64 byte packets and the average number of subtable lookups
per DPCLS hit in this pipeline is 1.0, i.e. the acceleration already starts for
a single busy mask. Tests with many visited subtables should show a strong
increase of the gain through DFC.

Flows   master  DFC+EMC  Gain
[Mpps]  [Mpps]
--
8   4.454.62 3.8%
100 4.174.47 7.2%
10003.884.3412.0%
20003.544.1717.8%
50003.013.8227.0%
1   2.753.6331.9%
2   2.643.5032.8%
5   2.603.3328.1%
10  2.593.2324.7%
50  2.593.1621.9%

Signed-off-by: Jan Scheurich 
Signed-off-by: Yipeng Wang 
---
 lib/dpif-netdev-perf.h |   1 +
 lib/dpif-netdev.c  | 357 +
 2 files changed, 243 insertions(+), 115 deletions(-)

diff --git a/lib/dpif-netdev-perf.h b/lib/dpif-netdev-perf.h
index 5993c25..157befb 100644
--- a/lib/dpif-netdev-perf.h
+++ b/lib/dpif-netdev-perf.h
@@ -48,6 +48,7 @@ extern "C" {
 
 enum pmd_stat_type {
 PMD_STAT_EXACT_HIT, /* Packets that had an exact match (emc). */
+PMD_STAT_DFC_HIT,/* Packets that had a flow cache hit (dfc). */
 PMD_STAT_MASKED_HIT,/* Packets that matched in the flow table. */
 PMD_STAT_MISS,  /* Packets that did not match and upcall was ok. */
 PMD_STAT_LOST,  /* Packets that did not match and upcall failed. */
diff --git a/lib/dpif-netdev.c b/lib/dpif-netdev.c
index b07fc6b..5920502 100644
--- a/lib/dpif-netdev.c
+++ b/lib/dpif-netdev.c
@@ -128,19 +128,19 @@ struct netdev_flow_key {
 uint64_t buf[FLOW_MAX_PACKET_U64S];
 };
 
-/* Exact match cache for frequently used flows
+/* Datapath flow cache (DFC) for frequently used flows
  *
- * The cache uses a 32-bit hash of the packet (which can be the RSS hash) to
- * search its entries for a miniflow that matches exactly the miniflow of the
- * packet. It stores the 'dpcls_rule' (rule) that matches the miniflow.
+ * The cache uses the 32-bit hash of the packet (which can be the RSS 

[ovs-dev] [PATCH 2/3] dpif-netdev: Use way-associative cache

[yipeng wang]

From: Yipeng Wang 

This commit use a way-associative cache rather than a simple
single entry hash for DFC. Experiments show that this design
generally has much higher hit rate.

Signed-off-by: Yipeng Wang 
---
 lib/dpif-netdev.c | 107 +++---
 1 file changed, 70 insertions(+), 37 deletions(-)

diff --git a/lib/dpif-netdev.c b/lib/dpif-netdev.c
index 5920502..08fee86 100644
--- a/lib/dpif-netdev.c
+++ b/lib/dpif-netdev.c
@@ -150,8 +150,10 @@ struct netdev_flow_key {
  */
 
 #define DFC_MASK_LEN 20
+#define DFC_ENTRY_PER_BUCKET 8
 #define DFC_ENTRIES (1u << DFC_MASK_LEN)
-#define DFC_MASK (DFC_ENTRIES - 1)
+#define DFC_BUCKET_CNT (DFC_ENTRIES / DFC_ENTRY_PER_BUCKET)
+#define DFC_MASK (DFC_BUCKET_CNT - 1)
 #define EMC_MASK_LEN 14
 #define EMC_ENTRIES (1u << EMC_MASK_LEN)
 #define EMC_MASK (EMC_ENTRIES - 1)
@@ -171,13 +173,14 @@ struct emc_cache {
 int sweep_idx;
 };
 
-struct dfc_entry {
-struct dp_netdev_flow *flow;
+struct dfc_bucket {
+uint16_t sig[DFC_ENTRY_PER_BUCKET];
+struct dp_netdev_flow *flow[DFC_ENTRY_PER_BUCKET];
 };
 
 struct dfc_cache {
 struct emc_cache emc_cache;
-struct dfc_entry entries[DFC_ENTRIES];
+struct dfc_bucket buckets[DFC_BUCKET_CNT];
 int sweep_idx;
 };
 
@@ -719,9 +722,9 @@ dpif_netdev_xps_revalidate_pmd(const struct 
dp_netdev_pmd_thread *pmd,
 static int dpif_netdev_xps_get_tx_qid(const struct dp_netdev_pmd_thread *pmd,
   struct tx_port *tx);
 
-static inline bool dfc_entry_alive(struct dfc_entry *ce);
+static inline bool dfc_entry_alive(struct dp_netdev_flow *flow);
 static void emc_clear_entry(struct emc_entry *ce);
-static void dfc_clear_entry(struct dfc_entry *ce);
+static void dfc_clear_entry(struct dfc_bucket *b, int idx);
 
 static void dp_netdev_request_reconfigure(struct dp_netdev *dp);
 
@@ -744,11 +747,13 @@ emc_cache_init(struct emc_cache *emc)
 static void
 dfc_cache_init(struct dfc_cache *flow_cache)
 {
-int i;
+int i, j;
 
 emc_cache_init(_cache->emc_cache);
-for (i = 0; i < ARRAY_SIZE(flow_cache->entries); i++) {
-flow_cache->entries[i].flow = NULL;
+for (i = 0; i < DFC_BUCKET_CNT; i++) {
+for (j = 0; j < DFC_ENTRY_PER_BUCKET; j++) {
+flow_cache->buckets[i].flow[j] = NULL;
+}
 }
 flow_cache->sweep_idx = 0;
 }
@@ -766,10 +771,12 @@ emc_cache_uninit(struct emc_cache *emc)
 static void
 dfc_cache_uninit(struct dfc_cache *flow_cache)
 {
-int i;
+int i, j;
 
-for (i = 0; i < ARRAY_SIZE(flow_cache->entries); i++) {
-dfc_clear_entry(_cache->entries[i]);
+for (i = 0; i < DFC_BUCKET_CNT; i++) {
+for (j = 0; j < DFC_ENTRY_PER_BUCKET; j++) {
+dfc_clear_entry(&(flow_cache->buckets[i]), j);
+}
 }
 emc_cache_uninit(_cache->emc_cache);
 }
@@ -2202,39 +2209,46 @@ emc_lookup(struct emc_cache *emc, const struct 
netdev_flow_key *key)
 return NULL;
 }
 
-static inline struct dfc_entry *
+static inline struct dp_netdev_flow *
 dfc_entry_get(struct dfc_cache *cache, const uint32_t hash)
 {
-return >entries[hash & DFC_MASK];
+struct dfc_bucket *bucket = >buckets[hash & DFC_MASK];
+uint16_t sig = hash >> 16;
+for (int i = 0; i < DFC_ENTRY_PER_BUCKET; i++) {
+if(bucket->sig[i] == sig) {
+return bucket->flow[i];
+}
+}
+return NULL;
 }
 
 static inline bool
-dfc_entry_alive(struct dfc_entry *ce)
+dfc_entry_alive(struct dp_netdev_flow *flow)
 {
-return ce->flow && !ce->flow->dead;
+return flow && !flow->dead;
 }
 
 static void
-dfc_clear_entry(struct dfc_entry *ce)
+dfc_clear_entry(struct dfc_bucket *b, int idx)
 {
-if (ce->flow) {
-dp_netdev_flow_unref(ce->flow);
-ce->flow = NULL;
+if (b->flow[idx]) {
+dp_netdev_flow_unref(b->flow[idx]);
+b->flow[idx] = NULL;
 }
 }
 
 static inline void
-dfc_change_entry(struct dfc_entry *ce, struct dp_netdev_flow *flow)
+dfc_change_entry(struct dfc_bucket *b, int idx, struct dp_netdev_flow *flow)
 {
-if (ce->flow != flow) {
-if (ce->flow) {
-dp_netdev_flow_unref(ce->flow);
+if (b->flow[idx] != flow) {
+if (b->flow[idx]) {
+dp_netdev_flow_unref(b->flow[idx]);
 }
 
 if (dp_netdev_flow_ref(flow)) {
-ce->flow = flow;
+b->flow[idx] = flow;
 } else {
-ce->flow = NULL;
+b->flow[idx] = NULL;
 }
 }
 }
@@ -2245,10 +2259,25 @@ dfc_insert(struct dp_netdev_pmd_thread *pmd,
struct dp_netdev_flow *flow)
 {
 struct dfc_cache *cache = >flow_cache;
-struct dfc_entry *current_entry;
 
-current_entry = dfc_entry_get(cache, key->hash);
-dfc_change_entry(current_entry, flow);
+struct dfc_bucket *bucket = >buckets[key->hash & DFC_MASK];
+uint16_t sig = key->hash >> 16;
+for (int i = 0; i < DFC_ENTRY_PER_BUCKET; i++) {

[ovs-dev] [PATCH 0/3] dpif-netdev: Combine CD and DFC patch for datapath refactor

[yipeng wang]

This patch set is the V1 implementation to combine the CD and DFC design.
Both patches intend to refactor datapath to avoid costly sequential subtable
search.

CD and DFC patch sets:
CD: [PATCH v2 0/5] dpif-netdev: Cuckoo-Distributor  implementation
https://mail.openvswitch.org/pipermail/ovs-dev/2017-October/340305.html

DFC: [PATCH] dpif-netdev: Refactor datapath flow cache
https://mail.openvswitch.org/pipermail/ovs-dev/2017-November/341066.html

The first commit is a rebase of Jan Scheurich's patch of
[PATCH] dpif-netdev: Refactor datapath flow cache

The second commit is to incorporate CD's way-associative design into DFC to
improve the hit rate.

The third commit is to change the distributor to cache an index of flow_table
entry to improve memory efficiency.


RFC of this patch set:
https://mail.openvswitch.org/pipermail/ovs-dev/2018-January/343411.html



RFC->V1:
1. rebase to master head.
2. The last commit is totally rewritten to use the flow_table as indirect table.
   The CD/DFC distributor will cache the index of flow_table entry.
3. Incorporate commit 2 into commit 1. (Bhanu's comment)
4. Change DFC to be always on in commit 1. (Bhanu's comment)


Yipeng Wang (2):
  dpif-netdev: Use way-associative cache
  use flow_table as indirect table

Jan Scheurich (1):
  dpif-netdev: Refactor datapath flow cache

 lib/cmap.c |  62 +
 lib/cmap.h |   5 +
 lib/dpif-netdev-perf.h |   1 +
 lib/dpif-netdev.c  | 359 +
 4 files changed, 310 insertions(+), 117 deletions(-)

-- 
2.7.4

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

[ovs-dev] Test result. RE: [patch v1] conntrack-tcp: Handle tcp session reuse.

[Yangxiaoliang (Neo)]

Hi Darrell,

I have tested VM migration with this patch for several times. And this patch 
can avoid stopping the TCP stream, but the issue is that the TCP stream will 
suspend for  a big number of seconds after migration ( for example, more than 
100 seconds on 8Gbps).  

I think users will not be satisfied this issue. Can we enlarge the range that 
is saved by sequence tracking to be more permissive to decrease the time. Or 
maybe in the future we will solve this issue completely, for now it's not 
recommended to migrate VM with a big network throughput. Or any other idea ?

Thanks.

-Original Message-
From: ovs-dev-boun...@openvswitch.org [mailto:ovs-dev-boun...@openvswitch.org] 
On Behalf Of Darrell Ball
Sent: Thursday, March 01, 2018 3:26 PM
To: dlu...@gmail.com; d...@openvswitch.org
Subject: [ovs-dev] [patch v1] conntrack-tcp: Handle tcp session reuse.

Fix tcp sequence tracking for session reuse cases.  This can happen, for 
example by doing VM migration, where sequence tracking needs to be more 
permissive.  The solution is to be more permissive for session restart and 
session start only.  We don't differentiate session start here where we could 
be more strict, although we could, because the gain in protection is almost 
zero and the code modularity would be lessened and code complexity increased.
This issue originates in release 2.7.

Signed-off-by: Darrell Ball 
---
 lib/conntrack-tcp.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/lib/conntrack-tcp.c b/lib/conntrack-tcp.c index 04460c3..a0ddd65 
100644
--- a/lib/conntrack-tcp.c
+++ b/lib/conntrack-tcp.c
@@ -160,7 +160,6 @@ tcp_conn_update(struct conn *conn_, struct conntrack_bucket 
*ctb,
 uint16_t win = ntohs(tcp->tcp_winsz);
 uint32_t ack, end, seq, orig_seq;
 uint32_t p_len = tcp_payload_length(pkt);
-int ackskew;
 
 if (tcp_invalid_flags(tcp_flags)) {
 return CT_UPDATE_INVALID;
@@ -195,11 +194,11 @@ tcp_conn_update(struct conn *conn_, struct 
conntrack_bucket *ctb,
  */
 
 orig_seq = seq = ntohl(get_16aligned_be32(>tcp_seq));
+bool check_ackskew = true;
 if (src->state < CT_DPIF_TCPS_SYN_SENT) {
 /* First packet from this end. Set its state */
 
 ack = ntohl(get_16aligned_be32(>tcp_ack));
-
 end = seq + p_len;
 if (tcp_flags & TCP_SYN) {
 end++;
@@ -232,6 +231,7 @@ tcp_conn_update(struct conn *conn_, struct conntrack_bucket 
*ctb,
 if (src->seqhi == 1
 || SEQ_GEQ(end + MAX(1, dst->max_win << dws), src->seqhi)) {
 src->seqhi = end + MAX(1, dst->max_win << dws);
+check_ackskew = false;
 }
 if (win > src->max_win) {
 src->max_win = win;
@@ -265,7 +265,13 @@ tcp_conn_update(struct conn *conn_, struct 
conntrack_bucket *ctb,
 end = seq;
 }
 
-ackskew = dst->seqlo - ack;
+int ackskew;
+if (check_ackskew) {
+ackskew = dst->seqlo - ack;
+} else {
+ackskew = 0;
+}
+
 #define MAXACKWINDOW (0x + 1500)/* 1500 is an arbitrary fudge factor */
 if (SEQ_GEQ(src->seqhi, end)
 /* Last octet inside other's window space */
--
1.9.1

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

[ovs-dev] [PATCH v2] datapath-windows: Do not drop Ip fragments less than MIN_FRAGMENT_SIZE

[Anand Kumar]

Previously ipfragment module would drop any fragments less than
MIN_FRAGMENT_SIZE (400 bytes), which was added to safeguard against the
vulnerability CVE-2000-0305. This check is incorrect, since minimum size
of the Ipfragment is 68 bytes (i.e. max length of Ip Header + 8 bytes of
L4 header). So Ip fragments less than MIN_FRAGMENT_SIZE (400 bytes) is not
guranted to be malformed or illegal.

To guard against security vulnerability CVE-2000-0305, for a given ip
datagram, ipfragments should be dropped only when number of smallest
fragments recieved reaches a certain threshold.

Signed-off-by: Anand Kumar 
---
 datapath-windows/ovsext/IpFragment.c | 9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/datapath-windows/ovsext/IpFragment.c 
b/datapath-windows/ovsext/IpFragment.c
index 3d5277a..d59d7cf 100644
--- a/datapath-windows/ovsext/IpFragment.c
+++ b/datapath-windows/ovsext/IpFragment.c
@@ -25,10 +25,10 @@
 #undef OVS_DBG_MOD
 #endif
 #define OVS_DBG_MOD OVS_DBG_IPFRAG
-/* Based on MIN_FRAGMENT_SIZE.*/
-#define MAX_FRAGMENTS 164
+
 #define MIN_FRAGMENT_SIZE 400
 #define MAX_IPDATAGRAM_SIZE 65535
+#define MAX_FRAGMENTS MAX_IPDATAGRAM_SIZE/MIN_FRAGMENT_SIZE + 1
 
 /* Function declarations */
 static KSTART_ROUTINE OvsIpFragmentEntryCleaner;
@@ -275,10 +275,7 @@ OvsProcessIpv4Fragment(POVS_SWITCH_CONTEXT switchContext,
 offset = ntohs(ipHdr->frag_off) & IP_OFFSET;
 offset <<= 3;
 flags = ntohs(ipHdr->frag_off) & IP_MF;
-/* Only the last fragment can be of smaller size.*/
-if (flags && ntohs(ipHdr->tot_len) < MIN_FRAGMENT_SIZE) {
-return NDIS_STATUS_INVALID_LENGTH;
-}
+
 /*Copy fragment specific fields. */
 fragKey.protocol = ipHdr->protocol;
 fragKey.id = ipHdr->id;
-- 
2.9.3.windows.1

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

Re: [ovs-dev] [PATCH] datapath-windows: Do not drop Ip fragments less than MIN_FRAGMENT_SIZE

[Anand Kumar]

Thanks for the review. 

MIN_FRAGMENT_SIZE is used to determine maximum number of fragments that are 
allowed for an IP datagram. 
I will update the macro MAX_FRAGMENTS to compute the value based on 
MIN_FRAGMENT_SIZE.

Regards,
Anand Kumar

On 3/6/18, 5:43 AM, "aserd...@ovn.org"  wrote:

I guess you can also remove the define

(https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openvswitch_ovs_blob_master_datapath-2Dwindows_ovsext_IpFr=DwIFBA=uilaK90D4TOVoH58JNXRgQ=Q5z9tBe-nAOpE7LIHSPV8uy5-437agMXvkeHHMkR8Us=IO3JXN8xQplOxWRufcsmrjAad9LTMz362Yoy7M5ydI0=FWfFKSKtm6492BHmJ_HpEwBo_iYESHGduKFqDgo4ZOU=
agment.c#L30)
since it is not used anywhere else.

Thanks,
Alin.

-Mesaj original-
De la: ovs-dev-boun...@openvswitch.org  În
numele Anand Kumar
Trimis: Tuesday, March 6, 2018 1:21 AM
Către: d...@openvswitch.org
Subiect: [ovs-dev] [PATCH] datapath-windows: Do not drop Ip fragments less
than MIN_FRAGMENT_SIZE

Previously ipfragment module would drop any fragments less than
MIN_FRAGMENT_SIZE (400 bytes), which was added to safeguard against the
vulnerability CVE-2000-0305. This check is incorrect, since minimum size of
the Ipfragment is 68 bytes (i.e. max length of Ip Header + 8 bytes of
L4 header). So Ip fragments less than MIN_FRAGMENT_SIZE (400 bytes) is not
guranted to be malformed or illegal.

To guard against security vulnerability CVE-2000-0305, for a given ip
datagram, ipfragments should be dropped only when number of smallest
fragments recieved reaches a certain threshold.

Signed-off-by: Anand Kumar 
---
 datapath-windows/ovsext/IpFragment.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/datapath-windows/ovsext/IpFragment.c
b/datapath-windows/ovsext/IpFragment.c
index 3d5277a..da9d33a 100644
--- a/datapath-windows/ovsext/IpFragment.c
+++ b/datapath-windows/ovsext/IpFragment.c
@@ -275,10 +275,7 @@ OvsProcessIpv4Fragment(POVS_SWITCH_CONTEXT
switchContext,
 offset = ntohs(ipHdr->frag_off) & IP_OFFSET;
 offset <<= 3;
 flags = ntohs(ipHdr->frag_off) & IP_MF;
-/* Only the last fragment can be of smaller size.*/
-if (flags && ntohs(ipHdr->tot_len) < MIN_FRAGMENT_SIZE) {
-return NDIS_STATUS_INVALID_LENGTH;
-}
+
 /*Copy fragment specific fields. */
 fragKey.protocol = ipHdr->protocol;
 fragKey.id = ipHdr->id;
--
2.9.3.windows.1

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

https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddev=DwIFBA=uilaK90D4TOVoH58JNXRgQ=Q5z9tBe-nAOpE7LIHSPV8uy5-437agMXvkeHHMkR8Us=IO3JXN8xQplOxWRufcsmrjAad9LTMz362Yoy7M5ydI0=lZS0kDScEQSgdBhKx1EABsU7dS-a_f9IMQJv1aQar0I=









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

Re: [ovs-dev] command name of daemon process is null after recover from crash

[Ben Pfaff]

On Tue, Mar 06, 2018 at 10:14:29AM +0800, Huanle Han wrote:
> HI, all
>I find the comm name of daemon process is null after recover from
> crash. For example,
> 
> 1. `ps -ef |grep ovs-vswitchd` : get the ovs-vswitchd pid (not the monitor)
> 2. `cat /proc/$pid/comm` : see name "ovs-vswitchd"
> 3. `kill -11 $pid` : make process segfault and crash
> 4. `ps -ef |grep ovs-vswitchd` : get the new pid
> 5. `cat /proc/$newpid/comm` : see **nothing**
> 6. This also effects some tools, such as "top", "lsof"
> 
> I believe it's the 'set_subprogram_name("")' in moinitor_daemon()
> leads to the problem. But I don't known how to get a correct name
> before set.

I guess we'd need to add a function to retrieve the thread name from
pthreads, e.g. glibc has pthread_getname_np().
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] [RFC] build-windows: Add pthread to windows build

[Shashank Ram]

On Tue, Mar 6, 2018 at 10:44 AM,  wrote:

> Adding Ben to thread also.
>
> The footprint isn't that bad compares to the MSI images:
> alin@DESKTOP-IUDEFLM /c/_2018/march/temp/ovs/windows
> $ ls -lh ovs-windows-installer/images/
> total 582K
> -rw-r--r-- 1 alin Administrators 132K Mar  6 20:00 bannrbmp.bmp
> -rw-r--r-- 1 alin Administrators 450K Mar  6 20:00 dlgbmp.bmp
>
> alin@DESKTOP-IUDEFLM /c/_2018/march/temp/ovs/windows
> $ ls -lh pthreads-w32-2-9-1-release.tar.gz
> -rw-r--r-- 1 alin Administrators 361K Mar  6 20:37
> pthreads-w32-2-9-1-release.tar.gz
>
> It makes it easier for people which are building on systems that
> don't have an internet connections.
>
> Another idea would be to have `--with-pthread-tar=` and point it
> to the tarball.
>
> Which one do you prefer?
>
> Thanks,
> Alin.
>
> -Mesaj original-
> De la: ovs-dev-boun...@openvswitch.org 
> În numele Shashank Ram
> Trimis: Tuesday, March 6, 2018 8:17 PM
> Către: Alin Gabriel Serdean 
> Cc: d...@openvswitch.org
> Subiect: Re: [ovs-dev] [PATCH] [RFC] build-windows: Add pthread to windows
> build
>
> Hi Alin, please lets not checkin a binary file into the repo. It will make
> the repo size bigger and some git operations slower. Also it will be a pain
> to erase it from the history if it needs to be removed.
>
> Thanks,
> Shashank
>
> On Mon, Mar 5, 2018 at 4:40 AM, Alin Gabriel Serdean 
> wrote:
>
> > Until know we asked users to download a precompiled library of `pthreads`
> > as
> > part of the build chain.
> >
> > A big problem with this approach is that the precompiled version of
> > pthreads
> > is built using VS2010 and we must redistribute that runtime to install
> > targets
> > as well.
> >
> > The library seems to be abandoned and no longer maintained. I tried to
> > email
> > the authors several times and unfortunately, I haven’t received a reply.
> > In the end we might end up maintaining the project under the folder
> > `windows`.
> >
> > For now, however we just add the source tarball of the pthread library to
> > the
> > `windows` folder.  We simplify the process of installing and building by
> > compiling pthread library shipped in the `windows` folder during the
> build
> > step.
> > We still allow `--with-pthread=` argument during configure step. If that
> > argument is not specified we fall back to the shipped tarball.
> >
> > Signed-off-by: Alin Gabriel Serdean 
> > ---
> >  Makefile.am   |  11 +++
> >  m4/openvswitch.m4 |  17 -
> >  windows/.gitignore|   3 +++
> >  windows/automake.mk   |   3 ++-
> >  windows/pthreads-w32-2-9-1-release.tar.gz | Bin 0 -> 369537 bytes
> >  5 files changed, 32 insertions(+), 2 deletions(-)
> >  create mode 100644 windows/pthreads-w32-2-9-1-release.tar.gz
> >
>
> Having an option to specify the tar seems like a much better option. This
gives users flexibility to use their own binaries.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] [RFC] build-windows: Add pthread to windows build

[aserdean]

Adding Ben to thread also.

The footprint isn't that bad compares to the MSI images:
alin@DESKTOP-IUDEFLM /c/_2018/march/temp/ovs/windows
$ ls -lh ovs-windows-installer/images/
total 582K
-rw-r--r-- 1 alin Administrators 132K Mar  6 20:00 bannrbmp.bmp
-rw-r--r-- 1 alin Administrators 450K Mar  6 20:00 dlgbmp.bmp

alin@DESKTOP-IUDEFLM /c/_2018/march/temp/ovs/windows
$ ls -lh pthreads-w32-2-9-1-release.tar.gz
-rw-r--r-- 1 alin Administrators 361K Mar  6 20:37 
pthreads-w32-2-9-1-release.tar.gz

It makes it easier for people which are building on systems that
don't have an internet connections.

Another idea would be to have `--with-pthread-tar=` and point it
to the tarball.

Which one do you prefer?

Thanks,
Alin.

-Mesaj original-
De la: ovs-dev-boun...@openvswitch.org  În 
numele Shashank Ram
Trimis: Tuesday, March 6, 2018 8:17 PM
Către: Alin Gabriel Serdean 
Cc: d...@openvswitch.org
Subiect: Re: [ovs-dev] [PATCH] [RFC] build-windows: Add pthread to windows build

Hi Alin, please lets not checkin a binary file into the repo. It will make
the repo size bigger and some git operations slower. Also it will be a pain
to erase it from the history if it needs to be removed.

Thanks,
Shashank

On Mon, Mar 5, 2018 at 4:40 AM, Alin Gabriel Serdean 
wrote:

> Until know we asked users to download a precompiled library of `pthreads`
> as
> part of the build chain.
>
> A big problem with this approach is that the precompiled version of
> pthreads
> is built using VS2010 and we must redistribute that runtime to install
> targets
> as well.
>
> The library seems to be abandoned and no longer maintained. I tried to
> email
> the authors several times and unfortunately, I haven’t received a reply.
> In the end we might end up maintaining the project under the folder
> `windows`.
>
> For now, however we just add the source tarball of the pthread library to
> the
> `windows` folder.  We simplify the process of installing and building by
> compiling pthread library shipped in the `windows` folder during the build
> step.
> We still allow `--with-pthread=` argument during configure step. If that
> argument is not specified we fall back to the shipped tarball.
>
> Signed-off-by: Alin Gabriel Serdean 
> ---
>  Makefile.am   |  11 +++
>  m4/openvswitch.m4 |  17 -
>  windows/.gitignore|   3 +++
>  windows/automake.mk   |   3 ++-
>  windows/pthreads-w32-2-9-1-release.tar.gz | Bin 0 -> 369537 bytes
>  5 files changed, 32 insertions(+), 2 deletions(-)
>  create mode 100644 windows/pthreads-w32-2-9-1-release.tar.gz
>

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

Re: [ovs-dev] [PATCH] datapath-windows: Fix static analysis in Stt.c

[aserdean]

Thanks. Applied on master.

Alin.

-Mesaj original-
De la: ovs-dev-boun...@openvswitch.org  În 
numele Sairam Venugopal
Trimis: Tuesday, March 6, 2018 7:56 PM
Către: Alin Gabriel Serdean ; d...@openvswitch.org
Subiect: Re: [ovs-dev] [PATCH] datapath-windows: Fix static analysis in Stt.c

Didn't realize this patch wasn't acked. Please push this in.

Acked-by: Sairam Venugopal 

Thanks,
Sairam

On 2/8/18, 9:31 AM, "ovs-dev-boun...@openvswitch.org on behalf of Alin Gabriel 
Serdean"  wrote:

The WDK 10 static analysis complains:
stt.c(427): warning C30030: Warning: Allocating executable memory via
specifying a MM_PAGE_PRIORITY type without a bitwise OR with
MdlMappingNoExecute.

Signed-off-by: Alin Gabriel Serdean 

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

Re: [ovs-dev] [PATCH] datapath-windows: Fix static analysis in Stt.c

[Sairam Venugopal]

Didn't realize this patch wasn't acked. Please push this in.

Acked-by: Sairam Venugopal 

Thanks,
Sairam

On 2/8/18, 9:31 AM, "ovs-dev-boun...@openvswitch.org on behalf of Alin Gabriel 
Serdean"  wrote:

The WDK 10 static analysis complains:
stt.c(427): warning C30030: Warning: Allocating executable memory via
specifying a MM_PAGE_PRIORITY type without a bitwise OR with
MdlMappingNoExecute.

Signed-off-by: Alin Gabriel Serdean 
---
 datapath-windows/ovsext/Stt.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/datapath-windows/ovsext/Stt.c b/datapath-windows/ovsext/Stt.c
index e3c4b4686..0220a6e80 100644
--- a/datapath-windows/ovsext/Stt.c
+++ b/datapath-windows/ovsext/Stt.c
@@ -424,8 +424,8 @@ OvsValidateTCPChecksum(PNET_BUFFER_LIST curNbl,
 NDIS_STATUS status;
 
 curMdl = NET_BUFFER_CURRENT_MDL(curNb);
-buf = (PUINT8)MmGetSystemAddressForMdlSafe(curMdl, LowPagePriority)
-+ NET_BUFFER_CURRENT_MDL_OFFSET(curNb);
+buf = (PUINT8)OvsGetMdlWithLowPriority(curMdl)
+  + NET_BUFFER_CURRENT_MDL_OFFSET(curNb);
 if (!buf) {
 status = NDIS_STATUS_INVALID_PACKET;
 return status;
-- 
2.16.1.windows.1

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

https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddev=DwICAg=uilaK90D4TOVoH58JNXRgQ=Z6vowHUOjP5ysP_g372c49Nqc1vEKqHKNBkR5Q5Z7uo=BY4WXq8DeAmm1qlGIU6_uzzNUDAh5i6EKM5G_IdrUVI=ioWzOV69cv-8RilP53-ycbEfxEQ70f9WRH4NxzRWErU=


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

Re: [ovs-dev] [patch v5 00/11] Userspace datapath: Add fragmentation support.

[Darrell Ball]

On Mon, Mar 5, 2018 at 8:16 AM, Aaron Conole  wrote:

> Darrell Ball  writes:
>
> > Hi Aaron
> >
> > I totally missed this response - sorry!
> >
> > On Thu, Feb 22, 2018 at 10:24 AM, Aaron Conole 
> wrote:
> >
> >  Darrell Ball  writes:
> >
> >  > On Fri, Feb 9, 2018 at 1:35 PM, Aaron Conole 
> wrote:
> >  >
> >  >  Hi Darrell,
> >  >
> >  >  Darrell Ball  writes:
> >  >
> >  >  > Fragmentation support for userspace datapath conntrack is added;
> both
> >  >  > v4 and v6 are supported. See the patches for additional details.
> >  >
> >  >  Very pumped about this!
> >  >
> >  >  I went to start reviewing this, but found out that 04/ didn't apply
> >  >  correctly.  No problem, I'll proceed - just figured I'd let you know
> >  >  that:
> >  >
> >  > The merge conflict in NEWS was due to 2 subsequent applies on Feb 6,
> while
> >  > the series was posted on Feb 4.
> >
> >  Yep.  I've worked around it.
> >
> >  >1. I'm looking at it :)
> >  >
> >  > Thanks Aaron
> >
> >  I have a question on patches 5-7:
> >
> >Do you think it's worthwhile having these as configuration options in
> >the database?
> >
> >  I can see where it could be considered that they aren't appropriate
> >  (after all, the linux fragmentation support is enabled/disabled not via
> >  the netlink interface, but by the system administrator outside of the
> >  ovs configuration).  On the other hand, from a user perspective it's
> >  probably more friendly to have that configuration knob be persistent.
> >
> >  I think there is value in having the configuration for ipfrag be stored
> >  in a database so that each 'restart' doesn't require an extra set of
> >  commands be run.  I envision a situation where users have their system
> >  configured, restart, and get confused because they have to manually
> >  re-enable the configuration.  There are a few ways this could be done
> >  (for instance, a post-start script that runs after ovs-ctl), but I think
> >  the database might be a useful way of accomplishing that goal - it
> >  exists
> >
> >  and we use it for dpdk configurations, ex.
> >
> > For global and interface configuration, yes.
> > For flow specific information, the database has very limited usage;
> notably, there is flow eviction
> > policy
> >  an ip prefix settings.
> >
> > I did not opt for using the database here for a few reasons:
> >
> > 1/ Scripts for starts and restarts will be the same and hence
> > the possibility to forget for restart is pretty low;  database
> > commands themselves are also run from scripts, for example for
> interfaces in general and various
> > other stuff.
>
> I'm not sure I follow this.  Users, at least in my experience, almost
> never deal directly with ovs.  They go through some kind of extra
> interface, like neutron/director/ovn/whatever and that deals with all
> the headaches of setting up the datapaths, etc.  Usually, they want to
> configure everything in the database and then be done with it.  That
> lets them query / set using the same interface, and can work remotely
> rather than needing permissions and local access.
>

I agree; local access can be a valid concern in some workflows.



>
> I just imagine a situation where a customer has a system set up via
> OSP/OCP/Kube and vswitchd restarts (for whatever reason... lets say a
> crash or something).  When it comes back, the ipfrag flags are cleared.
> The customers network may start misbehaving, with the cause unknown
> (unless those mechanism start caring about vswitchd process restarts).
>
> Maybe my concern is overblown?  Is there some other mechanism to catch
> this case I missed?
>

I am not sure if there is a misconception/disconnect here. The question is
not whether restarts should be
handled; of course they are intended to be. I want to make we are on the
same page in this respect.

The question is whether a re-read from the database would be used
or re-executing an appctl dpctl command would be executed after a restart.

We need to take into account future support:

1/ A common interface with kernel and userspace DP for fragmentation
configuration going thru OVS.

2/ Similar configuration options for conntrack; for example per zone limits
- we will not use the database here as well.


This is another open question that has intersection here and that is the
default for fragmentation enabled.
Given that we have protections in place for DOS abuse and the kernel
enables fragmentation by default, we can
do the same for userspace DP without much deleterious affects.

This also limits the need to have local access for appctl dpctl commands
for customization only.



>
> > 2/ Using the database, introduces more complexity and dependencies for
> limited
> > gain for something that is usually set once at startup and never changes
> after that.
> >
> > I was/am simply leaning towards not using the database here for 

[ovs-dev] Updated AT Users

[Angela Mishoe]

Hi,

Hope you’re doing well. I do research on companies such as yours.

Just wanted to check whether you would be interested in *AT *user’s
contacts for your sales and email marketing campaigns?

We provide database across the globe from all Industries and from all
departments/titles.

*Job Functions:* - CFO, CEO, CMO, COO, CIO, CTO, CAO, CSO, Vice Presidents,
Presidents, Directors, Heads, Managers, Executives, Analysts, Coordinators,
etc.

Geography We Cover: - North America, EMEA, APAC & Latin America.

*Information Fields: -* Name, Title, Email, Phone, Company Name, Physical
Address, City, State, Zip Code, Country, Web Address, Employee Size,
Revenue Size and Industry.

*We can also provide companies using:* Cisco Systems, Avaya, Nortel, Mitel,
Sprint, Verizon Wireless and some more…

Let me know if you are interested and I will get back to you with more
information for the same.

You can also let me know if you have a different target audience. Thanks!

Regards,
Angela Mishoe

To opt out, please answer with Exclude in the Subject Line.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] OVN python IDL: avoid useless JSON conversion to enhance performance

[Lucas Alvares Gomes]

Hi,

Excellent investigative work here Daniel, thanks for that!

On Wed, Feb 28, 2018 at 9:37 AM, Miguel Angel Ajo Pelayo
 wrote:
> And if we can get backports down the lane, that'd be great :)
>

+1 for backporting it. The changes seems straight forward to do so.

> On Wed, Feb 28, 2018 at 9:37 AM Miguel Angel Ajo Pelayo 
> wrote:
>
>> Acked-by: Miguel Angel Ajo 
>>
>> On Wed, Feb 28, 2018 at 9:13 AM Daniel Alvarez Sanchez <
>> dalva...@redhat.com> wrote:
>>
>>> Thanks Terry and Han for the reviews!
>>> I removed the 'OVN' keyword from the title and submitted a v2:
>>> [PATCH v2] python: avoid useless JSON conversion to enhance performance
>>>
>>> Thanks again.
>>> Daniel
>>>
>>> On Wed, Feb 28, 2018 at 12:41 AM, Han Zhou  wrote:
>>>
>>> > Great catch!
>>> > This patch is generic and not only for OVN, so I suggest to remove the
>>> > "OVN" keyword in commit title.
>>> >
>>> > Acked-by: Han Zhou 
>>> >
>>> > On Tue, Feb 27, 2018 at 12:44 PM, Terry Wilson 
>>> wrote:
>>> >
>>> >> On Tue, Feb 27, 2018 at 9:25 AM, Daniel Alvarez 
>>> >> wrote:
>>> >> > This patch removes a useless conversion to/from JSON in the
>>> >> > processing of any 'modify' operations inside the process_update2
>>> >> > method in Python IDL implementation.
>>> >> >
>>> >> > Previous code will make resources creation take longer as the number
>>> >> > of elements in the row grows because of that JSON conversion. This
>>> >> > patch eliminates it and now the time remains consant regardless
>>> >> > of the database contents improving performance and scaling.
>>> >> >
>>> >> > Reported-by: Daniel Alvarez Sanchez 
>>> >> > Reported-at: https://mail.openvswitch.org/p
>>> >> ipermail/ovs-discuss/2018-February/046263.html
>>> >> > Signed-off-by: Daniel Alvarez 
>>> >> > ---
>>> >> >  python/ovs/db/idl.py | 12 +---
>>> >> >  1 file changed, 5 insertions(+), 7 deletions(-)
>>> >> >
>>> >> > diff --git a/python/ovs/db/idl.py b/python/ovs/db/idl.py
>>> >> > index 60548bcf5..5a4d129c0 100644
>>> >> > --- a/python/ovs/db/idl.py
>>> >> > +++ b/python/ovs/db/idl.py
>>> >> > @@ -518,10 +518,8 @@ class Idl(object):
>>> >> >  if not row:
>>> >> >  raise error.Error('Modify non-existing row')
>>> >> >
>>> >> > -old_row_diff_json = self.__apply_diff(table, row,
>>> >> > -
>>> row_update['modify'])
>>> >> > -self.notify(ROW_UPDATE, row,
>>> >> > -Row.from_json(self, table, uuid,
>>> >> old_row_diff_json))
>>> >> > +old_row = self.__apply_diff(table, row,
>>> >> row_update['modify'])
>>> >> > +self.notify(ROW_UPDATE, row, Row(self, table, uuid,
>>> >> old_row))
>>> >> >  changed = True
>>> >> >  else:
>>> >> >  raise error.Error(' unknown operation',
>>> >> > @@ -584,7 +582,7 @@ class Idl(object):
>>> >> >  row_update[column.name] =
>>> >> self.__column_name(column)
>>> >> >
>>> >> >  def __apply_diff(self, table, row, row_diff):
>>> >> > -old_row_diff_json = {}
>>> >> > +old_row = {}
>>> >> >  for column_name, datum_diff_json in six.iteritems(row_diff):
>>> >> >  column = table.columns.get(column_name)
>>> >> >  if not column:
>>> >> > @@ -601,12 +599,12 @@ class Idl(object):
>>> >> >% (column_name, table.name, e))
>>> >> >  continue
>>> >> >
>>> >> > -old_row_diff_json[column_name] =
>>> >> row._data[column_name].to_json()
>>> >> > +old_row[column_name] = row._data[column_name].copy()
>>> >> >  datum = row._data[column_name].diff(datum_diff)
>>> >> >  if datum != row._data[column_name]:
>>> >> >  row._data[column_name] = datum
>>> >> >
>>> >> > -return old_row_diff_json
>>> >> > +return old_row
>>> >> >
>>> >> >  def __row_update(self, table, row, row_json):
>>> >> >  changed = False
>>> >> > --
>>> >> > 2.13.5
>>> >> >
>>> >> > ___
>>> >> > dev mailing list
>>> >> > d...@openvswitch.org
>>> >> > https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>>> >>
>>> >> +1
>>> >>
>>> >> This passes all of the functional tests in ovsdbapp when applied. Nice
>>> >> find!
>>> >>
>>> >> Terry
>>> >> ___
>>> >> dev mailing list
>>> >> d...@openvswitch.org
>>> >> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>>> >>
>>> >
>>> >
>>> ___
>>> dev mailing list
>>> d...@openvswitch.org
>>> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>>>
>>
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH] tests-windows: Make flow extractor work on Windows

[Alin Gabriel Serdean]

42. library.at:3: testing flow extractor ...
./library.at:4: $PYTHON $srcdir/flowgen.py >/dev/null 3>flows 4>pcap
--- /dev/null   2018-03-06 15:59:49 +0200
+++ /c/_2018/march/06/ovs/tests/testsuite.dir/at-groups/42/stderr   
2018-03-06 15:59:49 +0200
@@ -0,0 +1,4 @@
+Traceback (most recent call last):
+  File "../.././flowgen.py", line 204, in 
+flows = os.fdopen(3, 'wb')
+OSError: [Errno 9] Bad file descriptor
./library.at:4: exit code was 1, expected 0
42. library.at:3:  FAILED (library.at:4)

Unfortunately 3/4/5/.. FDs don't work on Windows. Switch to a filename open
instead of opening the FDs.

Signed-off-by: Alin Gabriel Serdean 
---
 tests/flowgen.py | 4 ++--
 tests/library.at | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/tests/flowgen.py b/tests/flowgen.py
index 221a8f2bc..4d31b05a9 100755
--- a/tests/flowgen.py
+++ b/tests/flowgen.py
@@ -201,8 +201,8 @@ def output(attrs):
 packets.write(packet)
 
 
-flows = os.fdopen(3, 'wb')
-packets = os.fdopen(4, 'wb')
+flows = open('flows', 'wb')
+packets = open('pcap', 'wb')
 
 # Print pcap file header.
 packets.write(struct.pack('>LHH',
diff --git a/tests/library.at b/tests/library.at
index 5efbfbb7c..5bfea2f69 100644
--- a/tests/library.at
+++ b/tests/library.at
@@ -1,7 +1,7 @@
 AT_BANNER([library unit tests])
 
 AT_SETUP([flow extractor])
-AT_CHECK([$PYTHON $srcdir/flowgen.py >/dev/null 3>flows 4>pcap])
+AT_CHECK([$PYTHON $srcdir/flowgen.py >/dev/null])
 AT_CHECK([ovstest test-flows flows pcap], [0], [checked 247 packets, 0 errors
 ])
 AT_CLEANUP
-- 
2.16.1.windows.1

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

Re: [ovs-dev] [PATCH] datapath-windows: Do not drop Ip fragments less than MIN_FRAGMENT_SIZE

[aserdean]

I guess you can also remove the define
(https://github.com/openvswitch/ovs/blob/master/datapath-windows/ovsext/IpFr
agment.c#L30)
since it is not used anywhere else.

Thanks,
Alin.

-Mesaj original-
De la: ovs-dev-boun...@openvswitch.org  În
numele Anand Kumar
Trimis: Tuesday, March 6, 2018 1:21 AM
Către: d...@openvswitch.org
Subiect: [ovs-dev] [PATCH] datapath-windows: Do not drop Ip fragments less
than MIN_FRAGMENT_SIZE

Previously ipfragment module would drop any fragments less than
MIN_FRAGMENT_SIZE (400 bytes), which was added to safeguard against the
vulnerability CVE-2000-0305. This check is incorrect, since minimum size of
the Ipfragment is 68 bytes (i.e. max length of Ip Header + 8 bytes of
L4 header). So Ip fragments less than MIN_FRAGMENT_SIZE (400 bytes) is not
guranted to be malformed or illegal.

To guard against security vulnerability CVE-2000-0305, for a given ip
datagram, ipfragments should be dropped only when number of smallest
fragments recieved reaches a certain threshold.

Signed-off-by: Anand Kumar 
---
 datapath-windows/ovsext/IpFragment.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/datapath-windows/ovsext/IpFragment.c
b/datapath-windows/ovsext/IpFragment.c
index 3d5277a..da9d33a 100644
--- a/datapath-windows/ovsext/IpFragment.c
+++ b/datapath-windows/ovsext/IpFragment.c
@@ -275,10 +275,7 @@ OvsProcessIpv4Fragment(POVS_SWITCH_CONTEXT
switchContext,
 offset = ntohs(ipHdr->frag_off) & IP_OFFSET;
 offset <<= 3;
 flags = ntohs(ipHdr->frag_off) & IP_MF;
-/* Only the last fragment can be of smaller size.*/
-if (flags && ntohs(ipHdr->tot_len) < MIN_FRAGMENT_SIZE) {
-return NDIS_STATUS_INVALID_LENGTH;
-}
+
 /*Copy fragment specific fields. */
 fragKey.protocol = ipHdr->protocol;
 fragKey.id = ipHdr->id;
--
2.9.3.windows.1

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

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

Re: [ovs-dev] [PATCH] Documentation: Add note about dpdkvhostuser and IOMMU.

[Stokes, Ian]

> -Original Message-
> From: ovs-dev-boun...@openvswitch.org [mailto:ovs-dev-
> boun...@openvswitch.org] On Behalf Of Kevin Traynor
> Sent: Tuesday, March 6, 2018 12:07 PM
> To: d...@openvswitch.org
> Cc: Maxime Coquelin 
> Subject: [ovs-dev] [PATCH] Documentation: Add note about dpdkvhostuser and
> IOMMU.
> 
> The docs describe IOMMU support for dpdkvhostuserclient ports, but it is
> not mentioned in the section about dpdkvhostuser ports. Add an explicit
> note to say IOMMU is not supported for dpdkvhostuser ports.
> 
> CC: Maxime Coquelin 
> Signed-off-by: Kevin Traynor 
> ---
> 
> This patch is relevant for master and branch-2.9.
> 
>  Documentation/topics/dpdk/vhost-user.rst | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/Documentation/topics/dpdk/vhost-user.rst
> b/Documentation/topics/dpdk/vhost-user.rst
> index 95517a6..8f20398 100644
> --- a/Documentation/topics/dpdk/vhost-user.rst
> +++ b/Documentation/topics/dpdk/vhost-user.rst
> @@ -106,4 +106,7 @@ the guest. There are two ways to do this: using QEMU
> directly, or using  libvirt.
> 
> +.. note::
> +   IOMMU is not supported with vhost-user ports.
> +

LGTM.

Acked-by: Ian Stokes 

I'll put this as part of the pull request this week.

Thanks
Ian

>  Adding vhost-user ports to the guest (QEMU)
> ~~~
> --
> 1.8.3.1
> 
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] Staffing and Recruiting…..Join Us Onboard

[Captain Nenad Willheim via dev]

Crystal Cruises Line  Australia
PO Box 1237, North Sydney NSW 2059 
Australia.
Email:     crystalserv...@australiamail.com
 
The Crystal Cruises Australia Intends To Increase Its Manpower Base Due To New 
Ships And Increasing Number Of Customers In Our Cruise Linear Australia.
The Total Recruitment Will Be  580  Applicants. Minimum Age Requirements Is 
18-Years and Above.
 
It is Crystal Cruises Line policy not to discriminate against any employee or 
applicant for employment because of   RACE, COLOR, RELIGION, SEX, NATIONAL 
ORIGIN, AGE, DISABILITY, MARITAL OR VETERAN STATUS.
 
THESE ARE THE AVAILABLE POSITIONS:
—Accounting—
Senior Auditor, Junior Auditor, Accountant, Controller, Computerized 
Accounting, Staff Accountant
—Beauty salon—
Salon Manager, Assistant Salon Manager, Beautician, Hair Stylist, Barber, 
Message Therapist, Cosmetologist, Nail Technicians, Aerobic And Fitness 
Instructors, Alternative Instructors, Acupuncturist
—Casino—
Casino Manager, Assistant Casino Manager, Casino Dealer, Slot Technician
—Clergy—
Priest, Minister, Rabbi, Reverend
—Cruise staff—
Cruise Director, Assistant Cruise Director, Cruise Staff, Gentlemen Dance Host, 
Youth Activities Coordinator, Fitness Instructor, Aerobics Instructor, French 
Instructor, German Instructor, Water Sport Scuba, Water Sports Scuba Diving 
Instructor, Port Lecturer, Television Technician, Videographer, International 
Host & Hostess, Administrative Assistant
—Deck—
Captain, Staff Captain, First Officer, Second Officer, Third Officer, Junior 
Third Officer, Deck Engine Mechanic, Navigation Officer, Safety Officer, 
Security Personnel, Chief Radio Officer, Radio Officer, Quarter Master, 
Carpenter, Ordinary Seaman, Able Seaman Entry Level, Able Seaman Limited, Abel 
Seaman Special, Able Seaman Unlimited, Splicer Joiner, Seaman Surveyor, Deck 
Utility Man, Deck Hand, Deck Cadet
—Engineers—
Chief Engineer, Staff Chief Engineer, First Engineer, Second Engineer, Third 
Engineer, Junior Third Engineer, Engine Cadet, Hotel Service Engineer, Chief 
Electrical Engineer
Electrical Engineer, Electronic Engineer, Electronic Engineer Junior, Chief 
Refrigeration Engineer, Refrigeration Engineer, Engine Storekeeper, Motorman, 
Fitter, Oiler, Wiper (Engine Utility Man), Plumber Upholsterer
—Entertainment—
Guest Entertainer, Lounger Performer, Show Signer, Production Vocalist, Show 
Dancer, Dance Troupes And Performers, Production Manager, Assistant Production 
Manager, Stage Manager, Backstage Manager, Disc Jockey, Sound Light Technician, 
Video Technician, Show Band Musician Piano, Cocktail Pianist, Piano Bar 
Entertainer, Show Band Musician Trumpet, Show Band Musician Trombone, Show Band 
Musician Saxophone Reeds, Show Band Musician Drums, Show Band Musician Bass, 
Show Band Musician Guitar, Guitar Soloist, Keyboard Soloist, Guest Band 
Musician, Classic Rock Musicians, R And B Musicians, Country Musicians, 
Instrumentalists, Cabaret Actors, Comedians
—Food And Beverage—
Food And Beverage Director, Assistant Food And Beverage Director, Restaurant 
Manager, Maitre D, Head Waiter Waitress, Jr. Waiter, Dining Room Manager, 
Sommelier Wine Steward Stewardess, Dining Room Waiter Waitress, Dining Room 
Buffet Man, Restaurant Hostess, Bar Manager, Assistant Bar Manager, Bar 
Supervisor, Assistant Bar Supervisor,Bar Accountant, Bar Waiter Waitress, 
Bartender, Bar Steward & Stewardess, Snack Steward Stewardess, Bar Utility, Bar 
Boy, Buffet Steward & Stewardess, Busboy
—Galley—
Executive Chef, Assistant Executive Chef, Souse Chief, Chef Tournant, First 
Cook, Second Cook, Third Cook, Vegetable Cook, Cook Trainee, Crew Cook, Crew 
Cook Assistant, Crew Cook Utility, Officer Mess Man, Staff Mess Man, Provision 
Store Keeper, Butcher Supervisor, Assistant Butcher Supervisor, Butcher, 
Butcher Trainee, Butcher Utility, Pastry Chef, Assistant Pastry Chef, First 
Pastry Man, Second Pastry Man, Third Pastry Man, Baker Supervisor, Assistant 
Baker Supervisor, First Baker, Second Baker, Third Baker, Baker Trainee, Pantry 
Man, Dishwasher, Pot Washer, Ice Carver
—Gift shop—
Gift Shop Manager, Assistant Shop Manager, Retail Sales Person, Florist
—Guest lecturers—
Destination Speaker, Special Interest Speaker/Lecturer, Port/Shopping Lecturer,
—Hotel—
Passenger Service Director, Chief Purser, Assistant Hotel Manager, Deputy 
Purser, Second Purser, Assistant Purser, Computer Technician, Junior Assistant 
Purser, Crew Purser, Assistance Crew Purser, Receptionist, Guest Service 
Coordinator, Guest Service Associate, Hotel Assistant, Shore Excursion Manager, 
Assistant Shore Excursion Manager, Cruise Sales Consultant, Hotel Controller, 
Senior Auditor Hotel Operations, Junior Auditor Hotel Operations, Night 
Auditor, Printer Desktop Publishing And Applications, Yeoman, Chief Yeoman, 
Locket Attendant
—–Housekeeping—
Chief Housekeeping Assistant Chief Housekeeper, Floor Supervisor, Head Room 
Steward, Cabin Steward Stewardess, Assistant Cabin Steward Stewardess, Bell 
Captain, Bell 

[ovs-dev] [PATCH] Documentation: Add note about dpdkvhostuser and IOMMU.

[Kevin Traynor]

The docs describe IOMMU support for dpdkvhostuserclient ports,
but it is not mentioned in the section about dpdkvhostuser
ports. Add an explicit note to say IOMMU is not supported for
dpdkvhostuser ports.

CC: Maxime Coquelin 
Signed-off-by: Kevin Traynor 
---

This patch is relevant for master and branch-2.9.

 Documentation/topics/dpdk/vhost-user.rst | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/topics/dpdk/vhost-user.rst 
b/Documentation/topics/dpdk/vhost-user.rst
index 95517a6..8f20398 100644
--- a/Documentation/topics/dpdk/vhost-user.rst
+++ b/Documentation/topics/dpdk/vhost-user.rst
@@ -106,4 +106,7 @@ the guest. There are two ways to do this: using QEMU 
directly, or using
 libvirt.
 
+.. note::
+   IOMMU is not supported with vhost-user ports.
+
 Adding vhost-user ports to the guest (QEMU)
 ~~~
-- 
1.8.3.1

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

Re: [ovs-dev] Hardware acceleration enablement in OVS-DPDK

[Chandran, Sugesh]

Hello all,
Thank you everyone for attending the OVS-DPDK hardware acceleration call.

Meeting minutes are updated in the following document.

https://docs.google.com/document/d/1KeQB5NIUph721uuk1f1wMy4QXwSWxlzDaumd_bWX6YI/edit?usp=sharing

Feel free to add/comment in case I missed out anything.



Regards
_Sugesh


  -Original Appointment-
  From: Chandran, Sugesh
  Sent: Thursday, March 1, 2018 9:46 PM
  To: Chandran, Sugesh; 'd...@openvswitch.org'; 'Darrell Ball'; 'Simon 
Horman'; Stokes, Ian; 'Yuanhan Liu'; 'Finn Christensen'; 'jiaquan song'; 
'pieter.jansenvanvuu...@netronome.com'; Doherty, Declan; 
'frikkie.scho...@netronome.com'; Bodireddy, Bhanuprakash; Keane, Lorna; Giller, 
Robin; Loftus, Ciara; Awal, Mohammad Abdul; 'Eelco Chaudron'; O Mahony, Billy
  Subject: Hardware acceleration enablement in OVS-DPDK
  When: Monday, March 5, 2018 11:30 AM-12:30 PM (UTC+00:00) Dublin, 
Edinburgh, Lisbon, London.
  Where: Skype Meeting


  Hello All,

  I am setting up next call in this series to discuss further on approaches 
to enable full hardware acceleration in OVS-DPDK.

  Agenda for this meeting is to discuss further on two proposals (one from 
Intel and another from Napatech) for enabling full hardware acceleration in 
OVS-DPDK.

  The Previous meeting minutes can be found at following google doc

  
https://docs.google.com/document/d/1KeQB5NIUph721uuk1f1wMy4QXwSWxlzDaumd_bWX6YI/edit?usp=sharing

  I would encourage everyone to have look at the following two patch series 
before the call, so that we can have a productive discussion.


  The Napatech hardware acceleration approach in OVS-DPDK can be found 
below,

  >>
  Hi All,

  As agreed in last meeting, I have created an OVS branch of our OVS fork 
(from late January - v2.9), and added the Partial hw offload proposal, followed 
by our full offload extension - 3 additional commits.
  It should compile against DPDK 17.11, and for that to be possible an 
existing RTE_FLOW_ACTION_TYPE_VF is (mis-)used to send port-id to PMD. 
Furthermore, tcp_flags update from NIC is commented out due to lack of that 
field in the RTE FLOW query structure.
  Please see this as a PoC. It is not yet ready for an actual proposal, 
though it is fully functioning in our lab.

  https://github.com/napatech/ovs/tree/hw-full-offload-v1

  Further notes:
  As mentioned at the last meeting, this proposal is based on vPorts on NIC 
(being VF, virtio or other vPort), completely handled outside OVS. The vPorts 
are then connected and configured in OVS as "normal" type=dpdk ports. I know 
this is not in-line with Intels proposal, however, we think it might be a good 
idea. It makes it simpler in OVS, since we only need either capabilities, or 
trial & error to do transparent full hw-offload.
  Anyway, this is our current proposal for the next discussion meeting.

  Thanks,
  Finn

  >>


  The intel hardware acceleration proposal can be found at


  

  Hello All,

  As discussed in the last meeting, I have created a OVS 2.7 fork with our 
hardware acceleration implementation as below.


  https://github.com/sugchand/ovs.git (branch - 
dpdk-hw-accel-intel)

  Few points on the implementation.
1)  This implementation is just for reference to show the proposal.
2)  The code is still 2.7 based. We will merge to latest branch once we 
have finalized on the approach.
3)  Some of the hardware acceleration functionalities still missing in this 
implementation, such as flow offload thread , flow stat and tcp-flag handling. 
We are working on it to add those support.
4)  This implementation uses some of hardware specific APIs that are not 
yet available in the DPDK main tree. So the code may not build properly.

  Please review the implementation (in the last 12 commits), Will setup a 
follow up call to discuss further on this.

  Thank you!


  Regards
  _Sugesh
  >

  
.
  --> Join Skype Meeting
Trouble Joining? Try Skype Web 
App
  Join by phone
  +1(916)356-2663 (or your local bridge access #) Choose bridge 
5.
 (Global) English (United States)
  Find a local number

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

  [!OC([1033])!]
  

[ovs-dev] [PATCH] tests-windows: Fix SSL ovsdb test which is hanging

[Alin Gabriel Serdean]

The test:
`1827. ovsdb-server.at:490: testing SSL db: implementation ...`
is hanging on Windows because the returned in the case the client failed to
connect is "Unknown error" vs the normal "Protocol error".

Update the test to accommodate for this.

Signed-off-by: Alin Gabriel Serdean 
---
 tests/ovsdb-server.at | 36 ++--
 1 file changed, 26 insertions(+), 10 deletions(-)

diff --git a/tests/ovsdb-server.at b/tests/ovsdb-server.at
index 968356781..7d94e1c71 100644
--- a/tests/ovsdb-server.at
+++ b/tests/ovsdb-server.at
@@ -569,11 +569,19 @@ AT_CHECK(
   [stderr], 
   [test ! -e pid || kill `cat pid`])
 cat stderr > output
-AT_CHECK_UNQUOTED(
-  [grep "failed to connect" output], [0],
-  [ovsdb-client: failed to connect to "ssl:127.0.0.1:$SSL_PORT" (Protocol 
error)
-], 
-  [ignore], [test ! -e pid || kill `cat pid`])
+if test "$IS_WIN32" = "yes"; then
+  AT_CHECK_UNQUOTED(
+[grep "failed to connect" output], [0],
+[ovsdb-client: failed to connect to "ssl:127.0.0.1:$SSL_PORT" (Unknown 
error)
+],
+[ignore], [test ! -e pid || kill `cat pid`])
+else
+  AT_CHECK_UNQUOTED(
+[grep "failed to connect" output], [0],
+[ovsdb-client: failed to connect to "ssl:127.0.0.1:$SSL_PORT" (Protocol 
error)
+],
+[ignore], [test ! -e pid || kill `cat pid`])
+fi
 # Check that when ciphers are not compatible, that a negotiation
 # failure occurs.
 AT_CHECK(
@@ -593,11 +601,19 @@ AT_CHECK(
   [stderr], 
   [test ! -e pid || kill `cat pid`])
 cat stderr > output
-AT_CHECK_UNQUOTED(
-  [grep "failed to connect" output], [0],
-  [ovsdb-client: failed to connect to "ssl:127.0.0.1:$SSL_PORT" (Protocol 
error)
-], 
-  [ignore], [test ! -e pid || kill `cat pid`])
+if test "$IS_WIN32" = "yes"; then
+  AT_CHECK_UNQUOTED(
+[grep "failed to connect" output], [0],
+[ovsdb-client: failed to connect to "ssl:127.0.0.1:$SSL_PORT" (Unknown 
error)
+],
+[ignore], [test ! -e pid || kill `cat pid`])
+else
+  AT_CHECK_UNQUOTED(
+[grep "failed to connect" output], [0],
+[ovsdb-client: failed to connect to "ssl:127.0.0.1:$SSL_PORT" (Protocol 
error)
+],
+[ignore], [test ! -e pid || kill `cat pid`])
+fi
 # The error message for being unable to negotiate a shared ciphersuite
 # is 'sslv3 alert handshake failure'. This is not the clearest message.
 AT_CHECK_UNQUOTED(
-- 
2.16.1.windows.1

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

[ovs-dev] [PATCH] tests-windows: Add OpenSSL directory to autotest path

[Alin Gabriel Serdean]

Running OpenSSL unit tests without it already being included in library path
revealed a problem: the AUTOTEST_PATH does not include it.

This patch adds a new variable `SSL_DIR` which will be added in AUTOTEST_PATH.

Signed-off-by: Alin Gabriel Serdean 
---
 m4/ax_check_openssl.m4 | 4 
 tests/automake.mk  | 2 +-
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/m4/ax_check_openssl.m4 b/m4/ax_check_openssl.m4
index 7846fb071..281d4dc65 100644
--- a/m4/ax_check_openssl.m4
+++ b/m4/ax_check_openssl.m4
@@ -14,6 +14,7 @@
 # SSL_INCLUDES to the include directives required
 # SSL_LIBS to the -l directives required
 # SSL_LDFLAGS to the -L or -R flags required
+# SSL_DIR to add it to various paths
 #
 #   and calls ACTION-IF-FOUND or ACTION-IF-NOT-FOUND appropriately
 #
@@ -81,8 +82,10 @@ AC_DEFUN([AX_CHECK_OPENSSL], [
 SSL_LDFLAGS="-L$ssldir/lib"
 if test "$WIN32" = "yes"; then
 SSL_LIBS="-lssleay32 -llibeay32"
+SSL_DIR=/$(echo ${ssldir} | ${SED} -e 's/://')
 else
 SSL_LIBS="-lssl -lcrypto"
+SSL_DIR="$ssldir"
 fi
 found=true
 AC_MSG_RESULT([yes])
@@ -126,4 +129,5 @@ AC_DEFUN([AX_CHECK_OPENSSL], [
 AC_SUBST([SSL_INCLUDES])
 AC_SUBST([SSL_LIBS])
 AC_SUBST([SSL_LDFLAGS])
+AC_SUBST([SSL_DIR])
 ])
diff --git a/tests/automake.mk b/tests/automake.mk
index 18698ebc3..160908d05 100644
--- a/tests/automake.mk
+++ b/tests/automake.mk
@@ -136,7 +136,7 @@ SYSTEM_USERSPACE_TESTSUITE = 
$(srcdir)/tests/system-userspace-testsuite
 SYSTEM_OFFLOADS_TESTSUITE = $(srcdir)/tests/system-offloads-testsuite
 DISTCLEANFILES += tests/atconfig tests/atlocal
 
-AUTOTEST_PATH = 
utilities:vswitchd:ovsdb:vtep:tests:$(PTHREAD_WIN32_DIR_DLL):ovn/controller-vtep:ovn/northd:ovn/utilities:ovn/controller
+AUTOTEST_PATH = 
utilities:vswitchd:ovsdb:vtep:tests:$(PTHREAD_WIN32_DIR_DLL):$(SSL_DIR):ovn/controller-vtep:ovn/northd:ovn/utilities:ovn/controller
 
 check-local:
set $(SHELL) '$(TESTSUITE)' -C tests AUTOTEST_PATH=$(AUTOTEST_PATH) 
$(TESTSUITEFLAGS); \
-- 
2.16.1.windows.1

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