[ovs-dev] [PATCH v7 1/1] ovs-numa: Support non-contiguous numa nodes and offline CPU cores

2021-06-22 Thread David Wilder 
This change removes the assumption that numa nodes and cores are numbered
contiguously in linux.  This change is required to support some Power
systems.

A check has been added to verify that cores are online,
offline cores result in non-contiguously numbered cores.

Dpdk EAL option generation is updated to work with non-contiguous numa nodes.
These options can be seen in the ovs-vswitchd.log.  For example:
a system containing only numa nodes 0 and 8 will generate the following:

EAL ARGS: ovs-vswitchd --socket-mem 1024,0,0,0,0,0,0,0,1024 \
 --socket-limit 1024,0,0,0,0,0,0,0,1024 -l 0

Tests for pmd and dpif-netdev have been updated to validate non-contiguous
numbered nodes.

Signed-off-by: David Wilder 
---
 lib/dpdk.c   | 57 +++--
 lib/ovs-numa.c   | 51 
 lib/ovs-numa.h   |  2 ++
 tests/dpif-netdev.at |  2 +-
 tests/pmd.at | 61 
 5 files changed, 142 insertions(+), 31 deletions(-)

diff --git a/lib/dpdk.c b/lib/dpdk.c
index 2eaaa569c..238d0fffb 100644
--- a/lib/dpdk.c
+++ b/lib/dpdk.c
@@ -130,22 +130,63 @@ construct_dpdk_options(const struct smap 
*ovs_other_config, struct svec *args)
 }
 }
 
+static int
+compare_numa_node_list(const void *a_, const void *b_)
+{
+int a = *(const int *) a_;
+int b = *(const int *) b_;
+
+if (a < b) {
+return -1;
+}
+if (a > b) {
+return 1;
+}
+return 0;
+}
+
 static char *
 construct_dpdk_socket_mem(void)
 {
 const char *def_value = "1024";
-int numa, numa_nodes = ovs_numa_get_n_numas();
+struct ovs_numa_dump *dump;
+const struct ovs_numa_info_numa *node;
+int k = 0, last_node = 0, n_numa_nodes, *numa_node_list;
 struct ds dpdk_socket_mem = DS_EMPTY_INITIALIZER;
 
-if (numa_nodes == 0 || numa_nodes == OVS_NUMA_UNSPEC) {
-numa_nodes = 1;
-}
+/* Build a list of all numa nodes with at least one core */
+dump = ovs_numa_dump_n_cores_per_numa(1);
+n_numa_nodes = hmap_count(&dump->numas);
+numa_node_list = xcalloc(n_numa_nodes, sizeof *numa_node_list);
 
-ds_put_cstr(&dpdk_socket_mem, def_value);
-for (numa = 1; numa < numa_nodes; ++numa) {
-ds_put_format(&dpdk_socket_mem, ",%s", def_value);
+FOR_EACH_NUMA_ON_DUMP(node, dump) {
+if (k >= n_numa_nodes) {
+break;
+}
+numa_node_list[k++] = node->numa_id;
 }
-
+qsort(numa_node_list, k, sizeof *numa_node_list, compare_numa_node_list);
+
+for (int i = 0; i < n_numa_nodes; i++) {
+while (numa_node_list[i] > last_node &&
+   numa_node_list[i] != OVS_NUMA_UNSPEC &&
+   numa_node_list[i] <= MAX_NUMA_NODES){
+if (last_node == 0) {
+ds_put_format(&dpdk_socket_mem, "%s", "0");
+} else {
+ds_put_format(&dpdk_socket_mem, ",%s", "0");
+}
+last_node++;
+}
+if (numa_node_list[i] == 0) {
+ds_put_format(&dpdk_socket_mem, "%s", def_value);
+} else {
+ds_put_format(&dpdk_socket_mem, ",%s", def_value);
+}
+last_node++;
+}
+free(numa_node_list);
+ovs_numa_dump_destroy(dump);
 return ds_cstr(&dpdk_socket_mem);
 }
 
diff --git a/lib/ovs-numa.c b/lib/ovs-numa.c
index 6d0a68522..b825ecbdd 100644
--- a/lib/ovs-numa.c
+++ b/lib/ovs-numa.c
@@ -42,21 +42,22 @@ VLOG_DEFINE_THIS_MODULE(ovs_numa);
  * This module stores the affinity information of numa nodes and cpu cores.
  * It also provides functions to bookkeep the pin of threads on cpu cores.
  *
- * It is assumed that the numa node ids and cpu core ids all start from 0 and
- * range continuously.  So, for example, if 'ovs_numa_get_n_cores()' returns N,
- * user can assume core ids from 0 to N-1 are all valid and there is a
- * 'struct cpu_core' for each id.
+ * It is assumed that the numa node ids and cpu core ids all start from 0.
+ * There is no guarantee that node and cpu ids are numbered consecutively
+ * (this is a change from earlier version of the code). So, for example,
+ * if two nodes exist with ids 0 and 8, 'ovs_numa_get_n_nodes()' will
+ * return 2, no assumption of node numbering should be made.
  *
  * NOTE, this module should only be used by the main thread.
  *
- * NOTE, the assumption above will fail when cpu hotplug is used.  In that
- * case ovs-numa will not function correctly.  For now, add a TODO entry
- * for addressing it in the future.
+ * NOTE, if cpu hotplug is used 'all_numa_nodes' and 'all_cpu_cores' must be
+ * invalidated when ever the system topology changes. Support for detecting
+ * topology changes has not been included. For

[ovs-dev] [PATCH v7 0/1] Support for non-contiguous numa nodes and core ids.

2021-06-22 Thread David Wilder 
Ovs-numa currently makes the assumption that numa node ids and cpu core ids
will be numbered contiguously. Current Power systems don't always follow this
model. Furthermore, cpus on Power may be on/off lined based the setting of
Simultaneous multithreading (SMT). The result can be gaps in the numbering of
the cores. For example, a 2 socket system with 20 Core(s) per socket configured
with 4 thread per core (smt=4) has the following topology:

NUMA node0 CPU(s):   0-79
NUMA node8 CPU(s):   80-159

When set to smt=2 the following topology is created.

NUMA node0 CPU(s): 0,1,4,5,8,9,12,13,16,17,20,21,24,25,28,29,32,33,36,37,40,
   41,44,45,48,49,52,53,56,57,60,61,64,65,68,69,72,73,76,77
NUMA node8 CPU(s): 80,81,84,85,88,89,92,93,96,97,100,101,104,105,108,109,112,
   113,116,117,120,121,124,125,128,129,132,133,136,137,140,
   141,144,145,148,149,152,153,156,157

This patch allows ovs-numa to work with non-contiguous node and cpu ids.
In addition lib/dpdk:construct_dpdk_socket_mem() is updated to correctly
build the EAL options: --socket-mem and --socket-limit on systems with
non-contiguous node ids. Pmd and dpif-netdev multi-node tests were updated
to validate a simulated numa topology with non-contiguous nodes.

v2 changes:
-0-day Robot suggested changes.
v3 changes:
-re-wrote cpu_detected() to address memory leak.
V4 changes:
-Rebased patches for:
 https://patchwork.ozlabs.org/project/openvswitch/list/?series=157389.
-Extended the automated tests to test both contiguous and non-contiguous
 configurations.
-changed the phrase "non-consecutive" to "non-contiguous" (since 0, 8 is
 consecutive but not contiguous).
V5 changes 
-Removed unused variable max_numa_id in discover_numa_and_core_dummy().
-Cleanup snprintf formatting in cpu_detected().
-Simplified test coverage of non-contiguous and contiguous nodes.
-Fixed bug in construct_dpdk_socket_mem().
V6 changes
-Sorted the list of numa nodes as hmap will not guarantee any order.
-Added a test to ensure that rxq assignment to pmds can be done when
  there are non-contiguous numa nodes (Provided by ktray...@redhat.com).
-Reduced the number of non-contiguous numa nodes tests in dpif-netdev.at.
-Squashed the patch series to a single patch.
V7 changes
-Change numa_node_list and dependencies from size_t to int.
-Added dereference in sizeof in construct_dpdk_socket_mem().

David Wilder (1):
  ovs-numa: Support non-contiguous numa nodes and offline CPU cores

 lib/dpdk.c   | 57 +++--
 lib/ovs-numa.c   | 51 
 lib/ovs-numa.h   |  2 ++
 tests/dpif-netdev.at |  2 +-
 tests/pmd.at | 61 
 5 files changed, 142 insertions(+), 31 deletions(-)

-- 
2.27.0

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

[ovs-dev] [PATCH v6 1/1] ovs-numa: Support non-contiguous numa nodes and offline CPU cores

2021-06-17 Thread David Wilder 
This change removes the assumption that numa nodes and cores are numbered
contiguously in linux.  This change is required to support some Power
systems.

A check has been added to verify that cores are online,
offline cores result in non-contiguously numbered cores.

Dpdk EAL option generation is updated to work with non-contiguous numa nodes.
These options can be seen in the ovs-vswitchd.log.  For example:
a system containing only numa nodes 0 and 8 will generate the following:

EAL ARGS: ovs-vswitchd --socket-mem 1024,0,0,0,0,0,0,0,1024 \
 --socket-limit 1024,0,0,0,0,0,0,0,1024 -l 0

Tests for pmd and dpif-netdev have been updated to validate non-contiguous
numbered nodes.

Signed-off-by: David Wilder 
---
 lib/dpdk.c   | 57 +++--
 lib/ovs-numa.c   | 51 
 lib/ovs-numa.h   |  2 ++
 tests/dpif-netdev.at |  2 +-
 tests/pmd.at | 61 
 5 files changed, 142 insertions(+), 31 deletions(-)

diff --git a/lib/dpdk.c b/lib/dpdk.c
index 319540394..7f6f1d164 100644
--- a/lib/dpdk.c
+++ b/lib/dpdk.c
@@ -129,22 +129,63 @@ construct_dpdk_options(const struct smap 
*ovs_other_config, struct svec *args)
 }
 }
 
+static int
+compare_numa_node_list(const void *a_, const void *b_)
+{
+size_t a = *(const size_t *) a_;
+size_t b = *(const size_t *) b_;
+
+if (a < b) {
+return -1;
+}
+if (a > b) {
+return 1;
+}
+return 0;
+}
+
 static char *
 construct_dpdk_socket_mem(void)
 {
 const char *def_value = "1024";
-int numa, numa_nodes = ovs_numa_get_n_numas();
+struct ovs_numa_dump *dump;
+const struct ovs_numa_info_numa *node;
+size_t k = 0, last_node = 0, n_numa_nodes, *numa_node_list;
 struct ds dpdk_socket_mem = DS_EMPTY_INITIALIZER;
 
-if (numa_nodes == 0 || numa_nodes == OVS_NUMA_UNSPEC) {
-numa_nodes = 1;
-}
+/* Build a list of all numa nodes with at least one core */
+dump = ovs_numa_dump_n_cores_per_numa(1);
+n_numa_nodes = hmap_count(&dump->numas);
+numa_node_list = xcalloc(n_numa_nodes, sizeof numa_node_list);
 
-ds_put_cstr(&dpdk_socket_mem, def_value);
-for (numa = 1; numa < numa_nodes; ++numa) {
-ds_put_format(&dpdk_socket_mem, ",%s", def_value);
+FOR_EACH_NUMA_ON_DUMP(node, dump) {
+if (k >= n_numa_nodes) {
+break;
+}
+numa_node_list[k++] = node->numa_id;
 }
-
+qsort(numa_node_list, k, sizeof numa_node_list, compare_numa_node_list);
+
+for (size_t i = 0; i < n_numa_nodes; i++) {
+while (numa_node_list[i] > last_node &&
+   numa_node_list[i] != OVS_NUMA_UNSPEC &&
+   numa_node_list[i] <= MAX_NUMA_NODES){
+if (last_node == 0) {
+ds_put_format(&dpdk_socket_mem, "%s", "0");
+} else {
+ds_put_format(&dpdk_socket_mem, ",%s", "0");
+}
+last_node++;
+}
+if (numa_node_list[i] == 0) {
+ds_put_format(&dpdk_socket_mem, "%s", def_value);
+} else {
+ds_put_format(&dpdk_socket_mem, ",%s", def_value);
+}
+last_node++;
+}
+free(numa_node_list);
+ovs_numa_dump_destroy(dump);
 return ds_cstr(&dpdk_socket_mem);
 }
 
diff --git a/lib/ovs-numa.c b/lib/ovs-numa.c
index 6d0a68522..b825ecbdd 100644
--- a/lib/ovs-numa.c
+++ b/lib/ovs-numa.c
@@ -42,21 +42,22 @@ VLOG_DEFINE_THIS_MODULE(ovs_numa);
  * This module stores the affinity information of numa nodes and cpu cores.
  * It also provides functions to bookkeep the pin of threads on cpu cores.
  *
- * It is assumed that the numa node ids and cpu core ids all start from 0 and
- * range continuously.  So, for example, if 'ovs_numa_get_n_cores()' returns N,
- * user can assume core ids from 0 to N-1 are all valid and there is a
- * 'struct cpu_core' for each id.
+ * It is assumed that the numa node ids and cpu core ids all start from 0.
+ * There is no guarantee that node and cpu ids are numbered consecutively
+ * (this is a change from earlier version of the code). So, for example,
+ * if two nodes exist with ids 0 and 8, 'ovs_numa_get_n_nodes()' will
+ * return 2, no assumption of node numbering should be made.
  *
  * NOTE, this module should only be used by the main thread.
  *
- * NOTE, the assumption above will fail when cpu hotplug is used.  In that
- * case ovs-numa will not function correctly.  For now, add a TODO entry
- * for addressing it in the future.
+ * NOTE, if cpu hotplug is used 'all_numa_nodes' and 'all_cpu_cores' must be
+ * invalidated when ever the system topology changes. Support for detecting
+ * topology changes has not been included. For

[ovs-dev] [PATCH v6 0/1] Support for non-contiguous numa nodes and core ids.

2021-06-17 Thread David Wilder 
Ovs-numa currently makes the assumption that numa node ids and cpu core ids
will be numbered contiguously. Current Power systems don't always follow this
model. Furthermore, cpus on Power may be on/off lined based the setting of
Simultaneous multithreading (SMT). The result can be gaps in the numbering of
the cores. For example, a 2 socket system with 20 Core(s) per socket configured
with 4 thread per core (smt=4) has the following topology:

NUMA node0 CPU(s):   0-79
NUMA node8 CPU(s):   80-159

When set to smt=2 the following topology is created.

NUMA node0 CPU(s): 0,1,4,5,8,9,12,13,16,17,20,21,24,25,28,29,32,33,36,37,40,
   41,44,45,48,49,52,53,56,57,60,61,64,65,68,69,72,73,76,77
NUMA node8 CPU(s): 80,81,84,85,88,89,92,93,96,97,100,101,104,105,108,109,112,
   113,116,117,120,121,124,125,128,129,132,133,136,137,140,
   141,144,145,148,149,152,153,156,157

This patch allows ovs-numa to work with non-contiguous node and cpu ids.
In addition lib/dpdk:construct_dpdk_socket_mem() is updated to correctly
build the EAL options: --socket-mem and --socket-limit on systems with
non-contiguous node ids. Pmd and dpif-netdev multi-node tests were updated
to validate a simulated numa topology with non-contiguous nodes.

v2 changes:
-0-day Robot suggested changes.
v3 changes:
-re-wrote cpu_detected() to address memory leak.
V4 changes:
-Rebased patches for:
 https://patchwork.ozlabs.org/project/openvswitch/list/?series=157389.
-Extended the automated tests to test both contiguous and non-contiguous
 configurations.
-changed the phrase "non-consecutive" to "non-contiguous" (since 0, 8 is
 consecutive but not contiguous).
V5 changes 
-Removed unused variable max_numa_id in discover_numa_and_core_dummy().
-Cleanup snprintf formatting in cpu_detected().
-Simplified test coverage of non-contiguous and contiguous nodes.
-Fixed bug in construct_dpdk_socket_mem().
V6 changes
-Sorted the list of numa nodes as hmap will not guarantee any order.
-Added a test to ensure that rxq assignment to pmds can be done when
  there are non-contiguous numa nodes (Provided by ktray...@redhat.com).
-Reduced the number of non-contiguous numa nodes tests in dpif-netdev.at.
-Squashed the patch series to a single patch.

David Wilder (1):
  ovs-numa: Support non-contiguous numa nodes and offline CPU cores

 lib/dpdk.c   | 57 +++--
 lib/ovs-numa.c   | 51 
 lib/ovs-numa.h   |  2 ++
 tests/dpif-netdev.at |  2 +-
 tests/pmd.at | 61 
 5 files changed, 142 insertions(+), 31 deletions(-)

-- 
2.27.0

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

[ovs-dev] [PATCH v5 1/2] ovs-numa: Support non-contiguous numa nodes and offline CPU cores

2021-05-25 Thread David Wilder 
This change removes the assumption that numa nodes and cores are numbered
contiguously in linux.  This change is required to support some Power
systems.

An additional check has been added to verify that cores are online,
offline cores result in non-contiguously numbered cores.

I manually verified that all the exported functions defined in
ovs-numa.h function correctly with these changes on Power and amd64
systems.

Tests for dpif-netdev and pmd that define numa systems using the
--dummy-numa option have been modified to use both contiguous and
non-contiguous numbered nodes.

Signed-off-by: David Wilder 
Reviewed-by: David Christensen 
Tested-by: Emma Finn 
---
 lib/ovs-numa.c   | 50 ++
 tests/dpif-netdev.at | 12 ++--
 tests/pmd.at | 23 ---
 3 files changed, 60 insertions(+), 25 deletions(-)

diff --git a/lib/ovs-numa.c b/lib/ovs-numa.c
index 6d0a685..8c7d25b 100644
--- a/lib/ovs-numa.c
+++ b/lib/ovs-numa.c
@@ -42,16 +42,18 @@ VLOG_DEFINE_THIS_MODULE(ovs_numa);
  * This module stores the affinity information of numa nodes and cpu cores.
  * It also provides functions to bookkeep the pin of threads on cpu cores.
  *
- * It is assumed that the numa node ids and cpu core ids all start from 0 and
- * range continuously.  So, for example, if 'ovs_numa_get_n_cores()' returns N,
- * user can assume core ids from 0 to N-1 are all valid and there is a
- * 'struct cpu_core' for each id.
+ * It is assumed that the numa node ids and cpu core ids all start from 0.
+ * There is no guarantee that node and cpu ids are numbered consecutively
+ * (this is a change from earlier version of the code). So, for example,
+ * if two nodes exist with ids 0 and 8, 'ovs_numa_get_n_nodes()' will
+ * return 2, no assumption of node numbering should be made.
  *
  * NOTE, this module should only be used by the main thread.
  *
- * NOTE, the assumption above will fail when cpu hotplug is used.  In that
- * case ovs-numa will not function correctly.  For now, add a TODO entry
- * for addressing it in the future.
+ * NOTE, if cpu hotplug is used 'all_numa_nodes' and 'all_cpu_cores' must be
+ * invalidated when ever the system topology changes. Support for detecting
+ * topology changes has not been included. For now, add a TODO entry for
+ * addressing it in the future.
  *
  * TODO: Fix ovs-numa when cpu hotplug is used.
  */
@@ -130,15 +132,14 @@ insert_new_cpu_core(struct numa_node *n, unsigned core_id)
  * - "0,0,0,0": four cores on numa socket 0.
  * - "0,1,0,1,0,1,0,1,0,1,0,1,0,1,0,1": 16 cores on two numa sockets.
  * - "0,0,0,0,1,1,1,1": 8 cores on two numa sockets.
- *
- * The different numa ids must be consecutives or the function will abort. */
+ * - "0,0,0,0,8,8,8,8": 8 cores on two numa sockets, non-contiguous.
+ */
 static void
 discover_numa_and_core_dummy(void)
 {
 char *conf = xstrdup(dummy_config);
 char *id, *saveptr = NULL;
 unsigned i = 0;
-long max_numa_id = 0;
 
 for (id = strtok_r(conf, ",", &saveptr); id;
  id = strtok_r(NULL, ",", &saveptr)) {
@@ -152,8 +153,6 @@ discover_numa_and_core_dummy(void)
 continue;
 }
 
-max_numa_id = MAX(max_numa_id, numa_id);
-
 hnode = hmap_first_with_hash(&all_numa_nodes, hash_int(numa_id, 0));
 
 if (hnode) {
@@ -169,10 +168,27 @@ discover_numa_and_core_dummy(void)
 
 free(conf);
 
-if (max_numa_id + 1 != hmap_count(&all_numa_nodes)) {
-ovs_fatal(0, "dummy numa contains non consecutive numa ids");
+}
+
+#ifdef __linux__
+/* Check if a cpu is detected and online */
+static int
+cpu_detected(unsigned int core_id)
+{
+char path[PATH_MAX];
+int len = snprintf(path, sizeof(path),
+   "/sys/devices/system/cpu/cpu%d/topology/core_id",
+   core_id);
+if (len <= 0 || (unsigned) len >= sizeof(path)) {
+return 0;
+}
+if (access(path, F_OK) != 0) {
+return 0;
 }
+
+return 1;
 }
+#endif /* __linux__ */
 
 /* Discovers all numa nodes and the corresponding cpu cores.
  * Constructs the 'struct numa_node' and 'struct cpu_core'. */
@@ -219,7 +235,9 @@ discover_numa_and_core(void)
 unsigned core_id;
 
 core_id = strtoul(subdir->d_name + 3, NULL, 10);
-insert_new_cpu_core(n, core_id);
+if (cpu_detected(core_id)) {
+insert_new_cpu_core(n, core_id);
+}
 }
 }
 closedir(dir);
@@ -229,7 +247,7 @@ discover_numa_and_core(void)
 }
 
 free(path);
-if (!dir || !numa_supported) {
+if (!numa_supported) {
 break;
 }
 }
diff --git a/tests/dpif-netdev.at b/tests/dpif-

[ovs-dev] [PATCH v5 2/2] ovs-numa: Dpdk options with non-contiguous nodes

2021-05-25 Thread David Wilder 
If not supplied by the user --socket-mem and --socket-limit EAL options
are set to a default value based system topology. The assumption that
numa nodes must be numbered contiguously is removed by this change.

These options can be seen in the ovs-vswitchd.log.  For example:
a system containing only numa nodes 0 and 8 will generate the following:

EAL ARGS: ovs-vswitchd --socket-mem 1024,0,0,0,0,0,0,0,1024 \
 --socket-limit 1024,0,0,0,0,0,0,0,1024 -l 0

Signed-off-by: David Wilder 
Reviewed-by: David Christensen 
Tested-by: Emma Finn 
---
 lib/dpdk.c | 33 -
 lib/ovs-numa.c |  1 -
 lib/ovs-numa.h |  2 ++
 3 files changed, 26 insertions(+), 10 deletions(-)

diff --git a/lib/dpdk.c b/lib/dpdk.c
index 3195403..6e4a2e3 100644
--- a/lib/dpdk.c
+++ b/lib/dpdk.c
@@ -133,18 +133,33 @@ static char *
 construct_dpdk_socket_mem(void)
 {
 const char *def_value = "1024";
-int numa, numa_nodes = ovs_numa_get_n_numas();
-struct ds dpdk_socket_mem = DS_EMPTY_INITIALIZER;
+struct ovs_numa_dump *dump;
+int last_node = 0;
+const struct ovs_numa_info_numa *node;
 
-if (numa_nodes == 0 || numa_nodes == OVS_NUMA_UNSPEC) {
-numa_nodes = 1;
-}
+/* Build a list of all numa nodes with at least one core */
+dump = ovs_numa_dump_n_cores_per_numa(1);
+struct ds dpdk_socket_mem = DS_EMPTY_INITIALIZER;
 
-ds_put_cstr(&dpdk_socket_mem, def_value);
-for (numa = 1; numa < numa_nodes; ++numa) {
-ds_put_format(&dpdk_socket_mem, ",%s", def_value);
+FOR_EACH_NUMA_ON_DUMP(node, dump) {
+while (node->numa_id > last_node &&
+   node->numa_id != OVS_NUMA_UNSPEC &&
+   node->numa_id <= MAX_NUMA_NODES){
+if (last_node == 0) {
+ds_put_format(&dpdk_socket_mem, "%s", "0");
+} else {
+ds_put_format(&dpdk_socket_mem, ",%s", "0");
+}
+last_node++;
+}
+if (node->numa_id == 0) {
+ds_put_format(&dpdk_socket_mem, "%s", def_value);
+} else {
+ds_put_format(&dpdk_socket_mem, ",%s", def_value);
+}
+last_node++;
 }
-
+ovs_numa_dump_destroy(dump);
 return ds_cstr(&dpdk_socket_mem);
 }
 
diff --git a/lib/ovs-numa.c b/lib/ovs-numa.c
index 8c7d25b..b825ecb 100644
--- a/lib/ovs-numa.c
+++ b/lib/ovs-numa.c
@@ -58,7 +58,6 @@ VLOG_DEFINE_THIS_MODULE(ovs_numa);
  * TODO: Fix ovs-numa when cpu hotplug is used.
  */
 
-#define MAX_NUMA_NODES 128
 
 /* numa node. */
 struct numa_node {
diff --git a/lib/ovs-numa.h b/lib/ovs-numa.h
index 8f2ea34..ecc251a 100644
--- a/lib/ovs-numa.h
+++ b/lib/ovs-numa.h
@@ -26,6 +26,8 @@
 #define OVS_CORE_UNSPEC INT_MAX
 #define OVS_NUMA_UNSPEC INT_MAX
 
+#define MAX_NUMA_NODES 128
+
 /* Dump of a list of 'struct ovs_numa_info'. */
 struct ovs_numa_dump {
 struct hmap cores;
-- 
1.8.3.1

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

[ovs-dev] [PATCH v5 0/2] Support for non-contiguous numa nodes and core ids.

2021-05-25 Thread David Wilder 
Ovs-numa currently makes the assumption that numa node ids and cpu core ids
will be numbered contiguously. Current Power systems don't always follow this
model. Furthermore, cpus on Power may be on/off lined based the setting of
Simultaneous multithreading (SMT). The result can be gaps in the numbering of
the cores. For example, a 2 socket system with 20 Core(s) per socket configured
with 4 thread per core (smt=4) has the following topology:

NUMA node0 CPU(s):   0-79
NUMA node8 CPU(s):   80-159

When set to smt=2 the following topology is created.

NUMA node0 CPU(s): 0,1,4,5,8,9,12,13,16,17,20,21,24,25,28,29,32,33,36,37,40,
   41,44,45,48,49,52,53,56,57,60,61,64,65,68,69,72,73,76,77
NUMA node8 CPU(s): 80,81,84,85,88,89,92,93,96,97,100,101,104,105,108,109,112,
   113,116,117,120,121,124,125,128,129,132,133,136,137,140,
   141,144,145,148,149,152,153,156,157

The first patch in this series allows ovs-numa to work with non-contiguous
node and cpu ids. I updated pmd and dpif-netdev multi-node tests to simulate
a numa topology with non-contiguous node ids.

The second patch in the series updates lib/dpdk:construct_dpdk_socket_mem()
to correctly build the EAL options: --socket-mem and --socket-limit on systems
with non-contiguous node ids.

v2 changes:
-0-day Robot suggested changes.
v3 changes:
-re-wrote cpu_detected() to address memory leak.
V4 changes:
-Rebased patches for:
 https://patchwork.ozlabs.org/project/openvswitch/list/?series=157389.
-Extended the automated tests to test both contiguous and non-contiguous
 configurations.
-changed the phrase "non-consecutive" to "non-contiguous" (since 0, 8 is
 consecutive but not contiguous).
V5 changes 
-Removed unused variable max_numa_id in discover_numa_and_core_dummy().
-Cleanup snprintf formatting in cpu_detected().
-Simplified test coverage of non-contiguous and contiguous nodes.
-Fixed bug in construct_dpdk_socket_mem().

A travis build with these two patches can be found here:
https://travis-ci.org/github/djlwilder/ovs/builds/772249286

David Wilder (2):
  ovs-numa: Support non-contiguous numa nodes and offline CPU cores
  ovs-numa: Dpdk options with non-contiguous nodes

 lib/dpdk.c   | 33 -
 lib/ovs-numa.c   | 51 ++-
 lib/ovs-numa.h   |  2 ++
 tests/dpif-netdev.at | 12 ++--
 tests/pmd.at | 23 ---
 5 files changed, 86 insertions(+), 35 deletions(-)

-- 
1.8.3.1

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

[ovs-dev] [PATCH v4 1/2] ovs-numa: Support non-contiguous numa nodes and offline CPU cores

2021-05-18 Thread David Wilder 
This change removes the assumption that numa nodes and cores are numbered
contiguously in linux.  This change is required to support some Power
systems.

An additional check has been added to verify that cores are online,
offline cores result in non-contiguously numbered cores.

I manually verified that all the exported functions defined in
ovs-numa.h function correctly with these changes on Power and amd64
systems.

Tests for dpif-netdev and pmd that define numa systems using the
--dummy-numa option have been modified to use both contiguous and
non-contiguous numbered nodes.

Signed-off-by: David Wilder 
Reviewed-by: David Christensen 
---
 lib/ovs-numa.c   | 47 +++---
 tests/dpif-netdev.at | 64 +---
 tests/pmd.at | 20 
 3 files changed, 80 insertions(+), 51 deletions(-)

diff --git a/lib/ovs-numa.c b/lib/ovs-numa.c
index 6d0a685..d2e7cc6 100644
--- a/lib/ovs-numa.c
+++ b/lib/ovs-numa.c
@@ -42,16 +42,18 @@ VLOG_DEFINE_THIS_MODULE(ovs_numa);
  * This module stores the affinity information of numa nodes and cpu cores.
  * It also provides functions to bookkeep the pin of threads on cpu cores.
  *
- * It is assumed that the numa node ids and cpu core ids all start from 0 and
- * range continuously.  So, for example, if 'ovs_numa_get_n_cores()' returns N,
- * user can assume core ids from 0 to N-1 are all valid and there is a
- * 'struct cpu_core' for each id.
+ * It is assumed that the numa node ids and cpu core ids all start from 0.
+ * There is no guarantee that node and cpu ids are numbered consecutively
+ * (this is a change from earlier version of the code). So, for example,
+ * if two nodes exist with ids 0 and 8, 'ovs_numa_get_n_nodes()' will
+ * return 2, no assumption of node numbering should be made.
  *
  * NOTE, this module should only be used by the main thread.
  *
- * NOTE, the assumption above will fail when cpu hotplug is used.  In that
- * case ovs-numa will not function correctly.  For now, add a TODO entry
- * for addressing it in the future.
+ * NOTE, if cpu hotplug is used 'all_numa_nodes' and 'all_cpu_cores' must be
+ * invalidated when ever the system topology changes. Support for detecting
+ * topology changes has not been included. For now, add a TODO entry for
+ * addressing it in the future.
  *
  * TODO: Fix ovs-numa when cpu hotplug is used.
  */
@@ -130,8 +132,8 @@ insert_new_cpu_core(struct numa_node *n, unsigned core_id)
  * - "0,0,0,0": four cores on numa socket 0.
  * - "0,1,0,1,0,1,0,1,0,1,0,1,0,1,0,1": 16 cores on two numa sockets.
  * - "0,0,0,0,1,1,1,1": 8 cores on two numa sockets.
- *
- * The different numa ids must be consecutives or the function will abort. */
+ * - "0,0,0,0,8,8,8,8": 8 cores on two numa sockets, non-contiguous.
+ */
 static void
 discover_numa_and_core_dummy(void)
 {
@@ -169,10 +171,27 @@ discover_numa_and_core_dummy(void)
 
 free(conf);
 
-if (max_numa_id + 1 != hmap_count(&all_numa_nodes)) {
-ovs_fatal(0, "dummy numa contains non consecutive numa ids");
+}
+
+#ifdef __linux__
+/* Check if a cpu is detected and online */
+static int
+cpu_detected(unsigned int core_id)
+{
+char path[PATH_MAX];
+int len = snprintf(path,
+  sizeof(path), "/sys/devices/system/cpu/cpu%d/topology/core_id" ,
+  core_id);
+if (len <= 0 || (unsigned) len >= sizeof(path)) {
+return 0;
+}
+if (access(path, F_OK) != 0) {
+return 0;
 }
+
+return 1;
 }
+#endif /* __linux__ */
 
 /* Discovers all numa nodes and the corresponding cpu cores.
  * Constructs the 'struct numa_node' and 'struct cpu_core'. */
@@ -219,7 +238,9 @@ discover_numa_and_core(void)
 unsigned core_id;
 
 core_id = strtoul(subdir->d_name + 3, NULL, 10);
-insert_new_cpu_core(n, core_id);
+if (cpu_detected(core_id)) {
+insert_new_cpu_core(n, core_id);
+}
 }
 }
 closedir(dir);
@@ -229,7 +250,7 @@ discover_numa_and_core(void)
 }
 
 free(path);
-if (!dir || !numa_supported) {
+if (!numa_supported) {
 break;
 }
 }
diff --git a/tests/dpif-netdev.at b/tests/dpif-netdev.at
index 57cae38..f8782e6 100644
--- a/tests/dpif-netdev.at
+++ b/tests/dpif-netdev.at
@@ -85,7 +85,7 @@ AT_CLEANUP
 
 
 m4_define([DPIF_NETDEV_DUMMY_IFACE],
-  [AT_SETUP([dpif-netdev - $1 interface])
+  [AT_SETUP([dpif-netdev - $1 interface $2])
# Create br0 with interfaces p1 and p7
#and br1 with interfaces p2 and p8
# with p1 and p2 connected via unix domain socket
@@ -98,7 +98,7 @@ m4_define([DPIF_NETDEV_DUMMY_IFACE],
  fail-mode=secure -- \
   add-port br1 p2 -- se

[ovs-dev] [PATCH v4 2/2] ovs-numa: Dpdk options with non-contiguous nodes

2021-05-18 Thread David Wilder 
If not supplied by the user --socket-mem and --socket-limit EAL options
are set to a default value based system topology. The assumption that
numa nodes must be numbered contiguously is removed by this change.

These options can be seen in the ovs-vswitchd.log.  For example:
a system containing only numa nodes 0 and 8 will generate the following:

EAL ARGS: ovs-vswitchd --socket-mem 1024,0,0,0,0,0,0,0,1024 \
 --socket-limit 1024,0,0,0,0,0,0,0,1024 -l 0

Signed-off-by: David Wilder 
Reviewed-by: David Christensen 
---
 lib/dpdk.c | 26 ++
 lib/ovs-numa.c |  1 -
 lib/ovs-numa.h |  2 ++
 3 files changed, 20 insertions(+), 9 deletions(-)

diff --git a/lib/dpdk.c b/lib/dpdk.c
index 3195403..918bc80 100644
--- a/lib/dpdk.c
+++ b/lib/dpdk.c
@@ -133,18 +133,28 @@ static char *
 construct_dpdk_socket_mem(void)
 {
 const char *def_value = "1024";
-int numa, numa_nodes = ovs_numa_get_n_numas();
+struct ovs_numa_dump *dump;
+int last_node = 0;
+
+/* Build a list of all numa nodes with at least one core */
+dump = ovs_numa_dump_n_cores_per_numa(1);
 struct ds dpdk_socket_mem = DS_EMPTY_INITIALIZER;
+ds_put_cstr(&dpdk_socket_mem, def_value);
 
-if (numa_nodes == 0 || numa_nodes == OVS_NUMA_UNSPEC) {
-numa_nodes = 1;
-}
+const struct ovs_numa_info_numa *node;
 
-ds_put_cstr(&dpdk_socket_mem, def_value);
-for (numa = 1; numa < numa_nodes; ++numa) {
-ds_put_format(&dpdk_socket_mem, ",%s", def_value);
+FOR_EACH_NUMA_ON_DUMP(node, dump) {
+while (node->numa_id > last_node+1 &&
+   node->numa_id != OVS_NUMA_UNSPEC &&
+   node->numa_id <= MAX_NUMA_NODES){
+ds_put_format(&dpdk_socket_mem, ",%s", "0");
+++last_node;
+}
+if (node->numa_id != 0) {
+ds_put_format(&dpdk_socket_mem, ",%s", def_value);
+}
 }
-
+ovs_numa_dump_destroy(dump);
 return ds_cstr(&dpdk_socket_mem);
 }
 
diff --git a/lib/ovs-numa.c b/lib/ovs-numa.c
index d2e7cc6..de1d037 100644
--- a/lib/ovs-numa.c
+++ b/lib/ovs-numa.c
@@ -58,7 +58,6 @@ VLOG_DEFINE_THIS_MODULE(ovs_numa);
  * TODO: Fix ovs-numa when cpu hotplug is used.
  */
 
-#define MAX_NUMA_NODES 128
 
 /* numa node. */
 struct numa_node {
diff --git a/lib/ovs-numa.h b/lib/ovs-numa.h
index 8f2ea34..ecc251a 100644
--- a/lib/ovs-numa.h
+++ b/lib/ovs-numa.h
@@ -26,6 +26,8 @@
 #define OVS_CORE_UNSPEC INT_MAX
 #define OVS_NUMA_UNSPEC INT_MAX
 
+#define MAX_NUMA_NODES 128
+
 /* Dump of a list of 'struct ovs_numa_info'. */
 struct ovs_numa_dump {
 struct hmap cores;
-- 
1.8.3.1

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

[ovs-dev] [PATCH v4 0/2] Support for non-contiguous numa nodes and core ids.

2021-05-18 Thread David Wilder 
Ovs-numa currently makes the assumption that numa node ids and cpu core ids
will be numbered contiguously. Current Power systems don't always follow this
model. Furthermore, cpus on Power may be on/off lined based the setting of
Simultaneous multithreading (SMT). The result can be gaps in the numbering of
the cores. For example, a 2 socket system with 20 Core(s) per socket configured
with 4 thread per core (smt=4) has the following topology:

NUMA node0 CPU(s):   0-79
NUMA node8 CPU(s):   80-159

When set to smt=2 the following topology is created.

NUMA node0 CPU(s): 0,1,4,5,8,9,12,13,16,17,20,21,24,25,28,29,32,33,36,37,40,
   41,44,45,48,49,52,53,56,57,60,61,64,65,68,69,72,73,76,77
NUMA node8 CPU(s): 80,81,84,85,88,89,92,93,96,97,100,101,104,105,108,109,112,
   113,116,117,120,121,124,125,128,129,132,133,136,137,140,
   141,144,145,148,149,152,153,156,157

The first patch in this series allows ovs-numa to work with non-contiguous
node and cpu ids. I updated pmd and dpif-netdev multi-node tests to simulate
a numa topology with non-contiguous node ids.

The second patch in the series updates lib/dpdk:construct_dpdk_socket_mem()
to correctly build the EAL options: --socket-mem and --socket-limit on systems
with non-contiguous node ids.

v2 changes:
-0-day Robot suggested changes.
v3 changes:
-re-wrote cpu_detected() to address memory leak.
V4 changes:
-Rebased patches for:
 https://patchwork.ozlabs.org/project/openvswitch/list/?series=157389.
-Extended the automated tests to test both contiguous and non-contiguous
 configurations.
-changed the phrase "non-consecutive" to "non-contiguous" (since 0, 8 is
 consecutive but not contiguous).

A travis build with these two patches can be found here:
https://travis-ci.org/github/djlwilder/ovs/builds/771610112

David Wilder (2):
  ovs-numa: Support non-contiguous numa nodes and offline CPU cores
  ovs-numa: Dpdk options with non-contiguous nodes

 lib/dpdk.c   | 26 ++---
 lib/ovs-numa.c   | 48 +++
 lib/ovs-numa.h   |  2 ++
 tests/dpif-netdev.at | 64 +---
 tests/pmd.at | 20 
 5 files changed, 100 insertions(+), 60 deletions(-)

-- 
1.8.3.1

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

[ovs-dev] [PATCH v3 2/2] ovs-numa: Dpdk options with non-consecutive nodes.

2020-02-07 Thread David Wilder 
If not supplied by the user --socket-mem and --socket-limit EAL options
are set to a default value based system topology. The assumption that
numa nodes must be numbered consecutive is removed by this change.

These options can be seen in the ovs-vswitchd.log.  For example:
a system containing only numa nodes 0 and 8 will generate the following:

EAL ARGS: ovs-vswitchd --socket-mem 1024,0,0,0,0,0,0,0,1024 \
 --socket-limit 1024,0,0,0,0,0,0,0,1024 -l 0

Signed-off-by: David Wilder 
---
 lib/dpdk.c | 26 ++
 lib/ovs-numa.c |  1 -
 lib/ovs-numa.h |  2 ++
 3 files changed, 20 insertions(+), 9 deletions(-)

diff --git a/lib/dpdk.c b/lib/dpdk.c
index 37ea2973c..5af6bb49b 100644
--- a/lib/dpdk.c
+++ b/lib/dpdk.c
@@ -134,18 +134,28 @@ static char *
 construct_dpdk_socket_mem(void)
 {
 const char *def_value = "1024";
-int numa, numa_nodes = ovs_numa_get_n_numas();
+struct ovs_numa_dump *dump;
+int last_node = 0;
+
+/* Build a list of all numa nodes with at least one core */
+dump = ovs_numa_dump_n_cores_per_numa(1);
 struct ds dpdk_socket_mem = DS_EMPTY_INITIALIZER;
+ds_put_cstr(&dpdk_socket_mem, def_value);
 
-if (numa_nodes == 0 || numa_nodes == OVS_NUMA_UNSPEC) {
-numa_nodes = 1;
-}
+const struct ovs_numa_info_numa *node;
 
-ds_put_cstr(&dpdk_socket_mem, def_value);
-for (numa = 1; numa < numa_nodes; ++numa) {
-ds_put_format(&dpdk_socket_mem, ",%s", def_value);
+FOR_EACH_NUMA_ON_DUMP(node, dump) {
+while (node->numa_id > last_node+1 &&
+   node->numa_id != OVS_NUMA_UNSPEC &&
+   node->numa_id <= MAX_NUMA_NODES){
+ds_put_format(&dpdk_socket_mem, ",%s", "0");
+++last_node;
+}
+if (node->numa_id != 0) {
+ds_put_format(&dpdk_socket_mem, ",%s", def_value);
+}
 }
-
+ovs_numa_dump_destroy(dump);
 return ds_cstr(&dpdk_socket_mem);
 }
 
diff --git a/lib/ovs-numa.c b/lib/ovs-numa.c
index ef445d282..d31d0076f 100644
--- a/lib/ovs-numa.c
+++ b/lib/ovs-numa.c
@@ -58,7 +58,6 @@ VLOG_DEFINE_THIS_MODULE(ovs_numa);
  * TODO: Fix ovs-numa when cpu hotplug is used.
  */
 
-#define MAX_NUMA_NODES 128
 
 /* numa node. */
 struct numa_node {
diff --git a/lib/ovs-numa.h b/lib/ovs-numa.h
index 8f2ea3430..ecc251a7f 100644
--- a/lib/ovs-numa.h
+++ b/lib/ovs-numa.h
@@ -26,6 +26,8 @@
 #define OVS_CORE_UNSPEC INT_MAX
 #define OVS_NUMA_UNSPEC INT_MAX
 
+#define MAX_NUMA_NODES 128
+
 /* Dump of a list of 'struct ovs_numa_info'. */
 struct ovs_numa_dump {
 struct hmap cores;
-- 
2.23.0.162.gf1d4a28

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

[ovs-dev] [PATCH v3 0/2] Support for non-consecutive numa nodes and core ids.

2020-02-07 Thread David Wilder 
Ovs-numa currently makes the assumption that numa node ids and cpu core ids
will be numbered consecutively. Current Power systems don't always follow this
model. Furthermore, cpus on Power may be on/off lined based the setting of
Simultaneous multithreading (SMT). The result can be gaps in the numbering of
the cores. For example, a 2 socket system with 20 Core(s) per socket configured
with 4 thread per core (smt=4) has the following topology:

NUMA node0 CPU(s):   0-79
NUMA node8 CPU(s):   80-159

When set to smt=2 the following topology is created.

NUMA node0 CPU(s): 0,1,4,5,8,9,12,13,16,17,20,21,24,25,28,29,32,33,36,37,40,
   41,44,45,48,49,52,53,56,57,60,61,64,65,68,69,72,73,76,77
NUMA node8 CPU(s): 80,81,84,85,88,89,92,93,96,97,100,101,104,105,108,109,112,
   113,116,117,120,121,124,125,128,129,132,133,136,137,140,
   141,144,145,148,149,152,153,156,157

The first patch in this series allows ovs-numa to work with non-consecutive
node and cpu ids. I updated pmd and dpif-netdev multi-node tests to simulate
a numa topology with non-consecutive node ids.

The second patch in the series updates lib/dpdk:construct_dpdk_socket_mem()
to correctly build the EAL options: --socket-mem and --socket-limit on systems
with non-consecutive node ids.

v2 changes:
0-day Robot suggested changes.
v3 changes:
re-wrote cpu_detected() to address memory leak.

A travis build with these two patches can be found here:
https://travis-ci.org/djlwilder/ovs/builds/647118555

David Wilder (2):
  ovs-numa: Non-consecutively numa nodes and cores
  ovs-numa: Dpdk options with non-consecutive nodes.

 lib/dpdk.c   | 26 ++
 lib/ovs-numa.c   | 44 
 lib/ovs-numa.h   |  2 ++
 tests/dpif-netdev.at | 12 ++--
 tests/pmd.at | 20 ++--
 5 files changed, 68 insertions(+), 36 deletions(-)

-- 
2.23.0.162.gf1d4a28

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

[ovs-dev] [PATCH v3 1/2] ovs-numa: Non-consecutively numa nodes and cores

2020-02-07 Thread David Wilder 
This change removes the assumption that numa nodes and cores are numbered
consecutively in linux.  This change is required to support some Power
systems.

An additional check has been added to verify that cores are online,
offline cores result in non-consecutively numbered cores.

I manually verified that all the exported functions defined in
ovs-numa.h function correctly with these changes on Power and amd64
systems.

Tests for dpif-netdev and pmd that define numa systems using the
--dummy-numa option have been modified to use non-consecutive numbered
nodes.

Signed-off-by: David Wilder 
---
 lib/ovs-numa.c   | 43 ---
 tests/dpif-netdev.at | 12 ++--
 tests/pmd.at | 20 ++--
 3 files changed, 48 insertions(+), 27 deletions(-)

diff --git a/lib/ovs-numa.c b/lib/ovs-numa.c
index 6d0a68522..ef445d282 100644
--- a/lib/ovs-numa.c
+++ b/lib/ovs-numa.c
@@ -42,16 +42,18 @@ VLOG_DEFINE_THIS_MODULE(ovs_numa);
  * This module stores the affinity information of numa nodes and cpu cores.
  * It also provides functions to bookkeep the pin of threads on cpu cores.
  *
- * It is assumed that the numa node ids and cpu core ids all start from 0 and
- * range continuously.  So, for example, if 'ovs_numa_get_n_cores()' returns N,
- * user can assume core ids from 0 to N-1 are all valid and there is a
- * 'struct cpu_core' for each id.
+ * It is assumed that the numa node ids and cpu core ids all start from 0.
+ * There is no guarantee that node and cpu ids are numbered consecutively
+ * (this is a change from earlier version of the code). So, for example,
+ * if two nodes exist with ids 0 and 8, 'ovs_numa_get_n_nodes()' will
+ * return 2, no assumption of node numbering should be made.
  *
  * NOTE, this module should only be used by the main thread.
  *
- * NOTE, the assumption above will fail when cpu hotplug is used.  In that
- * case ovs-numa will not function correctly.  For now, add a TODO entry
- * for addressing it in the future.
+ * NOTE, if cpu hotplug is used 'all_numa_nodes' and 'all_cpu_cores' must be
+ * invalidated when ever the system topology changes. Support for detecting
+ * topology changes has not been included. For now, add a TODO entry for
+ * addressing it in the future.
  *
  * TODO: Fix ovs-numa when cpu hotplug is used.
  */
@@ -169,10 +171,27 @@ discover_numa_and_core_dummy(void)
 
 free(conf);
 
-if (max_numa_id + 1 != hmap_count(&all_numa_nodes)) {
-ovs_fatal(0, "dummy numa contains non consecutive numa ids");
+}
+
+#ifdef __linux__
+/* Check if a cpu is detected and online */
+static int
+cpu_detected(unsigned int core_id)
+{
+char path[PATH_MAX];
+int len = snprintf(path,
+  sizeof(path), "/sys/devices/system/cpu/cpu%d/topology/core_id" ,
+  core_id);
+if (len <= 0 || (unsigned)len >= sizeof(path)) {
+return 0;
 }
+if (access(path, F_OK) != 0) {
+return 0;
+}
+
+return 1;
 }
+#endif /* __linux__ */
 
 /* Discovers all numa nodes and the corresponding cpu cores.
  * Constructs the 'struct numa_node' and 'struct cpu_core'. */
@@ -219,7 +238,9 @@ discover_numa_and_core(void)
 unsigned core_id;
 
 core_id = strtoul(subdir->d_name + 3, NULL, 10);
-insert_new_cpu_core(n, core_id);
+if (cpu_detected(core_id)) {
+insert_new_cpu_core(n, core_id);
+}
 }
 }
 closedir(dir);
@@ -229,7 +250,7 @@ discover_numa_and_core(void)
 }
 
 free(path);
-if (!dir || !numa_supported) {
+if (!numa_supported) {
 break;
 }
 }
diff --git a/tests/dpif-netdev.at b/tests/dpif-netdev.at
index 0aeb4e788..3a1a58276 100644
--- a/tests/dpif-netdev.at
+++ b/tests/dpif-netdev.at
@@ -94,7 +94,7 @@ m4_define([DPIF_NETDEV_DUMMY_IFACE],
  fail-mode=secure -- \
   add-port br1 p2 -- set interface p2 type=$1 
options:stream=unix:$OVS_RUNDIR/p0.sock ofport_request=2 -- \
   add-port br1 p8 -- set interface p8 ofport_request=8 type=$1 --], [], [],
-  [m4_if([$1], [dummy-pmd], [--dummy-numa="0,0,0,0,1,1,1,1"], [])])
+  [m4_if([$1], [dummy-pmd], [--dummy-numa="0,0,0,0,8,8,8,8"], [])])
AT_CHECK([ovs-appctl vlog/set dpif:dbg dpif_netdev:dbg])
 
AT_CHECK([ovs-ofctl add-flow br0 action=normal])
@@ -126,7 +126,7 @@ m4_define([DPIF_NETDEV_MISS_FLOW_INSTALL],
   -- set interface p1 type=$1 options:pstream=punix:$OVS_RUNDIR/p0.sock \
   -- set bridge br0 datapath-type=dummy \
 other-config:datapath-id=1234 fail-mode=secure], [], 
[],
-  [m4_if([$1], [dummy-pmd], [--dummy-numa="0,0,0,0,1,1,1,1"], [])])
+  [m4_if([$1], [dummy-pmd], [--dummy-numa="0,0,0,0,8,8,

[ovs-dev] [PATCH v2 0/2] Support for non-consecutive numa nodes and core ids.

2020-02-06 Thread David Wilder 
Ovs-numa currently makes the assumption that numa node ids and cpu core ids
will be numbered consecutively. Current Power systems don't always follow this
model. Furthermore, cpus on Power may be on/off lined based the setting of
Simultaneous multithreading (SMT). The result can be gaps in the numbering of
the cores. For example, a 2 socket system with 20 Core(s) per socket configured
with 4 thread per core (smt=4) has the following topology:

NUMA node0 CPU(s):   0-79
NUMA node8 CPU(s):   80-159

When set to smt=2 the following topology is created.

NUMA node0 CPU(s): 0,1,4,5,8,9,12,13,16,17,20,21,24,25,28,29,32,33,36,37,40,
   41,44,45,48,49,52,53,56,57,60,61,64,65,68,69,72,73,76,77
NUMA node8 CPU(s): 80,81,84,85,88,89,92,93,96,97,100,101,104,105,108,109,112,
   113,116,117,120,121,124,125,128,129,132,133,136,137,140,
   141,144,145,148,149,152,153,156,157

The first patch in this series allows ovs-numa to work with non-consecutive
node and cpu ids. I updated pmd and dpif-netdev multi-node tests to simulate
a numa topology with non-consecutive node ids.

The second patch in the series updates lib/dpdk:construct_dpdk_socket_mem()
to correctly build the EAL options: --socket-mem and --socket-limit on systems
with non-consecutive node ids.

v2 changes:
0-day Robot suggested changes.

A travis build with these two patches can be found here:
https://travis-ci.org/djlwilder/ovs/builds/647016162

David Wilder (2):
  ovs-numa: Non-consecutively numa nodes and cores
  ovs-numa: Dpdk options with non-consecutive nodes.

 lib/dpdk.c   | 26 ++
 lib/ovs-numa.c   | 41 +
 lib/ovs-numa.h   |  2 ++
 tests/dpif-netdev.at | 12 ++--
 tests/pmd.at | 20 ++--
 5 files changed, 65 insertions(+), 36 deletions(-)

-- 
2.23.0.162.gf1d4a28

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

[ovs-dev] [PATCH v2 1/2] ovs-numa: Non-consecutively numa nodes and cores

2020-02-06 Thread David Wilder 
This change removes the assumption that numa nodes and cores are numbered
consecutively in linux.  This change is required to support some Power
systems.

An additional check has been added to verify that cores are online,
offline cores result in non-consecutively numbered cores.

I manually verified that all the exported functions defined in
ovs-numa.h function correctly with these changes on Power and amd64
systems.

Tests for dpif-netdev and pmd that define numa systems using the
--dummy-numa option have been modified to use non-consecutive numbered
nodes.

Changes for v2:
0-day Robot suggested changes.

Signed-off-by: David Wilder 
---
 lib/ovs-numa.c   | 40 +---
 tests/dpif-netdev.at | 12 ++--
 tests/pmd.at | 20 ++--
 3 files changed, 45 insertions(+), 27 deletions(-)

diff --git a/lib/ovs-numa.c b/lib/ovs-numa.c
index 6d0a68522..5153ed27e 100644
--- a/lib/ovs-numa.c
+++ b/lib/ovs-numa.c
@@ -42,16 +42,18 @@ VLOG_DEFINE_THIS_MODULE(ovs_numa);
  * This module stores the affinity information of numa nodes and cpu cores.
  * It also provides functions to bookkeep the pin of threads on cpu cores.
  *
- * It is assumed that the numa node ids and cpu core ids all start from 0 and
- * range continuously.  So, for example, if 'ovs_numa_get_n_cores()' returns N,
- * user can assume core ids from 0 to N-1 are all valid and there is a
- * 'struct cpu_core' for each id.
+ * It is assumed that the numa node ids and cpu core ids all start from 0.
+ * There is no guarantee that node and cpu ids are numbered consecutively
+ * (this is a change from earlier version of the code). So, for example,
+ * if two nodes exist with ids 0 and 8, 'ovs_numa_get_n_nodes()' will
+ * return 2, no assumption of node numbering should be made.
  *
  * NOTE, this module should only be used by the main thread.
  *
- * NOTE, the assumption above will fail when cpu hotplug is used.  In that
- * case ovs-numa will not function correctly.  For now, add a TODO entry
- * for addressing it in the future.
+ * NOTE, if cpu hotplug is used 'all_numa_nodes' and 'all_cpu_cores' must be
+ * invalidated when ever the system topology changes. Support for detecting
+ * topology changes has not been included. For now, add a TODO entry for
+ * addressing it in the future.
  *
  * TODO: Fix ovs-numa when cpu hotplug is used.
  */
@@ -169,10 +171,24 @@ discover_numa_and_core_dummy(void)
 
 free(conf);
 
-if (max_numa_id + 1 != hmap_count(&all_numa_nodes)) {
-ovs_fatal(0, "dummy numa contains non consecutive numa ids");
+}
+
+#ifdef __linux__
+/* Check if a cpu is detected and online */
+static int
+cpu_detected(unsigned int core_id)
+{
+char *path;
+
+path = xasprintf( "/sys/devices/system/cpu/cpu%d/topology/core_id" ,
+ core_id);
+if (access(path, F_OK) != 0) {
+return 0;
 }
+
+return 1;
 }
+#endif /* __linux__ */
 
 /* Discovers all numa nodes and the corresponding cpu cores.
  * Constructs the 'struct numa_node' and 'struct cpu_core'. */
@@ -219,7 +235,9 @@ discover_numa_and_core(void)
 unsigned core_id;
 
 core_id = strtoul(subdir->d_name + 3, NULL, 10);
-insert_new_cpu_core(n, core_id);
+if (cpu_detected(core_id)) {
+insert_new_cpu_core(n, core_id);
+}
 }
 }
 closedir(dir);
@@ -229,7 +247,7 @@ discover_numa_and_core(void)
 }
 
 free(path);
-if (!dir || !numa_supported) {
+if (!numa_supported) {
 break;
 }
 }
diff --git a/tests/dpif-netdev.at b/tests/dpif-netdev.at
index 0aeb4e788..3a1a58276 100644
--- a/tests/dpif-netdev.at
+++ b/tests/dpif-netdev.at
@@ -94,7 +94,7 @@ m4_define([DPIF_NETDEV_DUMMY_IFACE],
  fail-mode=secure -- \
   add-port br1 p2 -- set interface p2 type=$1 
options:stream=unix:$OVS_RUNDIR/p0.sock ofport_request=2 -- \
   add-port br1 p8 -- set interface p8 ofport_request=8 type=$1 --], [], [],
-  [m4_if([$1], [dummy-pmd], [--dummy-numa="0,0,0,0,1,1,1,1"], [])])
+  [m4_if([$1], [dummy-pmd], [--dummy-numa="0,0,0,0,8,8,8,8"], [])])
AT_CHECK([ovs-appctl vlog/set dpif:dbg dpif_netdev:dbg])
 
AT_CHECK([ovs-ofctl add-flow br0 action=normal])
@@ -126,7 +126,7 @@ m4_define([DPIF_NETDEV_MISS_FLOW_INSTALL],
   -- set interface p1 type=$1 options:pstream=punix:$OVS_RUNDIR/p0.sock \
   -- set bridge br0 datapath-type=dummy \
 other-config:datapath-id=1234 fail-mode=secure], [], 
[],
-  [m4_if([$1], [dummy-pmd], [--dummy-numa="0,0,0,0,1,1,1,1"], [])])
+  [m4_if([$1], [dummy-pmd], [--dummy-numa="0,0,0,0,8,8,8,8"], [])])
AT_CHECK([ovs-appctl vlog/set dpif:dbg dpif_netdev:dbg])

[ovs-dev] [PATCH v2 2/2] ovs-numa: Dpdk options with non-consecutive nodes.

2020-02-06 Thread David Wilder 
If not supplied by the user --socket-mem and --socket-limit EAL options
are set to a default value based system topology. The assumption that
numa nodes must be numbered consecutive is removed by this change.

These options can be seen in the ovs-vswitchd.log.  For example:
a system containing only numa nodes 0 and 8 will generate the following:

EAL ARGS: ovs-vswitchd --socket-mem 1024,0,0,0,0,0,0,0,1024 \
 --socket-limit 1024,0,0,0,0,0,0,0,1024 -l 0

Changes for v2:
0-day Robot suggested changes.

Signed-off-by: David Wilder 
---
 lib/dpdk.c | 26 ++
 lib/ovs-numa.c |  1 -
 lib/ovs-numa.h |  2 ++
 3 files changed, 20 insertions(+), 9 deletions(-)

diff --git a/lib/dpdk.c b/lib/dpdk.c
index 37ea2973c..5af6bb49b 100644
--- a/lib/dpdk.c
+++ b/lib/dpdk.c
@@ -134,18 +134,28 @@ static char *
 construct_dpdk_socket_mem(void)
 {
 const char *def_value = "1024";
-int numa, numa_nodes = ovs_numa_get_n_numas();
+struct ovs_numa_dump *dump;
+int last_node = 0;
+
+/* Build a list of all numa nodes with at least one core */
+dump = ovs_numa_dump_n_cores_per_numa(1);
 struct ds dpdk_socket_mem = DS_EMPTY_INITIALIZER;
+ds_put_cstr(&dpdk_socket_mem, def_value);
 
-if (numa_nodes == 0 || numa_nodes == OVS_NUMA_UNSPEC) {
-numa_nodes = 1;
-}
+const struct ovs_numa_info_numa *node;
 
-ds_put_cstr(&dpdk_socket_mem, def_value);
-for (numa = 1; numa < numa_nodes; ++numa) {
-ds_put_format(&dpdk_socket_mem, ",%s", def_value);
+FOR_EACH_NUMA_ON_DUMP(node, dump) {
+while (node->numa_id > last_node+1 &&
+   node->numa_id != OVS_NUMA_UNSPEC &&
+   node->numa_id <= MAX_NUMA_NODES){
+ds_put_format(&dpdk_socket_mem, ",%s", "0");
+++last_node;
+}
+if (node->numa_id != 0) {
+ds_put_format(&dpdk_socket_mem, ",%s", def_value);
+}
 }
-
+ovs_numa_dump_destroy(dump);
 return ds_cstr(&dpdk_socket_mem);
 }
 
diff --git a/lib/ovs-numa.c b/lib/ovs-numa.c
index 5153ed27e..8a76e6b5e 100644
--- a/lib/ovs-numa.c
+++ b/lib/ovs-numa.c
@@ -58,7 +58,6 @@ VLOG_DEFINE_THIS_MODULE(ovs_numa);
  * TODO: Fix ovs-numa when cpu hotplug is used.
  */
 
-#define MAX_NUMA_NODES 128
 
 /* numa node. */
 struct numa_node {
diff --git a/lib/ovs-numa.h b/lib/ovs-numa.h
index 8f2ea3430..ecc251a7f 100644
--- a/lib/ovs-numa.h
+++ b/lib/ovs-numa.h
@@ -26,6 +26,8 @@
 #define OVS_CORE_UNSPEC INT_MAX
 #define OVS_NUMA_UNSPEC INT_MAX
 
+#define MAX_NUMA_NODES 128
+
 /* Dump of a list of 'struct ovs_numa_info'. */
 struct ovs_numa_dump {
 struct hmap cores;
-- 
2.23.0.162.gf1d4a28

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

[ovs-dev] [PATCH v1 2/2] ovs-numa: Dpdk options with non-consecutive nodes.

2020-02-05 Thread David Wilder 
If not supplied by the user --socket-mem and --socket-limit EAL options
are set to a default value based system topology. The assumption that
numa nodes must be numbered consecutive is removed by this change.

These options can be seen in the ovs-vswitchd.log.  For example:
a system containing only numa nodes 0 and 8 will generate the following:

EAL ARGS: ovs-vswitchd --socket-mem 1024,0,0,0,0,0,0,0,1024 \
 --socket-limit 1024,0,0,0,0,0,0,0,1024 -l 0

Signed-off-by: David Wilder 
---
 lib/dpdk.c | 25 +
 lib/ovs-numa.c |  1 -
 lib/ovs-numa.h |  2 ++
 3 files changed, 19 insertions(+), 9 deletions(-)

diff --git a/lib/dpdk.c b/lib/dpdk.c
index 37ea2973c..954643018 100644
--- a/lib/dpdk.c
+++ b/lib/dpdk.c
@@ -134,18 +134,27 @@ static char *
 construct_dpdk_socket_mem(void)
 {
 const char *def_value = "1024";
-int numa, numa_nodes = ovs_numa_get_n_numas();
+struct ovs_numa_dump *dump;
+int last_node = 0;
+
+/* Build a list of all numa nodes with at least one core */
+dump = ovs_numa_dump_n_cores_per_numa(1);
 struct ds dpdk_socket_mem = DS_EMPTY_INITIALIZER;
+ds_put_cstr(&dpdk_socket_mem, def_value);
 
-if (numa_nodes == 0 || numa_nodes == OVS_NUMA_UNSPEC) {
-numa_nodes = 1;
-}
+const struct ovs_numa_info_numa *node;
 
-ds_put_cstr(&dpdk_socket_mem, def_value);
-for (numa = 1; numa < numa_nodes; ++numa) {
-ds_put_format(&dpdk_socket_mem, ",%s", def_value);
+FOR_EACH_NUMA_ON_DUMP(node, dump) {
+while (node->numa_id > last_node+1 &&
+   node->numa_id != OVS_NUMA_UNSPEC &&
+   node->numa_id <= MAX_NUMA_NODES){
+ds_put_format(&dpdk_socket_mem, ",%s", "0");
+++last_node;
+}
+if (node->numa_id != 0)
+ds_put_format(&dpdk_socket_mem, ",%s", def_value);
 }
-
+ovs_numa_dump_destroy(dump);
 return ds_cstr(&dpdk_socket_mem);
 }
 
diff --git a/lib/ovs-numa.c b/lib/ovs-numa.c
index da4754094..5b00739fa 100644
--- a/lib/ovs-numa.c
+++ b/lib/ovs-numa.c
@@ -58,7 +58,6 @@ VLOG_DEFINE_THIS_MODULE(ovs_numa);
  * TODO: Fix ovs-numa when cpu hotplug is used.
  */
 
-#define MAX_NUMA_NODES 128
 
 /* numa node. */
 struct numa_node {
diff --git a/lib/ovs-numa.h b/lib/ovs-numa.h
index 8f2ea3430..ecc251a7f 100644
--- a/lib/ovs-numa.h
+++ b/lib/ovs-numa.h
@@ -26,6 +26,8 @@
 #define OVS_CORE_UNSPEC INT_MAX
 #define OVS_NUMA_UNSPEC INT_MAX
 
+#define MAX_NUMA_NODES 128
+
 /* Dump of a list of 'struct ovs_numa_info'. */
 struct ovs_numa_dump {
 struct hmap cores;
-- 
2.23.0.162.gf1d4a28

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

[ovs-dev] [PATCH v1 0/2] Support for non-consecutive numa nodes and core ids.

2020-02-05 Thread David Wilder 
Ovs-numa currently makes the assumption that numa node ids and cpu core ids
will be numbered consecutively. Current Power systems don't always follow this
model. Furthermore, cpus on Power may be on/off lined based the setting of
Simultaneous multithreading (SMT). The result can be gaps in the numbering of
the cores. For example, a 2 socket system with 20 Core(s) per socket configured
with 4 thread per core (smt=4) has the following topology:

NUMA node0 CPU(s):   0-79
NUMA node8 CPU(s):   80-159

When set to smt=2 the following topology is created.

NUMA node0 CPU(s): 0,1,4,5,8,9,12,13,16,17,20,21,24,25,28,29,32,33,36,37,40,
   41,44,45,48,49,52,53,56,57,60,61,64,65,68,69,72,73,76,77
NUMA node8 CPU(s): 80,81,84,85,88,89,92,93,96,97,100,101,104,105,108,109,112,
   113,116,117,120,121,124,125,128,129,132,133,136,137,140,
   141,144,145,148,149,152,153,156,157

The first patch in this series allows ovs-numa to work with non-consecutive
node and cpu ids. I updated pmd and dpif-netdev multi-node tests to simulate
a numa topology with non-consecutive node ids.

The second patch in the series updates lib/dpdk:construct_dpdk_socket_mem()
to correctly build the EAL options: --socket-mem and --socket-limit on systems
with non-consecutive node ids.

A travis build with these two patches can be found here:
https://travis-ci.org/djlwilder/ovs/builds/646548843

David Wilder (2):
  ovs-numa: Non-consecutively numa nodes and cores
  ovs-numa: Dpdk options with non-consecutive nodes.

 lib/dpdk.c   | 25 +
 lib/ovs-numa.c   | 41 +++--
 lib/ovs-numa.h   |  2 ++
 tests/dpif-netdev.at | 12 ++--
 tests/pmd.at | 20 ++--
 5 files changed, 62 insertions(+), 38 deletions(-)

-- 
2.23.0.162.gf1d4a28

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

[ovs-dev] [PATCH v1 1/2] ovs-numa: Non-consecutively numa nodes and cores

2020-02-05 Thread David Wilder 
This change removes the assumption that numa nodes and cores are numbered
consecutively in linux.  This change is required to support some Power
systems.

An additional check has been added to verify that cores are online,
offline cores result in non-consecutively numbered cores.

I manually verified that all the exported functions defined in
ovs-numa.h function correctly with these changes on Power and amd64
systems.

Tests for dpif-netdev and pmd that define numa systems using the
--dummy-numa option have been modified to use non-consecutive numbered
nodes.

Signed-off-by: David Wilder 
---
 lib/ovs-numa.c   | 40 +++-
 tests/dpif-netdev.at | 12 ++--
 tests/pmd.at | 20 ++--
 3 files changed, 43 insertions(+), 29 deletions(-)

diff --git a/lib/ovs-numa.c b/lib/ovs-numa.c
index 6d0a68522..da4754094 100644
--- a/lib/ovs-numa.c
+++ b/lib/ovs-numa.c
@@ -42,16 +42,18 @@ VLOG_DEFINE_THIS_MODULE(ovs_numa);
  * This module stores the affinity information of numa nodes and cpu cores.
  * It also provides functions to bookkeep the pin of threads on cpu cores.
  *
- * It is assumed that the numa node ids and cpu core ids all start from 0 and
- * range continuously.  So, for example, if 'ovs_numa_get_n_cores()' returns N,
- * user can assume core ids from 0 to N-1 are all valid and there is a
- * 'struct cpu_core' for each id.
+ * It is assumed that the numa node ids and cpu core ids all start from 0.
+ * There is no guarantee that node and cpu ids are numbered consecutively
+ * (this is a change from earlier version of the code). So, for example,
+ * if two nodes exist with ids 0 and 8, 'ovs_numa_get_n_nodes()' will
+ * return 2, no assumption of node numbering should be made.
  *
  * NOTE, this module should only be used by the main thread.
  *
- * NOTE, the assumption above will fail when cpu hotplug is used.  In that
- * case ovs-numa will not function correctly.  For now, add a TODO entry
- * for addressing it in the future.
+ * NOTE, if cpu hotplug is used 'all_numa_nodes' and 'all_cpu_cores' must be
+ * invalidated when ever the system topology changes. Support for detecting
+ * topology changes has not been included. For now, add a TODO entry for
+ * addressing it in the future.
  *
  * TODO: Fix ovs-numa when cpu hotplug is used.
  */
@@ -169,11 +171,23 @@ discover_numa_and_core_dummy(void)
 
 free(conf);
 
-if (max_numa_id + 1 != hmap_count(&all_numa_nodes)) {
-ovs_fatal(0, "dummy numa contains non consecutive numa ids");
-}
 }
 
+#ifdef __linux__
+/* Check if a cpu is detected and online */
+static int
+cpu_detected(unsigned int core_id)
+{
+char *path;
+
+path = xasprintf("/sys/devices/system/cpu/cpu%d/topology/core_id", 
core_id);
+if (access(path, F_OK) != 0)
+return 0;
+
+return 1;
+}
+#endif /* __linux__ */
+
 /* Discovers all numa nodes and the corresponding cpu cores.
  * Constructs the 'struct numa_node' and 'struct cpu_core'. */
 static void
@@ -219,7 +233,8 @@ discover_numa_and_core(void)
 unsigned core_id;
 
 core_id = strtoul(subdir->d_name + 3, NULL, 10);
-insert_new_cpu_core(n, core_id);
+if (cpu_detected(core_id))
+insert_new_cpu_core(n, core_id);
 }
 }
 closedir(dir);
@@ -229,9 +244,8 @@ discover_numa_and_core(void)
 }
 
 free(path);
-if (!dir || !numa_supported) {
+if (!numa_supported)
 break;
-}
 }
 #endif /* __linux__ */
 }
diff --git a/tests/dpif-netdev.at b/tests/dpif-netdev.at
index 0aeb4e788..3a1a58276 100644
--- a/tests/dpif-netdev.at
+++ b/tests/dpif-netdev.at
@@ -94,7 +94,7 @@ m4_define([DPIF_NETDEV_DUMMY_IFACE],
  fail-mode=secure -- \
   add-port br1 p2 -- set interface p2 type=$1 
options:stream=unix:$OVS_RUNDIR/p0.sock ofport_request=2 -- \
   add-port br1 p8 -- set interface p8 ofport_request=8 type=$1 --], [], [],
-  [m4_if([$1], [dummy-pmd], [--dummy-numa="0,0,0,0,1,1,1,1"], [])])
+  [m4_if([$1], [dummy-pmd], [--dummy-numa="0,0,0,0,8,8,8,8"], [])])
AT_CHECK([ovs-appctl vlog/set dpif:dbg dpif_netdev:dbg])
 
AT_CHECK([ovs-ofctl add-flow br0 action=normal])
@@ -126,7 +126,7 @@ m4_define([DPIF_NETDEV_MISS_FLOW_INSTALL],
   -- set interface p1 type=$1 options:pstream=punix:$OVS_RUNDIR/p0.sock \
   -- set bridge br0 datapath-type=dummy \
 other-config:datapath-id=1234 fail-mode=secure], [], 
[],
-  [m4_if([$1], [dummy-pmd], [--dummy-numa="0,0,0,0,1,1,1,1"], [])])
+  [m4_if([$1], [dummy-pmd], [--dummy-numa="0,0,0,0,8,8,8,8"], [])])
AT_CHECK([ovs-appctl vlog/set dpif:dbg dpif_netdev:dbg])
 
AT_CHECK([ovs-ofctl add-flow br0 action=normal])
@@ -168,

[ovs-dev] [PATCH v4] travis: support ppc64le builds

2019-12-06 Thread David Wilder 
Add support for travis-ci ppc64le builds.

Updated matrix in .travis.yml to include an arch: ppc64le build.
To keep the total build time at an acceptable level only a single build
job is included in the matrix for ppc64le.

A build report example can be found here [1]
[0] http://travis-ci.org/
[1] https://travis-ci.org/djlwilder/ovs/builds/621795084

Signed-off-by: David Wilder 
Acked-by: William Tu 
---
This commit must be applied on top of Lance Yang's post:
[PATCH v2 2/3] travis: Move x86-only addon packages to linux-prepare.sh
Merging with Lance's other two patches should be easy.

 .travis.yml | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/.travis.yml b/.travis.yml
index 2dc4d436b..308c09635 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -50,6 +50,9 @@ matrix:
 - os: osx
   compiler: clang
   env: OPTS="--disable-ssl"
+- arch: ppc64le
+  compiler: gcc
+  env: OPTS="--disable-ssl"
 
 script: ./.travis/${TRAVIS_OS_NAME}-build.sh $OPTS
 
-- 
2.23.0.162.gf1d4a28

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

[ovs-dev] [PATCH v3] travis: support ppc64le builds

2019-11-06 Thread David Wilder 
Add support for travis-ci ppc64le builds.

- Updated matrix in .travis.yml to include an arch: ppc64le build.
- Move package install needed for 32bit builds to .travis/linux-prepare.sh.

To keep the total build time at an acceptable level only a single build
job is included in the matrix for ppc64le.

A build report example can be found here [1]
[0] http://travis-ci.org/
[1] https://travis-ci.org/djlwilder/ovs/builds/607851729

Signed-off-by: David Wilder 
---
Addressed review comments:
- Cleaned up linux-prepare.sh (v2)
- Switch from os: linux-ppc64le to arch: ppc64le (v3)

 .travis.yml  | 5 +++--
 .travis/linux-prepare.sh | 5 -
 2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/.travis.yml b/.travis.yml
index 482efd2d1..308c09635 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -14,7 +14,6 @@ addons:
   apt:
 packages:
   - bc
-  - gcc-multilib
   - libssl-dev
   - llvm-dev
   - libjemalloc1
@@ -26,7 +25,6 @@ addons:
   - libelf-dev
   - selinux-policy-dev
   - libunbound-dev
-  - libunbound-dev:i386
   - libunwind-dev
 
 before_install: ./.travis/${TRAVIS_OS_NAME}-prepare.sh
@@ -52,6 +50,9 @@ matrix:
 - os: osx
   compiler: clang
   env: OPTS="--disable-ssl"
+- arch: ppc64le
+  compiler: gcc
+  env: OPTS="--disable-ssl"
 
 script: ./.travis/${TRAVIS_OS_NAME}-build.sh $OPTS
 
diff --git a/.travis/linux-prepare.sh b/.travis/linux-prepare.sh
index 9e3ac0df7..d66f480c6 100755
--- a/.travis/linux-prepare.sh
+++ b/.travis/linux-prepare.sh
@@ -18,7 +18,10 @@ pip install --user --upgrade docutils
 if [ "$M32" ]; then
 # 32-bit and 64-bit libunwind can not be installed at the same time.
 # This will remove the 64-bit libunwind and install 32-bit version.
-sudo apt-get install -y libunwind-dev:i386
+sudo apt-get install -y \
+ gcc-multilib \
+ libunwind-dev:i386 \
+ libunbound-dev:i386
 fi
 
 # IPv6 is supported by kernel but disabled in TravisCI images:
-- 
2.23.0.162.gf1d4a28

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

[ovs-dev] [PATCH v2] travis: support ppc64le builds

2019-10-29 Thread David Wilder 
Add support for travis-ci ppc64le builds.

- Updated matrix in .travis.yml to include a ppc64le build.
- Move package install needed for 32bit builds to .travis/linux-prepare.sh.

To keep the total build time at an acceptable level only a single build
job is included in the matrix for ppc64le.

A build report example can be found here [1]
[0] http://travis-ci.org/
[1] https://travis-ci.org/djlwilder/ovs/builds/604615966

Signed-off-by: David Wilder 
---
 .travis.yml  | 5 +++--
 .travis/linux-prepare.sh | 5 -
 2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/.travis.yml b/.travis.yml
index 5676d9748..c99f26815 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -14,7 +14,6 @@ addons:
   apt:
 packages:
   - bc
-  - gcc-multilib
   - libssl-dev
   - llvm-dev
   - libjemalloc1
@@ -24,7 +23,6 @@ addons:
   - libelf-dev
   - selinux-policy-dev
   - libunbound-dev
-  - libunbound-dev:i386
   - libunwind-dev
 
 before_install: ./.travis/${TRAVIS_OS_NAME}-prepare.sh
@@ -50,6 +48,9 @@ matrix:
 - os: osx
   compiler: clang
   env: OPTS="--disable-ssl"
+- os: linux-ppc64le
+  compiler: gcc
+  env: OPTS="--disable-ssl"
 
 script: ./.travis/${TRAVIS_OS_NAME}-build.sh $OPTS
 
diff --git a/.travis/linux-prepare.sh b/.travis/linux-prepare.sh
index e546d32cb..299f9de99 100755
--- a/.travis/linux-prepare.sh
+++ b/.travis/linux-prepare.sh
@@ -18,5 +18,8 @@ pip install --user --upgrade docutils
 if [ "$M32" ]; then
 # 32-bit and 64-bit libunwind can not be installed at the same time.
 # This will remove the 64-bit libunwind and install 32-bit version.
-sudo apt-get install -y libunwind-dev:i386
+sudo apt-get install -y \
+ gcc-multilib \
+ libunwind-dev:i386 \
+ libunbound-dev:i386
 fi
-- 
2.23.0.162.gf1d4a28

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

[ovs-dev] [PATCH ] travis: support ppc64le builds

2019-10-28 Thread David Wilder 
Add support for travis-ci ppc64le builds.

- Updated matrix in .travis.yml to include a ppc64le build.
- Added support to install packages needed by specific architectures.

To keep the total build time at an acceptable level only a single build
job is included in the matrix for ppc64le.

A build report example can be found here [1]
[0] http://travis-ci.org/
[1] https://travis-ci.org/djlwilder/ovs/builds/604098141

Signed-off-by: David Wilder 
---
 .travis.yml  |  5 +++--
 .travis/linux-prepare.sh | 18 ++
 2 files changed, 17 insertions(+), 6 deletions(-)

diff --git a/.travis.yml b/.travis.yml
index 5676d9748..c99f26815 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -14,7 +14,6 @@ addons:
   apt:
 packages:
   - bc
-  - gcc-multilib
   - libssl-dev
   - llvm-dev
   - libjemalloc1
@@ -24,7 +23,6 @@ addons:
   - libelf-dev
   - selinux-policy-dev
   - libunbound-dev
-  - libunbound-dev:i386
   - libunwind-dev
 
 before_install: ./.travis/${TRAVIS_OS_NAME}-prepare.sh
@@ -50,6 +48,9 @@ matrix:
 - os: osx
   compiler: clang
   env: OPTS="--disable-ssl"
+- os: linux-ppc64le
+  compiler: gcc
+  env: OPTS="--disable-ssl"
 
 script: ./.travis/${TRAVIS_OS_NAME}-build.sh $OPTS
 
diff --git a/.travis/linux-prepare.sh b/.travis/linux-prepare.sh
index e546d32cb..f3a9a6d44 100755
--- a/.travis/linux-prepare.sh
+++ b/.travis/linux-prepare.sh
@@ -15,8 +15,18 @@ cd ..
 pip install --disable-pip-version-check --user six flake8 hacking
 pip install --user --upgrade docutils
 
-if [ "$M32" ]; then
-# 32-bit and 64-bit libunwind can not be installed at the same time.
-# This will remove the 64-bit libunwind and install 32-bit version.
-sudo apt-get install -y libunwind-dev:i386
+# Include packages needed by specific architectures.
+if [ $TRAVIS_ARCH == amd64 ]; then
+   sudo apt-get install -y \
+libunbound-dev:i386 \
+gcc-multilib
+
+if [ "$M32" ]; then
+   # 32-bit and 64-bit libunwind can not be installed at the same time.
+   # This will remove the 64-bit libunwind and install 32-bit version.
+   sudo apt-get install -y libunwind-dev:i386
+fi
+
+elif [ $TRAVIS_ARCH == ppc64le ]; then
+   sudo apt-get install -y flex
 fi
-- 
2.23.0.162.gf1d4a28

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

[ovs-dev] [PATCH lib: v2] Avoid clobbered variable warning on ppc64le.

2019-10-08 Thread David Wilder 
Since commit e2ed6fbeb1, Ci on ppc64le with Ubuntu 16.04.6 LTS throws
this error:

lib/fatal-signal.c: In function 'send_backtrace_to_monitor':
lib/fatal-signal.c:168:9: error: variable 'dep' might be clobbered by
'longjmp' or 'vfork' [-Werror=clobbered]
 int dep;

Declaring dep as a volatile int.

Signed-off-by: David Wilder 
---
v1->v2 Updated signed off by email address.

 lib/fatal-signal.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/lib/fatal-signal.c b/lib/fatal-signal.c
index 7733850d5..09f7c6ecf 100644
--- a/lib/fatal-signal.c
+++ b/lib/fatal-signal.c
@@ -165,7 +165,8 @@ fatal_signal_add_hook(void (*hook_cb)(void *aux), void 
(*cancel_cb)(void *aux),
  */
 static inline void
 send_backtrace_to_monitor(void) {
-int dep;
+/* volatile added to prevent a "clobbered" error on ppc64le with gcc */
+volatile int dep;
 struct unw_backtrace unw_bt[UNW_MAX_DEPTH];
 unw_cursor_t cursor;
 unw_context_t uc;
-- 
2.23.0.162.gf1d4a28

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

[ovs-dev] [PATCH lib:] Avoid clobbered variable warning on ppc64le.

2019-10-08 Thread David Wilder 
Since commit e2ed6fbeb1, Ci on ppc64le with Ubuntu 16.04.6 LTS throws
this error:

lib/fatal-signal.c: In function 'send_backtrace_to_monitor':
lib/fatal-signal.c:168:9: error: variable 'dep' might be clobbered by
'longjmp' or 'vfork' [-Werror=clobbered]
 int dep;

Declaring dep as a volatile int.

Signed-off-by: David Wilder 
---
 lib/fatal-signal.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/lib/fatal-signal.c b/lib/fatal-signal.c
index 7733850d5..09f7c6ecf 100644
--- a/lib/fatal-signal.c
+++ b/lib/fatal-signal.c
@@ -165,7 +165,8 @@ fatal_signal_add_hook(void (*hook_cb)(void *aux), void 
(*cancel_cb)(void *aux),
  */
 static inline void
 send_backtrace_to_monitor(void) {
-int dep;
+/* volatile added to prevent a "clobbered" error on ppc64le with gcc */
+volatile int dep;
 struct unw_backtrace unw_bt[UNW_MAX_DEPTH];
 unw_cursor_t cursor;
 unw_context_t uc;
-- 
2.23.0.162.gf1d4a28

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