[dpdk-dev] [PATCH v2 2/5] app/test-flow-perf: add insertion rate calculation
Add insertion rate calculation feature into flow
performance application.
The application now provide the ability to test
insertion rate of specific rte_flow rule, by
stressing it to the NIC, and calculate the
insertion rate.
The application offers some options in the command
line, to configure which rule to apply.
After that the application will start producing
rules with same pattern but increasing the outer IP
source address by 1 each time, thus it will give
different flow each time, and all other items will
have open masks.
The current design have single core insertion rate.
In the future we may have a multi core insertion
rate measurement support in the app.
Signed-off-by: Wisam Jaddo
---
app/test-flow-perf/Makefile | 3 +
app/test-flow-perf/actions_gen.c | 86 ++
app/test-flow-perf/actions_gen.h | 48
app/test-flow-perf/flow_gen.c| 176
app/test-flow-perf/flow_gen.h| 61
app/test-flow-perf/items_gen.c | 265 +
app/test-flow-perf/items_gen.h | 68 +
app/test-flow-perf/main.c| 416 +--
app/test-flow-perf/meson.build | 8 +
app/test-flow-perf/user_parameters.h | 15 +
doc/guides/tools/flow-perf.rst | 186 +++-
11 files changed, 1307 insertions(+), 25 deletions(-)
create mode 100644 app/test-flow-perf/actions_gen.c
create mode 100644 app/test-flow-perf/actions_gen.h
create mode 100644 app/test-flow-perf/flow_gen.c
create mode 100644 app/test-flow-perf/flow_gen.h
create mode 100644 app/test-flow-perf/items_gen.c
create mode 100644 app/test-flow-perf/items_gen.h
diff --git a/app/test-flow-perf/Makefile b/app/test-flow-perf/Makefile
index 45b1fb1464..968c7c60dd 100644
--- a/app/test-flow-perf/Makefile
+++ b/app/test-flow-perf/Makefile
@@ -19,6 +19,9 @@ CFLAGS += -Wno-unused-function
#
# all source are stored in SRCS-y
#
+SRCS-y += actions_gen.c
+SRCS-y += flow_gen.c
+SRCS-y += items_gen.c
SRCS-y += main.c
include $(RTE_SDK)/mk/rte.app.mk
diff --git a/app/test-flow-perf/actions_gen.c b/app/test-flow-perf/actions_gen.c
new file mode 100644
index 00..564ed820e4
--- /dev/null
+++ b/app/test-flow-perf/actions_gen.c
@@ -0,0 +1,86 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ *
+ * The file contains the implementations of actions generators.
+ * Each generator is responsible for preparing it's action instance
+ * and initializing it with needed data.
+ *
+ * Copyright 2020 Mellanox Technologies, Ltd
+ **/
+
+#include
+#include
+#include
+#include
+
+#include "actions_gen.h"
+#include "user_parameters.h"
+
+void
+gen_mark(void)
+{
+ mark_action.id = MARK_ID;
+}
+
+void
+gen_queue(uint16_t queue)
+{
+ queue_action.index = queue;
+}
+
+void
+gen_jump(uint16_t next_table)
+{
+ jump_action.group = next_table;
+}
+
+void
+gen_rss(uint16_t *queues, uint16_t queues_number)
+{
+ uint16_t queue;
+ struct action_rss_data *rss_data;
+ rss_data = rte_malloc("rss_data",
+ sizeof(struct action_rss_data), 0);
+
+ if (rss_data == NULL)
+ rte_exit(EXIT_FAILURE, "No Memory available!");
+
+ *rss_data = (struct action_rss_data){
+ .conf = (struct rte_flow_action_rss){
+ .func = RTE_ETH_HASH_FUNCTION_DEFAULT,
+ .level = 0,
+ .types = ETH_RSS_IP,
+ .key_len = 0,
+ .queue_num = queues_number,
+ .key = 0,
+ .queue = rss_data->queue,
+ },
+ .key = { 0 },
+ .queue = { 0 },
+ };
+
+ for (queue = 0; queue < queues_number; queue++)
+ rss_data->queue[queue] = queues[queue];
+
+ rss_action = &rss_data->conf;
+}
+
+void
+gen_set_meta(void)
+{
+ meta_action.data = RTE_BE32(META_DATA);
+ meta_action.mask = RTE_BE32(0x);
+}
+
+void
+gen_set_tag(void)
+{
+ tag_action.data = RTE_BE32(META_DATA);
+ tag_action.mask = RTE_BE32(0x);
+ tag_action.index = TAG_INDEX;
+}
+
+void
+gen_port_id(void)
+{
+ port_id.id = PORT_ID_DST;
+}
diff --git a/app/test-flow-perf/actions_gen.h b/app/test-flow-perf/actions_gen.h
new file mode 100644
index 00..556d48b871
--- /dev/null
+++ b/app/test-flow-perf/actions_gen.h
@@ -0,0 +1,48 @@
+/** SPDX-License-Identifier: BSD-3-Clause
+ *
+ * This file contains the functions definitions to
+ * generate each supported action.
+ *
+ * Copyright 2020 Mellanox Technologies, Ltd
+ **/
+
+#ifndef _ACTION_GEN_
+#define _ACTION_GEN_
+
+struct rte_flow_action_mark mark_action;
+struct rte_flow_action_queue queue_action;
+struct rte_flow_action_jump jump_action;
+struct rte_flow_action_rss *rss_action;
+struct rte_flow_action_set_meta meta_action;
+struct rte_flow_action_set_tag tag_action;
+struct rte_flow_action_port_id port_id;
+
+/* Storage for struct rte_flow_action_rss includi
[dpdk-dev] [PATCH v2 1/5] app/test-flow-perf: add flow performance skeleton
Add flow performance application skeleton.
Signed-off-by: Wisam Jaddo
---
MAINTAINERS | 5 +
app/Makefile | 1 +
app/meson.build | 1 +
app/test-flow-perf/Makefile | 26 +++
app/test-flow-perf/main.c| 246 +++
app/test-flow-perf/meson.build | 11 ++
app/test-flow-perf/user_parameters.h | 16 ++
config/common_base | 5 +
doc/guides/tools/flow-perf.rst | 69
doc/guides/tools/index.rst | 1 +
10 files changed, 381 insertions(+)
create mode 100644 app/test-flow-perf/Makefile
create mode 100644 app/test-flow-perf/main.c
create mode 100644 app/test-flow-perf/meson.build
create mode 100644 app/test-flow-perf/user_parameters.h
create mode 100644 doc/guides/tools/flow-perf.rst
diff --git a/MAINTAINERS b/MAINTAINERS
index d31a809292..b5632c1bf5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1504,6 +1504,11 @@ T: git://dpdk.org/next/dpdk-next-net
F: app/test-pmd/
F: doc/guides/testpmd_app_ug/
+Flow performance tool
+M: Wisam Jaddo
+F: app/test-flow-perf
+F: doc/guides/flow-perf.rst
+
Compression performance test application
T: git://dpdk.org/next/dpdk-next-crypto
F: app/test-compress-perf/
diff --git a/app/Makefile b/app/Makefile
index 823771c5fc..bd823f3db7 100644
--- a/app/Makefile
+++ b/app/Makefile
@@ -9,6 +9,7 @@ DIRS-$(CONFIG_RTE_PROC_INFO) += proc-info
DIRS-$(CONFIG_RTE_LIBRTE_PDUMP) += pdump
DIRS-$(CONFIG_RTE_LIBRTE_ACL) += test-acl
DIRS-$(CONFIG_RTE_LIBRTE_CMDLINE) += test-cmdline
+DIRS-$(CONFIG_RTE_TEST_FLOW_PERF) += test-flow-perf
DIRS-$(CONFIG_RTE_LIBRTE_FIB) += test-fib
DIRS-$(CONFIG_RTE_LIBRTE_PIPELINE) += test-pipeline
DIRS-$(CONFIG_RTE_LIBRTE_IPSEC) += test-sad
diff --git a/app/meson.build b/app/meson.build
index 0f7fe94649..e26f5b72f5 100644
--- a/app/meson.build
+++ b/app/meson.build
@@ -14,6 +14,7 @@ apps = [
'test-compress-perf',
'test-crypto-perf',
'test-eventdev',
+ 'test-flow-perf',
'test-fib',
'test-pipeline',
'test-pmd',
diff --git a/app/test-flow-perf/Makefile b/app/test-flow-perf/Makefile
new file mode 100644
index 00..45b1fb1464
--- /dev/null
+++ b/app/test-flow-perf/Makefile
@@ -0,0 +1,26 @@
+# SPDX-License-Identifier: BSD-3-Clause
+# Copyright 2020 Mellanox Technologies, Ltd
+
+include $(RTE_SDK)/mk/rte.vars.mk
+
+ifeq ($(CONFIG_RTE_TEST_FLOW_PERF),y)
+
+#
+# library name
+#
+APP = flow_perf
+
+CFLAGS += -DALLOW_EXPERIMENTAL_API
+CFLAGS += -O3
+CFLAGS += $(WERROR_FLAGS)
+CFLAGS += -Wno-deprecated-declarations
+CFLAGS += -Wno-unused-function
+
+#
+# all source are stored in SRCS-y
+#
+SRCS-y += main.c
+
+include $(RTE_SDK)/mk/rte.app.mk
+
+endif
diff --git a/app/test-flow-perf/main.c b/app/test-flow-perf/main.c
new file mode 100644
index 00..156b9ef553
--- /dev/null
+++ b/app/test-flow-perf/main.c
@@ -0,0 +1,246 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ *
+ * This file contain the application main file
+ * This application provides the user the ability to test the
+ * insertion rate for specific rte_flow rule under stress state ~4M rule/
+ *
+ * Then it will also provide packet per second measurement after installing
+ * all rules, the user may send traffic to test the PPS that match the rules
+ * after all rules are installed, to check performance or functionality after
+ * the stress.
+ *
+ * The flows insertion will go for all ports first, then it will print the
+ * results, after that the application will go into forwarding packets mode
+ * it will start receiving traffic if any and then forwarding it back and
+ * gives packet per second measurement.
+ *
+ * Copyright 2020 Mellanox Technologies, Ltd
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "user_parameters.h"
+
+static uint32_t nb_lcores;
+static struct rte_mempool *mbuf_mp;
+
+static void usage(char *progname)
+{
+ printf("\nusage: %s", progname);
+}
+
+static void
+args_parse(int argc, char **argv)
+{
+ char **argvopt;
+ int opt;
+ int opt_idx;
+ static struct option lgopts[] = {
+ /* Control */
+ { "help", 0, 0, 0 },
+ };
+
+ argvopt = argv;
+
+ while ((opt = getopt_long(argc, argvopt, "",
+ lgopts, &opt_idx)) != EOF) {
+ switch (opt) {
+ case 0:
+ if (!strcmp(lgopts[opt_idx].name, "help")) {
+ usage(argv[0]);
+ rte_exit(EXIT_SUCCESS, "Displayed help\n");
+ }
+ break;
+
[dpdk-dev] [PATCH v2 0/5] *** Introduce flow perf application ***
From: root Add new application to test rte flow performance from: - Insertion rate. - Deletion rate. - Memory consumption. - PPS forward measurement. --- v2: * reset cpu_time_used every port. * generate different RSS action every flow with different RETA. * Fix in commit log message Wisam Jaddo (5): app/test-flow-perf: add flow performance skeleton app/test-flow-perf: add insertion rate calculation app/test-flow-perf: add deletion rate calculation app/test-flow-perf: add memory dump to app app/test-flow-perf: add packet forwarding support MAINTAINERS |5 + app/Makefile |1 + app/meson.build |1 + app/test-flow-perf/Makefile | 29 + app/test-flow-perf/actions_gen.c | 86 +++ app/test-flow-perf/actions_gen.h | 48 ++ app/test-flow-perf/flow_gen.c| 176 + app/test-flow-perf/flow_gen.h| 61 ++ app/test-flow-perf/items_gen.c | 265 +++ app/test-flow-perf/items_gen.h | 68 ++ app/test-flow-perf/main.c| 1071 ++ app/test-flow-perf/meson.build | 19 + app/test-flow-perf/user_parameters.h | 31 + config/common_base |5 + doc/guides/tools/flow-perf.rst | 265 +++ doc/guides/tools/index.rst |1 + 16 files changed, 2132 insertions(+) create mode 100644 app/test-flow-perf/Makefile create mode 100644 app/test-flow-perf/actions_gen.c create mode 100644 app/test-flow-perf/actions_gen.h create mode 100644 app/test-flow-perf/flow_gen.c create mode 100644 app/test-flow-perf/flow_gen.h create mode 100644 app/test-flow-perf/items_gen.c create mode 100644 app/test-flow-perf/items_gen.h create mode 100644 app/test-flow-perf/main.c create mode 100644 app/test-flow-perf/meson.build create mode 100644 app/test-flow-perf/user_parameters.h create mode 100644 doc/guides/tools/flow-perf.rst -- 2.17.1
[dpdk-dev] [PATCH v2 3/5] app/test-flow-perf: add deletion rate calculation
Add the ability to test deletion rate for flow performance
application.
This feature is disabled by default, and can be enabled by
add "--deletion-rate" in the application command line options.
Signed-off-by: Wisam Jaddo
---
app/test-flow-perf/main.c | 86 ++
doc/guides/tools/flow-perf.rst | 4 ++
2 files changed, 90 insertions(+)
diff --git a/app/test-flow-perf/main.c b/app/test-flow-perf/main.c
index 115af4f302..7c11c0b577 100644
--- a/app/test-flow-perf/main.c
+++ b/app/test-flow-perf/main.c
@@ -62,6 +62,7 @@ static uint16_t flow_actions;
static uint8_t flow_attrs;
static volatile bool force_quit;
static volatile bool dump_iterations;
+static volatile bool delete_flag;
static struct rte_mempool *mbuf_mp;
static uint32_t nb_lcores;
static uint32_t flows_count;
@@ -75,6 +76,8 @@ static void usage(char *progname)
" flows to insert, default is 4,000,000\n");
printf(" --dump-iterations: To print rates for each"
" iteration\n");
+ printf(" --deletion-rate: Enable deletion rate"
+ " calculations\n");
printf("To set flow attributes:\n");
printf(" --ingress: set ingress attribute in flows\n");
@@ -123,6 +126,7 @@ args_parse(int argc, char **argv)
{ "help", 0, 0, 0 },
{ "flows-count",1, 0, 0 },
{ "dump-iterations",0, 0, 0 },
+ { "deletion-rate", 0, 0, 0 },
/* Attributes */
{ "ingress",0, 0, 0 },
{ "egress", 0, 0, 0 },
@@ -304,6 +308,8 @@ args_parse(int argc, char **argv)
}
if (!strcmp(lgopts[opt_idx].name, "dump-iterations"))
dump_iterations = true;
+ if (!strcmp(lgopts[opt_idx].name, "deletion-rate"))
+ delete_flag = true;
break;
default:
usage(argv[0]);
@@ -323,9 +329,75 @@ print_flow_error(struct rte_flow_error error)
error.message ? error.message : "(no stated reason)");
}
+static inline void
+destroy_flows(int port_id, struct rte_flow **flow_list)
+{
+ struct rte_flow_error error;
+ clock_t start_iter, end_iter;
+ double cpu_time_used = 0;
+ double flows_rate;
+ double cpu_time_per_iter[MAX_ITERATIONS];
+ double delta;
+ uint32_t i;
+ int iter_id;
+
+ for (i = 0; i < MAX_ITERATIONS; i++)
+ cpu_time_per_iter[i] = -1;
+
+ if (iterations_number > flows_count)
+ iterations_number = flows_count;
+
+ /* Deletion Rate */
+ printf("Flows Deletion on port = %d\n", port_id);
+ start_iter = clock();
+ for (i = 0; i < flows_count; i++) {
+ if (!flow_list[i])
+ break;
+
+ memset(&error, 0x33, sizeof(error));
+ if (rte_flow_destroy(port_id, flow_list[i], &error)) {
+ print_flow_error(error);
+ rte_exit(EXIT_FAILURE, "Error in deleting flow");
+ }
+
+ if (i && !((i + 1) % iterations_number)) {
+ /* Save the deletion rate of each iter */
+ end_iter = clock();
+ delta = (double) (end_iter - start_iter);
+ iter_id = ((i + 1) / iterations_number) - 1;
+ cpu_time_per_iter[iter_id] =
+ delta / CLOCKS_PER_SEC;
+ cpu_time_used += cpu_time_per_iter[iter_id];
+ start_iter = clock();
+ }
+ }
+
+ /* Deletion rate per iteration */
+ if (dump_iterations)
+ for (i = 0; i < MAX_ITERATIONS; i++) {
+ if (cpu_time_per_iter[i] == -1)
+ continue;
+ delta = (double)(iterations_number /
+ cpu_time_per_iter[i]);
+ flows_rate = delta / 1000;
+ printf(":: Iteration #%d: %d flows "
+ "in %f sec[ Rate = %f K/Sec ]\n",
+ i, iterations_number,
+ cpu_time_per_iter[i], flows_rate);
+ }
+
+ /* Deletion rate for all flows */
+ flows_rate = ((double) (flows_count / cpu_time_used) / 1000);
+ printf("\n:: Total flow deletion rate -> %f K/Sec\n",
+ flows_rate);
+ printf(":: The time for deleting %d in flows %f seconds\n",
+ flows_count, cpu_time_used);
+}
+
static inline void
flows_handler(void)
{
+ struct rte_flow **flow_list;
struct rte_flow_error error;
clock_t start_iter, end_iter;
double cpu_time_used;
@@ -33
[dpdk-dev] [PATCH v2 4/5] app/test-flow-perf: add memory dump to app
Introduce new feature to dump memory statistics of each socket
and a total for all before and after the creation.
This will give two main advantage:
1- Check the memory consumption for large number of flows
"insertion rate scenario alone"
2- Check that no memory leackage after doing insertion then
deletion.
Signed-off-by: Suanming Mou
Signed-off-by: Wisam Jaddo
---
app/test-flow-perf/main.c | 69 ++
doc/guides/tools/flow-perf.rst | 6 ++-
2 files changed, 74 insertions(+), 1 deletion(-)
diff --git a/app/test-flow-perf/main.c b/app/test-flow-perf/main.c
index 7c11c0b577..95435910de 100644
--- a/app/test-flow-perf/main.c
+++ b/app/test-flow-perf/main.c
@@ -62,6 +62,7 @@ static uint16_t flow_actions;
static uint8_t flow_attrs;
static volatile bool force_quit;
static volatile bool dump_iterations;
+static volatile bool dump_socket_mem_flag;
static volatile bool delete_flag;
static struct rte_mempool *mbuf_mp;
static uint32_t nb_lcores;
@@ -78,6 +79,7 @@ static void usage(char *progname)
" iteration\n");
printf(" --deletion-rate: Enable deletion rate"
" calculations\n");
+ printf(" --dump-socket-mem: to dump all socket memory\n");
printf("To set flow attributes:\n");
printf(" --ingress: set ingress attribute in flows\n");
@@ -127,6 +129,7 @@ args_parse(int argc, char **argv)
{ "flows-count",1, 0, 0 },
{ "dump-iterations",0, 0, 0 },
{ "deletion-rate", 0, 0, 0 },
+ { "dump-socket-mem",0, 0, 0 },
/* Attributes */
{ "ingress",0, 0, 0 },
{ "egress", 0, 0, 0 },
@@ -310,6 +313,8 @@ args_parse(int argc, char **argv)
dump_iterations = true;
if (!strcmp(lgopts[opt_idx].name, "deletion-rate"))
delete_flag = true;
+ if (!strcmp(lgopts[opt_idx].name, "dump-socket-mem"))
+ dump_socket_mem_flag = true;
break;
default:
usage(argv[0]);
@@ -321,6 +326,62 @@ args_parse(int argc, char **argv)
printf("end_flow\n");
}
+/* Dump the socket memory statistics on console */
+static size_t
+dump_socket_mem(FILE *f)
+{
+ struct rte_malloc_socket_stats socket_stats;
+ unsigned int i = 0;
+ size_t total = 0;
+ size_t alloc = 0;
+ size_t free = 0;
+ unsigned int n_alloc = 0;
+ unsigned int n_free = 0;
+ bool active_nodes = false;
+
+
+ for (i = 0; i < RTE_MAX_NUMA_NODES; i++) {
+ if (rte_malloc_get_socket_stats(i, &socket_stats) ||
+ !socket_stats.heap_totalsz_bytes)
+ continue;
+ active_nodes = true;
+ total += socket_stats.heap_totalsz_bytes;
+ alloc += socket_stats.heap_allocsz_bytes;
+ free += socket_stats.heap_freesz_bytes;
+ n_alloc += socket_stats.alloc_count;
+ n_free += socket_stats.free_count;
+ if (dump_socket_mem_flag) {
+ fprintf(f, "");
+ fprintf(f,
+ "\nSocket %u:\nsize(M) total: %.6lf\nalloc:"
+ " %.6lf(%.3lf%%)\nfree: %.6lf"
+ "\nmax: %.6lf"
+ "\ncount alloc: %u\nfree: %u\n",
+ i,
+ socket_stats.heap_totalsz_bytes / 1.0e6,
+ socket_stats.heap_allocsz_bytes / 1.0e6,
+ (double)socket_stats.heap_allocsz_bytes * 100 /
+ (double)socket_stats.heap_totalsz_bytes,
+ socket_stats.heap_freesz_bytes / 1.0e6,
+ socket_stats.greatest_free_size / 1.0e6,
+ socket_stats.alloc_count,
+ socket_stats.free_count);
+ fprintf(f,
"");
+ }
+ }
+ if (dump_socket_mem_flag && active_nodes) {
+ fprintf(f,
+ "\nTotal: size(M)\ntotal: %.6lf"
+ "\nalloc: %.6lf(%.3lf%%)\nfree: %.6lf"
+ "\ncount alloc: %u\nfree: %u\n",
+ total / 1.0e6, alloc / 1.0e6,
+ (double)alloc * 100 / (double)total, free / 1.0e6,
+ n_alloc, n_free);
+ fprintf(f, "\n");
+ }
+ return alloc;
+}
+
static void
print_flow_error(struct rte_flow_error error)
{
@@ -657,6 +718,7 @@ main(int argc,
[dpdk-dev] [PATCH v2 5/5] app/test-flow-perf: add packet forwarding support
Introduce packet forwarding support to the app to do
some performance measurements.
The measurements are reported in term of packet per
second unit. The forwarding will start after the end
of insertion/deletion operations.
The support has single and multi core performance measurements.
Signed-off-by: Wisam Jaddo
---
app/test-flow-perf/main.c | 300 +
doc/guides/tools/flow-perf.rst | 6 +
2 files changed, 306 insertions(+)
diff --git a/app/test-flow-perf/main.c b/app/test-flow-perf/main.c
index 95435910de..2596d05dc2 100644
--- a/app/test-flow-perf/main.c
+++ b/app/test-flow-perf/main.c
@@ -60,14 +60,45 @@ static uint8_t flow_group;
static uint16_t flow_items;
static uint16_t flow_actions;
static uint8_t flow_attrs;
+
static volatile bool force_quit;
static volatile bool dump_iterations;
static volatile bool dump_socket_mem_flag;
static volatile bool delete_flag;
+static volatile bool enable_fwd;
+
static struct rte_mempool *mbuf_mp;
static uint32_t nb_lcores;
static uint32_t flows_count;
static uint32_t iterations_number;
+static uint32_t nb_lcores;
+
+#define MAX_PKT_BURST 32
+#define LCORE_MODE_PKT 1
+#define LCORE_MODE_STATS 2
+#define MAX_STREAMS 64
+#define MAX_LCORES 64
+
+struct stream {
+ int tx_port;
+ int tx_queue;
+ int rx_port;
+ int rx_queue;
+};
+
+struct lcore_info {
+ int mode;
+ int streams_nb;
+ struct stream streams[MAX_STREAMS];
+ /* stats */
+ uint64_t tx_pkts;
+ uint64_t tx_drops;
+ uint64_t rx_pkts;
+ struct rte_mbuf *pkts[MAX_PKT_BURST];
+} __attribute__((__aligned__(64))); /* let it be cacheline aligned */
+
+
+static struct lcore_info lcore_infos[MAX_LCORES];
static void usage(char *progname)
{
@@ -80,6 +111,8 @@ static void usage(char *progname)
printf(" --deletion-rate: Enable deletion rate"
" calculations\n");
printf(" --dump-socket-mem: to dump all socket memory\n");
+ printf(" --enable-fwd: to enable packets forwarding"
+ " after insertion\n");
printf("To set flow attributes:\n");
printf(" --ingress: set ingress attribute in flows\n");
@@ -130,6 +163,7 @@ args_parse(int argc, char **argv)
{ "dump-iterations",0, 0, 0 },
{ "deletion-rate", 0, 0, 0 },
{ "dump-socket-mem",0, 0, 0 },
+ { "enable-fwd", 0, 0, 0 },
/* Attributes */
{ "ingress",0, 0, 0 },
{ "egress", 0, 0, 0 },
@@ -315,6 +349,8 @@ args_parse(int argc, char **argv)
delete_flag = true;
if (!strcmp(lgopts[opt_idx].name, "dump-socket-mem"))
dump_socket_mem_flag = true;
+ if (!strcmp(lgopts[opt_idx].name, "enable-fwd"))
+ enable_fwd = true;
break;
default:
usage(argv[0]);
@@ -582,6 +618,265 @@ signal_handler(int signum)
}
}
+static inline uint16_t
+do_rx(struct lcore_info *li, uint16_t rx_port, uint16_t rx_queue)
+{
+ uint16_t cnt = 0;
+ cnt = rte_eth_rx_burst(rx_port, rx_queue, li->pkts, MAX_PKT_BURST);
+ li->rx_pkts += cnt;
+ return cnt;
+}
+
+static inline void
+do_tx(struct lcore_info *li, uint16_t cnt, uint16_t tx_port,
+ uint16_t tx_queue)
+{
+ uint16_t nr_tx = 0;
+ uint16_t i;
+
+ nr_tx = rte_eth_tx_burst(tx_port, tx_queue, li->pkts, cnt);
+ li->tx_pkts += nr_tx;
+ li->tx_drops += cnt - nr_tx;
+
+ for (i = nr_tx; i < cnt; i++)
+ rte_pktmbuf_free(li->pkts[i]);
+}
+
+/*
+ * Method to convert numbers into pretty numbers that easy
+ * to read. The design here is to add comma after each three
+ * digits and set all of this inside buffer.
+ *
+ * For example if n = 1799321, the output will be
+ * 1,799,321 after this method which is easier to read.
+ */
+static char *
+pretty_number(uint64_t n, char *buf)
+{
+ char p[6][4];
+ int i = 0;
+ int off = 0;
+
+ while (n > 1000) {
+ sprintf(p[i], "%03d", (int)(n % 1000));
+ n /= 1000;
+ i += 1;
+ }
+
+ sprintf(p[i++], "%d", (int)n);
+
+ while (i--)
+ off += sprintf(buf + off, "%s,", p[i]);
+ buf[strlen(buf) - 1] = '\0';
+
+ return buf;
+}
+
+static void
+packet_per_second_stats(void)
+{
+ struct lcore_info *old;
+ struct lcore_info *li, *oli;
+ int nr_lines = 0;
+ int i;
+
+ old = rte_zmalloc("old",
+ sizeof(struct lcore_info) * MAX_LCORES, 0);
+ if (old == NULL)
+ rte_exit(EXIT_FAILURE, "No Memory available!");
+
+ memcpy(old, lcore_infos,
+ sizeof(struct lcore_info) * MAX_LCORES)
Re: [dpdk-dev] [PATCH v1] vhost: fix mbuf allocation failures
Hi Flavio, Thanks for your comments. snipped > > The patch fixes the error scenario by skipping to next descriptor. > > Note: Drop counters are not currently supported. In that case shouldn't we continue to process the ring? Yes, we are updating the loop index and following the required clean-up. Also, don't we have the same issue with copy_desc_to_mbuf() Thank you. Will update in the V2 patch. and get_zmbuf()? This patch is not targeted for zero-copy cases. fbl snipped
Re: [dpdk-dev] [PATCH] net/iavf: fix link speed
Tested-by: Xie,WeiX < weix@intel.com>
Regards,
Xie Wei
-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of alvinx.zh...@intel.com
Sent: Tuesday, April 28, 2020 2:49 PM
To: dev@dpdk.org
Cc: Zhang, Qi Z ; Xing, Beilei ;
Zhang, AlvinX ; Wu, Jingjing
Subject: [dpdk-dev] [PATCH] net/iavf: fix link speed
From: Alvin Zhang
If the PF driver does not support the new speed reporting capabilities then use
link_event else use link_event_adv to get the speed.
Fixes: 48de41ca11f0 (net/iavf: enable link status update)
Cc: jingjing...@intel.com
Signed-off-by: Alvin Zhang
---
drivers/net/iavf/iavf_vchnl.c | 47 ++-
1 file changed, 46 insertions(+), 1 deletion(-)
diff --git a/drivers/net/iavf/iavf_vchnl.c b/drivers/net/iavf/iavf_vchnl.c
index 2a0cdd9..104a769 100644
--- a/drivers/net/iavf/iavf_vchnl.c
+++ b/drivers/net/iavf/iavf_vchnl.c
@@ -130,6 +130,44 @@
return err;
}
+static uint32_t
+iavf_convert_link_speed(uint32_t virt_link_speed) {
+ uint32_t speed;
+
+ switch (virt_link_speed) {
+ case VIRTCHNL_LINK_SPEED_100MB:
+ speed = 100;
+ break;
+ case VIRTCHNL_LINK_SPEED_1GB:
+ speed = 1000;
+ break;
+ case VIRTCHNL_LINK_SPEED_10GB:
+ speed = 1;
+ break;
+ case VIRTCHNL_LINK_SPEED_40GB:
+ speed = 4;
+ break;
+ case VIRTCHNL_LINK_SPEED_20GB:
+ speed = 2;
+ break;
+ case VIRTCHNL_LINK_SPEED_25GB:
+ speed = 25000;
+ break;
+ case VIRTCHNL_LINK_SPEED_2_5GB:
+ speed = 2500;
+ break;
+ case VIRTCHNL_LINK_SPEED_5GB:
+ speed = 5000;
+ break;
+ default:
+ speed = 0;
+ break;
+ }
+
+ return speed;
+}
+
static void
iavf_handle_pf_event_msg(struct rte_eth_dev *dev, uint8_t *msg,
uint16_t msglen)
@@ -151,7 +189,14 @@
case VIRTCHNL_EVENT_LINK_CHANGE:
PMD_DRV_LOG(DEBUG, "VIRTCHNL_EVENT_LINK_CHANGE event");
vf->link_up = pf_msg->event_data.link_event.link_status;
- vf->link_speed = pf_msg->event_data.link_event_adv.link_speed;
+ if (vf->vf_res->vf_cap_flags & VIRTCHNL_VF_CAP_ADV_LINK_SPEED) {
+ vf->link_speed =
+ pf_msg->event_data.link_event_adv.link_speed;
+ } else {
+ enum virtchnl_link_speed speed;
+ speed = pf_msg->event_data.link_event.link_speed;
+ vf->link_speed = iavf_convert_link_speed(speed);
+ }
iavf_dev_link_update(dev, 0);
_rte_eth_dev_callback_process(dev, RTE_ETH_EVENT_INTR_LSC,
NULL);
--
1.8.3.1
Re: [dpdk-dev] [PATCH 2/2] eal: add fnmatch implementation on Windows
On 2020-04-30 08:52 GMT+0200 Thomas Monjalon wrote: > 30/04/2020 01:24, Pallavi Kadam: > > Added fnmatch implementation on Windows to support > > log level arguments. > > The source file is with BSD-3-Clause license. > > https://github.com/lattera/freebsd/blob/master/usr.bin/csup/fnmatch.c > > Sorry for the naive question, I don't know Windows programming. > > Do we really need this external code? > Why RtlIsNameInExpression from Windows cannot be used? > https://docs.microsoft.com/en-us/windows/win32/devnotes/rtlisnameinexpression The general reason not to use Win32 API for globbing is poorly documented contract: what are the exact matching rules? They're definitely incompatible with fnmatch(3). IMO small external code is better than unknown behavior. RtlIsNameInExpression is an internal call for drivers and services with a cumbersome API. PathMatchSpecA is the user-mode interface, but see above. https://docs.microsoft.com/en-us/windows/win32/api/shlwapi/nf-shlwapi-pathmatchspeca -- Dmitry Kozlyuk
Re: [dpdk-dev] [PATCH v4] ethdev: support flow aging
Hi Tom
From: Tom Barbette
> Great news!
>
> - I can understand why there is no timeout unit. But that's calling for user
> nightmare. Eg I could only get from the code (and not from documentation
> yet? ) of the following mlx5 driver patch that the value should be in tenth of
> seconds. If I build an application that is supposed to work with "any NIC",
> what can I do? We'd need a way to query the timeout unit (have it in
> dev_info probably).
Please see the new age action structure in rte_flow.h
You can see comments there that timeout units is in seconds
> - It's not totally clear if the rule is automatically removed or not. is this
> a
> helper or an OpenFlow-like notification?
Only notification, the aged-out flow should be destroyed (or other action) by
the application according to the application needs...
> - Find a typo and grammar fix inline.
> - Recently, Mellanox introduced the ability to create 330K flows/s. Any
> performance considerations if those flow "expire" at the same rate?
We didn't see performance impact (should be same rate like count action).
>
> Hope it's helpfull,
>
> Tom
>
> Le 21/04/2020 à 12:11, Bill Zhou a écrit :
> > From: Dong Zhou
> >
> > One of the reasons to destroy a flow is the fact that no packet
> > matches the flow for "timeout" time.
> > For example, when TCP\UDP sessions are suddenly closed.
> >
> > Currently, there is not any DPDK mechanism for flow aging and the
> > applications use their own ways to detect and destroy aged-out flows.
> >
> > The flow aging implementation need include:
> > - A new rte_flow action: RTE_FLOW_ACTION_TYPE_AGE to set the timeout
> and
> >the application flow context for each flow.
> > - A new ethdev event: RTE_ETH_EVENT_FLOW_AGED for the driver to
> report
> >that there are new aged-out flows.
> > - A new rte_flow API: rte_flow_get_aged_flows to get the aged-out flows
> >contexts from the port.
> > - Support input flow aging command line in Testpmd.
> >
> > The new event type addition in the enum is flagged as an ABI breakage,
> > so an ignore rule is added for these reasons:
> > - It is not changing value of existing types (except MAX)
> > - The new value is not used by existing API if the event is not
> > registered In general, it is safe adding new ethdev event types at the
> > end of the enum, because of event callback registration mechanism.
> >
> > Signed-off-by: Dong Zhou
> > ---
> > v2: Removing "* Added support for flow Aging mechanism base on
> counter."
> > this line from doc/guides/rel_notes/release_20_05.rst, this patch does
> > not include this support.
> >
> > v3: Update file libabigail.abignore, add one new suppressed
> > enumeration type for RTE_ETH_EVENT_MAX.
> >
> > v4: Add justification in devtools/libabigail.abignore and in the
> > commit log about the modification of v3.
> > ---
> > app/test-pmd/cmdline_flow.c | 26 ++
> > devtools/libabigail.abignore | 6 +++
> > doc/guides/prog_guide/rte_flow.rst | 22 +
> > doc/guides/rel_notes/release_20_05.rst | 11 +
> > lib/librte_ethdev/rte_ethdev.h | 1 +
> > lib/librte_ethdev/rte_ethdev_version.map | 3 ++
> > lib/librte_ethdev/rte_flow.c | 18 +++
> > lib/librte_ethdev/rte_flow.h | 62
> > lib/librte_ethdev/rte_flow_driver.h | 6 +++
> > 9 files changed, 155 insertions(+)
> >
> > diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
> > index e6ab8ff2f7..45bcff3cf5 100644
> > --- a/app/test-pmd/cmdline_flow.c
> > +++ b/app/test-pmd/cmdline_flow.c
> > @@ -343,6 +343,8 @@ enum index {
> > ACTION_SET_IPV4_DSCP_VALUE,
> > ACTION_SET_IPV6_DSCP,
> > ACTION_SET_IPV6_DSCP_VALUE,
> > + ACTION_AGE,
> > + ACTION_AGE_TIMEOUT,
> > };
> >
> > /** Maximum size for pattern in struct rte_flow_item_raw. */ @@
> > -1145,6 +1147,7 @@ static const enum index next_action[] = {
> > ACTION_SET_META,
> > ACTION_SET_IPV4_DSCP,
> > ACTION_SET_IPV6_DSCP,
> > + ACTION_AGE,
> > ZERO,
> > };
> >
> > @@ -1370,6 +1373,13 @@ static const enum index action_set_ipv6_dscp[]
> = {
> > ZERO,
> > };
> >
> > +static const enum index action_age[] = {
> > + ACTION_AGE,
> > + ACTION_AGE_TIMEOUT,
> > + ACTION_NEXT,
> > + ZERO,
> > +};
> > +
> > static int parse_set_raw_encap_decap(struct context *, const struct
> token *,
> > const char *, unsigned int,
> > void *, unsigned int);
> > @@ -3694,6 +3704,22 @@ static const struct token token_list[] = {
> > (struct rte_flow_action_set_dscp, dscp)),
> > .call = parse_vc_conf,
> > },
> > + [ACTION_AGE] = {
> > + .name = "age",
> > + .help = "set a specific metadata header",
> > + .next = NEXT(action_age),
> > + .priv = PRIV_ACTION(AGE,
> > + sizeof(struct rte_flow_action_ag
Re: [dpdk-dev] [PATCH] net/ice: fix core dumped issue in switch filter
Hi Qiming, > -Original Message- > From: Yang, Qiming > Sent: Thursday, April 30, 2020 2:53 PM > To: Jiang, JunyuX ; dev@dpdk.org > Cc: sta...@dpdk.org > Subject: RE: [PATCH] net/ice: fix core dumped issue in switch filter > > Hi, > I don't understand your fix log, which pointer is NULL? > The act_qgrop->queue is NULL if act_qgrop->queue_num is 0. Thanks Junyu
Re: [dpdk-dev] [PATCH v4] ethdev: support flow aging
Le 30/04/2020 à 09:36, Matan Azrad a écrit :
Hi Tom
From: Tom Barbette
Great news!
- I can understand why there is no timeout unit. But that's calling for user
nightmare. Eg I could only get from the code (and not from documentation
yet? ) of the following mlx5 driver patch that the value should be in tenth of
seconds. If I build an application that is supposed to work with "any NIC",
what can I do? We'd need a way to query the timeout unit (have it in
dev_info probably).
Please see the new age action structure in rte_flow.h
You can see comments there that timeout units is in seconds
Oh okay, did not catch that. Maybe mention of the unit in the AGE action
documentation of rte_flow.rst would be helpful.
- It's not totally clear if the rule is automatically removed or not. is this a
helper or an OpenFlow-like notification?
Only notification, the aged-out flow should be destroyed (or other action) by
the application according to the application needs...
Makes sense.
- Find a typo and grammar fix inline.
- Recently, Mellanox introduced the ability to create 330K flows/s. Any
performance considerations if those flow "expire" at the same rate?
We didn't see performance impact (should be same rate like count action).
Ok great!
Thanks!
Hope it's helpfull,
Tom
Le 21/04/2020 à 12:11, Bill Zhou a écrit :
From: Dong Zhou
One of the reasons to destroy a flow is the fact that no packet
matches the flow for "timeout" time.
For example, when TCP\UDP sessions are suddenly closed.
Currently, there is not any DPDK mechanism for flow aging and the
applications use their own ways to detect and destroy aged-out flows.
The flow aging implementation need include:
- A new rte_flow action: RTE_FLOW_ACTION_TYPE_AGE to set the timeout
and
the application flow context for each flow.
- A new ethdev event: RTE_ETH_EVENT_FLOW_AGED for the driver to
report
that there are new aged-out flows.
- A new rte_flow API: rte_flow_get_aged_flows to get the aged-out flows
contexts from the port.
- Support input flow aging command line in Testpmd.
The new event type addition in the enum is flagged as an ABI breakage,
so an ignore rule is added for these reasons:
- It is not changing value of existing types (except MAX)
- The new value is not used by existing API if the event is not
registered In general, it is safe adding new ethdev event types at the
end of the enum, because of event callback registration mechanism.
Signed-off-by: Dong Zhou
---
v2: Removing "* Added support for flow Aging mechanism base on
counter."
this line from doc/guides/rel_notes/release_20_05.rst, this patch does
not include this support.
v3: Update file libabigail.abignore, add one new suppressed
enumeration type for RTE_ETH_EVENT_MAX.
v4: Add justification in devtools/libabigail.abignore and in the
commit log about the modification of v3.
---
app/test-pmd/cmdline_flow.c | 26 ++
devtools/libabigail.abignore | 6 +++
doc/guides/prog_guide/rte_flow.rst | 22 +
doc/guides/rel_notes/release_20_05.rst | 11 +
lib/librte_ethdev/rte_ethdev.h | 1 +
lib/librte_ethdev/rte_ethdev_version.map | 3 ++
lib/librte_ethdev/rte_flow.c | 18 +++
lib/librte_ethdev/rte_flow.h | 62
lib/librte_ethdev/rte_flow_driver.h | 6 +++
9 files changed, 155 insertions(+)
diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
index e6ab8ff2f7..45bcff3cf5 100644
--- a/app/test-pmd/cmdline_flow.c
+++ b/app/test-pmd/cmdline_flow.c
@@ -343,6 +343,8 @@ enum index {
ACTION_SET_IPV4_DSCP_VALUE,
ACTION_SET_IPV6_DSCP,
ACTION_SET_IPV6_DSCP_VALUE,
+ ACTION_AGE,
+ ACTION_AGE_TIMEOUT,
};
/** Maximum size for pattern in struct rte_flow_item_raw. */ @@
-1145,6 +1147,7 @@ static const enum index next_action[] = {
ACTION_SET_META,
ACTION_SET_IPV4_DSCP,
ACTION_SET_IPV6_DSCP,
+ ACTION_AGE,
ZERO,
};
@@ -1370,6 +1373,13 @@ static const enum index action_set_ipv6_dscp[]
= {
ZERO,
};
+static const enum index action_age[] = {
+ ACTION_AGE,
+ ACTION_AGE_TIMEOUT,
+ ACTION_NEXT,
+ ZERO,
+};
+
static int parse_set_raw_encap_decap(struct context *, const struct
token *,
const char *, unsigned int,
void *, unsigned int);
@@ -3694,6 +3704,22 @@ static const struct token token_list[] = {
(struct rte_flow_action_set_dscp, dscp)),
.call = parse_vc_conf,
},
+ [ACTION_AGE] = {
+ .name = "age",
+ .help = "set a specific metadata header",
+ .next = NEXT(action_age),
+ .priv = PRIV_ACTION(AGE,
+ sizeof(struct rte_flow_action_age)),
+ .call = parse_vc,
+ },
+ [ACTI
[dpdk-dev] [PATCH v3] net/axgbe: enabling VLAN support in axgbe
From: Sardar Shamsher Singh adding below APIs for axgbe - axgbe_enable_rx_vlan_stripping: to enable vlan header stipping - axgbe_disable_rx_vlan_stripping: to disable vlan header stipping - axgbe_enable_rx_vlan_filtering: to enable vlan filter mode - axgbe_disable_rx_vlan_filtering: to disable vlan filter mode - axgbe_update_vlan_hash_table: crc calculation and hash table update based on vlan values post filter enable - axgbe_vlan_filter_set: setting of active vlan out of max 4K values before doing hash update of same - axgbe_vlan_tpid_set: setting of default tpid values - axgbe_vlan_offload_set: a top layer function to call stip/filter etc based on mask values Signed-off-by: Sardar Shamsher Singh --- doc/guides/nics/features/axgbe.ini | 1 + drivers/net/axgbe/axgbe_common.h | 29 + drivers/net/axgbe/axgbe_dev.c | 171 ++-- drivers/net/axgbe/axgbe_ethdev.c | 173 - drivers/net/axgbe/axgbe_ethdev.h | 16 +++ drivers/net/axgbe/axgbe_rxtx.c | 63 ++- 6 files changed, 437 insertions(+), 16 deletions(-) diff --git a/doc/guides/nics/features/axgbe.ini b/doc/guides/nics/features/axgbe.ini index 0becaa097..b7b4dd992 100644 --- a/doc/guides/nics/features/axgbe.ini +++ b/doc/guides/nics/features/axgbe.ini @@ -11,6 +11,7 @@ Scattered Rx = Y Promiscuous mode = Y Allmulticast mode= Y RSS hash = Y +VLAN = Y CRC offload = Y L3 checksum offload = Y L4 checksum offload = Y diff --git a/drivers/net/axgbe/axgbe_common.h b/drivers/net/axgbe/axgbe_common.h index f48117180..283cbffaa 100644 --- a/drivers/net/axgbe/axgbe_common.h +++ b/drivers/net/axgbe/axgbe_common.h @@ -257,6 +257,7 @@ #define MAC_HWF0R 0x011c #define MAC_HWF1R 0x0120 #define MAC_HWF2R 0x0124 +#define MAC_HWF3R 0x0128 #define MAC_MDIOSCAR 0x0200 #define MAC_MDIOSCCDR 0x0204 #define MAC_MDIOISR0x0214 @@ -282,6 +283,18 @@ #define MAC_TXSNR 0x0d30 #define MAC_TXSSR 0x0d34 +/*VLAN control bit mask*/ +#define AXGBE_VLNCTRL_MASK 0x +#define VLAN_PRIO_MASK 0xe000 /* Priority Code Point */ +#define VLAN_PRIO_SHIFT13 +#define VLAN_CFI_MASK 0x1000 /* Canonical Format Indicator */ +#define VLAN_TAG_PRESENT VLAN_CFI_MASK +#define VLAN_VID_MASK 0x0fff /* VLAN Identifier */ +#define VLAN_N_VID 4096 +#define VLAN_TABLE_SIZE64 +#define VLAN_TABLE_BIT(vlan_id)(1UL << ((vlan_id) & 0x3F)) +#define VLAN_TABLE_IDX(vlan_id)((vlan_id) >> 6) + #define MAC_QTFCR_INC 4 #define MAC_MACA_INC 4 #define MAC_HTR_INC4 @@ -359,6 +372,10 @@ #define MAC_HWF2R_TXCHCNT_WIDTH4 #define MAC_HWF2R_TXQCNT_INDEX 6 #define MAC_HWF2R_TXQCNT_WIDTH 4 +#define MAC_HWF3R_CBTISEL_INDEX4 +#define MAC_HWF3R_CBTISEL_WIDTH1 +#define MAC_HWF3R_NRVF_INDEX 0 +#define MAC_HWF3R_NRVF_WIDTH 3 #define MAC_IER_TSIE_INDEX 12 #define MAC_IER_TSIE_WIDTH 1 #define MAC_ISR_MMCRXIS_INDEX 9 @@ -513,6 +530,8 @@ #define MAC_VLANIR_VLTI_WIDTH 1 #define MAC_VLANIR_CSVL_INDEX 19 #define MAC_VLANIR_CSVL_WIDTH 1 +#define MAC_VLANIR_VLC_INDEX 16 +#define MAC_VLANIR_VLC_WIDTH 2 #define MAC_VLANTR_DOVLTC_INDEX20 #define MAC_VLANTR_DOVLTC_WIDTH1 #define MAC_VLANTR_ERSVLM_INDEX19 @@ -523,12 +542,18 @@ #define MAC_VLANTR_ETV_WIDTH 1 #define MAC_VLANTR_EVLS_INDEX 21 #define MAC_VLANTR_EVLS_WIDTH 2 +#define MAC_VLANTR_EIVLS_INDEX 21 +#define MAC_VLANTR_EIVLS_WIDTH 2 #define MAC_VLANTR_EVLRXS_INDEX24 #define MAC_VLANTR_EVLRXS_WIDTH1 +#define MAC_VLANTR_EIVLRXS_INDEX 31 +#define MAC_VLANTR_EIVLRXS_WIDTH 1 #define MAC_VLANTR_VL_INDEX0 #define MAC_VLANTR_VL_WIDTH16 #define MAC_VLANTR_VTHM_INDEX 25 #define MAC_VLANTR_VTHM_WIDTH 1 +#define MAC_VLANTR_EDVLP_INDEX 26 +#define MAC_VLANTR_EDVLP_WIDTH 1 #define MAC_VLANTR_VTIM_INDEX 17 #define MAC_VLANTR_VTIM_WIDTH 1 #define MAC_VR_DEVID_INDEX 8 @@ -537,6 +562,10 @@ #define MAC_VR_SNPSVER_WIDTH 8 #define MAC_VR_USERVER_INDEX 16 #define MAC_VR_USERVER_WIDTH 8 +#define MAC_VLANIR_VLT_INDEX 0 +#define MAC_VLANIR_VLT_WIDTH 16 +#define MAC_VLANTR_ERIVLT_INDEX27 +#define MAC_VLANTR_ERIVLT_WIDTH1 /* MMC register offsets */ #define MMC_CR
Re: [dpdk-dev] [PATCH v4] eal/cpuflags: add x86 based cpu flags
On 29/04/2020 12:22, Neil Horman wrote: > On Mon, Apr 27, 2020 at 02:58:07PM +0100, Ray Kinsella wrote: >> >> >> On 27/04/2020 13:31, Thomas Monjalon wrote: >>> 27/04/2020 11:27, Ray Kinsella: On 25/04/2020 17:04, Thomas Monjalon wrote: > PS: Who is REALLY maintaining the ABI? > We really miss someone who carefully check all these things, > and take care of the doc and tooling. I would say that I am missing these changes to libabigail.ignore, which would be useful. Should we consolidate the ABI Policy and ABI Versioning sections of the MAINTAINERS file? >>> >>> Yes, I think it does not make sense spliting ABI topic in 2 sections >>> in MAINTAINERS file. >>> We need to have a clear ownership covering policy, libs, tooling and doc. >>> Let's agree to merge all in one section please. >>> >> >> I would suggest merging and listing myself and Neil as maintainers? >> Unless you are aware of another potential owner? >> > I'm ok with this > Neil ok I will take care of it in the next rev of the "[PATCH] abi: change references to abi 20.0.1 to abi v21" >> Ray K >> >>
Re: [dpdk-dev] [PATCH v5 00/29] graph: introduce graph subsystem
Hi all, I could not check all discussions regarding the graph subsystem, but I could not find a trivia behind the idea of re-creating yet another graph processing system like VPP, BESS, Click/FastClick and a few others that all support DPDK already and comes with up to thousands of "nodes" already built? Is there something fundamentally better than those? Or this is just to provide a clean in-house API? Thanks, Tom Le 11/04/2020 à 16:13, jer...@marvell.com a écrit : From: Jerin Jacob Using graph traversal for packet processing is a proven architecture that has been implemented in various open source libraries. Graph architecture for packet processing enables abstracting the data processing functions as “nodes” and “links” them together to create a complex “graph” to create reusable/modular data processing functions. The patchset further includes performance enhancements and modularity to the DPDK as discussed in more detail below. v5..v4: -- Addressed the following review comments from Andrzej Ostruszka. 1) Addressed and comment in (http://mails.dpdk.org/archives/dev/2020-April/162184.html) and improved following function prototypes/return types and adjusted the implementation a) rte_graph_node_get b) rte_graph_max_count c) rte_graph_export d) rte_graph_destroy 2) Updated UT and l3fwd-graph for updated function prototype 3) bug fix in edge_update 4) avoid reading graph_src_nodes_count() twice in rte_graph_create() 5) Fix graph_mem_fixup_secondray typo 6) Fixed Doxygen comments for rte_node_next_stream_put 7) Updated the documentation to reflect the same. 8) Removed RTE prefix from rte_node_mbuf_priv[1|2] * as they are internal defines 9) Limited next_hop id provided to LPM route add in librte_node/ip4_lookup.c to 24 bits () 10) Fixed pattern array overflow issue with l3fwd-graph/main.c by splitting pattern array to default + non-default array. Updated doc with the same info. 11) Fixed parsing issues in parse_config() in l3fwd-graph/main.c inline with issues reported in l2fwd-event 12)Removed next_hop field in l3fwd-graph/main.c main() 13) Fixed graph create error check in l3fwd-graph/main.c main() v4..v3: --- Addressed the following review comments from Wang, Xiao W 1) Remove unnecessary line from rte_graph.h 2) Fix a typo from rte_graph.h 3) Move NODE_ID_CHECK to 3rd patch where it is first used. 4) Fixed bug in edge_update() v3..v2: --- 1) refactor ipv4 node lookup by moving SSE and NEON specific code to lib/librte_node/ip4_lookup_sse.h and lib/librte_node/ip4_lookup_neon.h 2) Add scalar version of process() function for ipv4 lookup to make the node work on NON x86 and arm64 machines. v2..v1: -- 1) Added programmer guide/implementation documentation and l3fwd-graph doc RFC..v1: 1) Split the patch to more logical ones for review. 2) Added doxygen comments for the API 3) Code cleanup 4) Additional performance improvements. Delta between l3fwd and l3fwd-graph is negligible now. (~1%) on octeontx2. 5) Added SIMD routines for x86 in additional to arm64. Hosted in netlify for easy reference: Programmer’s Guide: https://dpdk-graph.netlify.com/doc/html/guides/prog_guide/graph_lib.html l3fwd-graph doc: https://dpdk-graph.netlify.com/doc/html/guides/sample_app_ug/l3_forward_graph.html API doc: https://dpdk-graph.netlify.com/doc/html/api/rte__graph_8h.html https://dpdk-graph.netlify.com/doc/html/api/rte__graph__worker_8h.html https://dpdk-graph.netlify.com/doc/html/api/rte__node__eth__api_8h.html https://dpdk-graph.netlify.com/doc/html/api/rte__node__ip4__api_8h.html 2) Added the release notes for the this feature 3) Fix build issues reported by CI for v1: http://mails.dpdk.org/archives/test-report/2020-March/121326.html Addional nodes planned for v20.08 -- 1) Packet classification node 2) Support for IPV6 LPM node This patchset contains - 1) The API definition to "create" nodes and "link" together to create a "graph" for packet processing. See, lib/librte_graph/rte_graph.h 2) The Fast path API definition for the graph walker and enqueue function used by the workers. See, lib/librte_graph/rte_graph_worker.h 3) Optimized SW implementation for (1) and (2). See, lib/librte_graph/ 4) Test case to verify the graph infrastructure functionality See, app/test/test_graph.c 5) Performance test cases to evaluate the cost of graph walker and nodes enqueue fast-path function for various combinations. See app/test/test_graph_perf.c 6) Packet processing nodes(Null, Rx, Tx, Pkt drop, IPV4 rewrite, IPv4 lookup) using graph infrastructure. See lib/librte_node/* 7) An example application to showcase l3fwd (functionality same as existing examples/l3fwd) using graph infrastructure and use packets processing nodes (item (6)). See examples/l3fwd-graph/. Performance --- 1) Graph walk and node enqueue overhead can be tested with performance test case application [1
Re: [dpdk-dev] [PATCH] vhost: zero_copy incompatible with client mode
On 4/29/20 4:59 AM, Xuan Ding wrote: > In server mode, virtio-user inits under the assumption that vhost-user > supports a list of features. However, this could be problematic when > in_order feature is negotiated but not supported by vhost-user when > enables dequeue_zero_copy later. > > Add handling when vhost-user enables dequeue_zero_copy as client. > > Signed-off-by: Xuan Ding > --- > lib/librte_vhost/socket.c | 6 ++ > 1 file changed, 6 insertions(+) Applied to dpdk-next-virtio/master. Thanks, Maxime
Re: [dpdk-dev] [PATCH v2] abi: change references to abi 20.0.1 to abi v21
On 29/04/2020 13:19, Dodji Seketeli wrote: > Hello, > > Ray Kinsella writes: > >> ah ok, the particular system I made the change on was Ubuntu 18.04.2. >> which is libabigail 1.2.0. > > Whoah, 1.2 is super old. I have a huge clunking raid'ed "build" server, that I am pretty conservative about upgrading on v18.04.2 :-) > In my opinion, one of the hallmarks of static analysis tools (and > libabigail is just a static analysis framework) is to be able to > recognize patterns used by developers, as much as we can. > > Because we can't really do that at once, we try to add recognition of > new patterns (of ABI changes) at every single release. Furthermore, > there are some change patterns that ought to be recognized and > categorized as harmless, whereas some others out to be categorized as > harmful. That categorization is also the result of input coming from > users as you, fine fellows. > > All this to say that with every new version, the number of new supported > features and bug fixes is potentially big. > > To alleviate that, some distributors update libabigail even in their old > stable distros, because the value of having an up to date version there > outweighs the potential drawbacks. Well it falls into the same category of problems of upgrading compilers. User's typically build their software build reliably on a given distro version. (or number of versions). If the maintainer upgrades compilers between distro versions, it introduces new warnings and errors, and all hell will generally break loose, when the user least expects it. They typically expect that mayhem when upgrading to new distro versions. Even tools like GNU indent can cause enormous problems. I would imagine that most maintainers would be pretty conservative about making such changes. > >> Given we still support v19.11 on Ubuntu 18.04.2. > > So maybe that's a discussion worth having with the maintainer of the > Ubuntu package of Libabigail? yes - I think it would be an interesting discussion alright. I imagine the response might be inline with my understanding above. Let's find out - as we can expect v18.04 to be around for at least another two years I guess. Another common way to handle this, is to be really explicit about what OS distros DPDK formally supports building on, which will then imply we support a small handful of versions of libabigail. We then simply say we don't support 18.04 anymore - FD.io VPP are planning this formal switch at the moment. > >> I think it's worthwhile keeping the suppression until v20.11? > > [...] > > David Marchand writes: > >> In Travis, we currently use libabigail 1.6 (mainly because I did not >> update to 1.7 when it was released). > > Right, that's probably another way to stay up to date independently from > the underlying distribution. You typically don't want to encourage this, you end up with some people on a newer version, some people on an old version and never upgrading. Then you never end up with a consistent view of what mitigations are actually required. Solving issues, becomes like a game of whack-a-mole. > > I hope this helps, It does, greatly thanks. > > Cheers, >
[dpdk-dev] [PATCH] net/mlx5: fix set VLAN vid size check
All comparison should be done in CPU endianness, otherwise
it will not give right results.
for example:
255 after converting into RTE_BE16 will be biger than 4096 after
converting into RTE_BE16.
Fixes: a5f2da0b816b ("net/mlx5: support modify VLAN ID on new VLAN header")
Cc: mo...@mellanox.com
Cc: sta...@dpdk.org backport
Signed-off-by: Wisam Jaddo
---
drivers/net/mlx5/mlx5_flow_dv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/mlx5/mlx5_flow_dv.c b/drivers/net/mlx5/mlx5_flow_dv.c
index 6263ecc731..2b88e85248 100644
--- a/drivers/net/mlx5/mlx5_flow_dv.c
+++ b/drivers/net/mlx5/mlx5_flow_dv.c
@@ -1965,7 +1965,7 @@ flow_dv_validate_action_set_vlan_vid(uint64_t item_flags,
const struct rte_flow_action *action = actions;
const struct rte_flow_action_of_set_vlan_vid *conf = action->conf;
- if (conf->vlan_vid > RTE_BE16(0xFFE))
+ if (rte_be_to_cpu_16(conf->vlan_vid) > 0xFFE)
return rte_flow_error_set(error, EINVAL,
RTE_FLOW_ERROR_TYPE_ACTION, action,
"VLAN VID value is too big");
--
2.17.1
Re: [dpdk-dev] [PATCH 2/2] eal: resolve getentropy at run time for random seed
On Mon, 2020-04-27 at 13:57 -0300, Dan Gora wrote: > On Mon, Apr 27, 2020 at 1:19 PM Luca Boccassi wrote: > > On Thu, 2020-04-23 at 14:38 -0300, Dan Gora wrote: > > > On Thu, Apr 23, 2020 at 12:59 PM Luca Boccassi wrote: > > > > > > /dev/urandom is basically only a different interface to the same > > > > > > underlying mechanism. > > > > > > > > This is not the whole story though - while the end result when all > > > > works is the same, there are important differences in getting there. > > > > There's a reason a programmatic interface was added - it's just better > > > > in general. > > > > Just to name one - opening files has implications for LSMs like > > > > SELinux. You now need a specific policy to allow it, which means > > > > applications that upgrade from one version of DPDK to the next will > > > > break. > > > > > > DPDK opens _tons_ of files. This would not be the first file that DPDK > > > has to open. And it's not like /dev/urandom is a new interface. It's > > > been around forever. > > > > That might be the case, but it is not reason in itself to make things > > harder. Especially in light of the new stability promise - this might > > or might not be considered part of it, but it's worth mentioning at the > > very least, as it has a real impact on users. > > "make things harder" seems especially subjective.. I would argue that > I am in fact making things much easier by removing unnecessary > dependecies For someone with selinux, things would be harder. It's a consequence worth highlighting, that's all. > > > If this is such a major problem, then that would argue for using the > > > dlsym()/dlopen() method to try to find the getentropy glibc function > > > that I sent in v3 of these patches. > > > > > > > In general, I do not think we should go backwards. The programmatic > > > > interface to the random pools are good and we should use them by > > > > default - of course by all means add fallbacks to urandom if they are > > > > not available. > > > > > > The original problem was that the "programmatic interface to the > > > random pools" (that is, getentropy()) can only be determined at > > > compilation time and if found introduce a new dependency on glibc 2.25 > > > that can easily be avoided by emulating it (as I did here in v4 of the > > > patches) or by trying to dynamically find the symbol at run time using > > > dlopen()/dlsym() (as I did in v3 of the patches). > > > > > > > But as Stephen said glibc generally does not support compiling on new + > > > > running on old - so if it's not this that breaks, it will be something > > > > else. > > > > > > Well that's not necessarily true. Most glibc interfaces have been > > > around forever and you can easily see what versions of glibc are > > > needed by running ldd on your application. I don't see the point in > > > introducing a new dependency on a very recent version of glibc which > > > is not supported by all supported DPDK platforms when it can easily be > > > worked around. > > > > > > The issue here is that the original patch to add getentropy(): > > > 1) Added a _new_ dependency on glibc 2.25. > > > 2) Added a _new_ dependency that the rdseed CPU flag on the execution > > > machine has to match the complication machine. > > > 3) Has different behavior if the DPDK is compiled with meson or with > > > Make on the same complication platform. > > > > > > thanks, > > > dan > > > > Adding a new dependecy happens only when building with the new version > > of the library. If it's not available, then there's no new dependency. > > But you also do not get to use the new getentropy() if you happen to > compile on a system which does not have the latest glibc, or if you > use the makefile system.. And that's perfectly fine - backward compatibility workarounds are not a problem to me. > > It sounds to me like you are trying to add workarounds for issues in > > your downstream build/deployment model, where your build dependencies > > are newer than your runtime dependencies. This in general is rarely > > well supported. > > I am fully aware of that. I am not adding "workarounds", I am > eliminating unnecessary dependencies which probably never should have > been introduced in the first place. It's not unnecessary. It's a better interface, and worth using if available. > > Now I'm fine with adding workarounds as _fallbacks_ - what I am > > explicitly NACKing is forcibly restricting to the least common > > denominator because of issues in a third party build/deployment system > > that doesn't follow the common norm. > > ugh.. this is the exact _opposite_ of what this patch does. It is not > restricting anything to a least common denominator. It is allowing > the DPDK to use the "best" available function, regardless of the build > system. > > Restricting to the least common denominator is what the original patch did... This is restricting to the least common denominator of /dev/urandom, which is a bad interface, frai
Re: [dpdk-dev] [PATCH v5 00/29] graph: introduce graph subsystem
On Thu, Apr 30, 2020 at 1:38 PM Tom Barbette wrote: > > Hi all, > > I could not check all discussions regarding the graph subsystem, but I > could not find a trivia behind the idea of re-creating yet another graph > processing system like VPP, BESS, Click/FastClick and a few others that > all support DPDK already and comes with up to thousands of "nodes" > already built? > > Is there something fundamentally better than those? Or this is just to > provide a clean in-house API? Enumerating some of the features: 0) Native mbuf based nodes. This will avoid, mbuf to other data plane container conversion cost in fastpath. 1) Nodes as plugins. 2) Support for out of tree nodes. 3) Inbuilt nodes for packet processing. 4) Multi-process support. 5) Low overhead graph walk and node enqueue.[1] See performance data from the cover letter. 6) Low overhead statistics collection infrastructure. 7) Support to export the graph as a Graphviz dot file. See rte_graph_export(). 8) Allow having another graph walk implementation in the future by segregating the fast path(rte_graph_worker.h) and slow path code. 9) Native DPDK apps for DPDK drivers to leverage graph architecture. I think item (0), (4), (5), (9) useful for the DPDK ecosystem. Performance[1] --- 1) Graph walk and node enqueue overhead can be tested with performance test case application [1] # If all packets go from a node to another node (we call it as # "homerun") then it will be just a pointer swap for a burst of packets. # In the worst case, a couple of handful cycles to move an object from a node to another node. 2) Performance comparison with existing l3fwd (The complete static code with out any nodes) vs modular l3fwd-graph with 5 nodes (ip4_lookup, ip4_rewrite, ethdev_tx, ethdev_rx, pkt_drop). Here is graphical representation of the l3fwd-graph as Graphviz dot file: http://bit.ly/39UPPGm # l3fwd-graph performance is -1.2% wrt static l3fwd. # We have simulated the similar test with existing librte_pipeline # application [4]. ip_pipline application is -48.62% wrt static l3fwd. The above results are on octeontx2. It may vary on other platforms. The platforms with higher L1 and L2 caches will have further better performance. > > Thanks, > > Tom > > Le 11/04/2020 à 16:13, jer...@marvell.com a écrit : > > From: Jerin Jacob > > > > Using graph traversal for packet processing is a proven architecture > > that has been implemented in various open source libraries. > > > > Graph architecture for packet processing enables abstracting the data > > processing functions as “nodes” and “links” them together to create a > > complex “graph” to create reusable/modular data processing functions. > > > > The patchset further includes performance enhancements and modularity > > to the DPDK as discussed in more detail below. > > > > v5..v4: > > -- > > Addressed the following review comments from Andrzej Ostruszka. > > > > 1) Addressed and comment in > > (http://mails.dpdk.org/archives/dev/2020-April/162184.html) > > and improved following function prototypes/return types and adjusted the > > implementation > > a) rte_graph_node_get > > b) rte_graph_max_count > > c) rte_graph_export > > d) rte_graph_destroy > > 2) Updated UT and l3fwd-graph for updated function prototype > > 3) bug fix in edge_update > > 4) avoid reading graph_src_nodes_count() twice in rte_graph_create() > > 5) Fix graph_mem_fixup_secondray typo > > 6) Fixed Doxygen comments for rte_node_next_stream_put > > 7) Updated the documentation to reflect the same. > > 8) Removed RTE prefix from rte_node_mbuf_priv[1|2] * as they are > > internal defines > > 9) Limited next_hop id provided to LPM route add in > > librte_node/ip4_lookup.c to 24 bits () > > 10) Fixed pattern array overflow issue with l3fwd-graph/main.c by > > splitting pattern > > array to default + non-default array. Updated doc with the same info. > > 11) Fixed parsing issues in parse_config() in l3fwd-graph/main.c inline > > with issues reported > > in l2fwd-event > > 12)Removed next_hop field in l3fwd-graph/main.c main() > > 13) Fixed graph create error check in l3fwd-graph/main.c main() > > > > v4..v3: > > --- > > Addressed the following review comments from Wang, Xiao W > > > > 1) Remove unnecessary line from rte_graph.h > > 2) Fix a typo from rte_graph.h > > 3) Move NODE_ID_CHECK to 3rd patch where it is first used. > > 4) Fixed bug in edge_update() > > > > v3..v2: > > --- > > 1) refactor ipv4 node lookup by moving SSE and NEON specific code to > > lib/librte_node/ip4_lookup_sse.h and lib/librte_node/ip4_lookup_neon.h > > 2) Add scalar version of process() function for ipv4 lookup to make > > the node work on NON x86 and arm64 machines. > > > > v2..v1: > > -- > > 1) Added programmer guide/implementation documentation and l3fwd-graph doc > > > > RFC..v1: > > > > > > 1) Split the patch to more logical ones for review. > > 2) Added doxygen comments for the API > > 3) Code cleanup > > 4) Additional performance impr
Re: [dpdk-dev] [PATCH] net/mlx5: fix default rule do RSS regardless rxmode
> -Original Message-
> From: Xiaoyu Min
> Sent: Wednesday, April 29, 2020 16:01
> To: Matan Azrad ; Shahaf Shuler
> ; Slava Ovsiienko
> Cc: dev@dpdk.org; sta...@dpdk.org
> Subject: [PATCH] net/mlx5: fix default rule do RSS regardless rxmode
>
> PMD create some default control rules with RSS action if it's not isolated
> mode.
>
> However whether default control rules need to do RSS or not should be
> controlled by device configuration, the mq_mode of rxmode configuration in
> specific.
>
> In another word, only when mq_mode is configured with
> ETH_MQ_RX_RSS_FLAG set, then RSS is needed for default rules.
>
> Fixes: c64ccc0eca2f ("mlx5: fix overwritten RSS configuration")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Xiaoyu Min
Signed-off-by: Viacheslav Ovsiienko
> ---
> drivers/net/mlx5/mlx5_flow.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/net/mlx5/mlx5_flow.c b/drivers/net/mlx5/mlx5_flow.c
> index e9ae2f782c..cb593c9449 100644
> --- a/drivers/net/mlx5/mlx5_flow.c
> +++ b/drivers/net/mlx5/mlx5_flow.c
> @@ -4912,6 +4912,8 @@ mlx5_ctrl_flow_vlan(struct rte_eth_dev *dev,
> if (!priv->reta_idx_n || !priv->rxqs_n) {
> return 0;
> }
> + if (!(dev->data->dev_conf.rxmode.mq_mode &
> ETH_MQ_RX_RSS_FLAG))
> + action_rss.types = 0;
> for (i = 0; i != priv->reta_idx_n; ++i)
> queue[i] = (*priv->reta_idx)[i];
> flow_idx = flow_list_create(dev, &priv->ctrl_flows,
> --
> 2.26.0
Re: [dpdk-dev] [PATCH] eal/ppc: fix redefine bool type
Hi David,
> -Original Message-
> From: David Marchand
> Sent: Wednesday, April 29, 2020 11:17 AM
> To: Ori Kam
> Cc: Thomas Monjalon ; Matan Azrad
> ; Shahaf Shuler ; Slava
> Ovsiienko ; David Christensen
> ; dev ; Yigit, Ferruh
>
> Subject: Re: [dpdk-dev] [PATCH] eal/ppc: fix redefine bool type
>
> On Tue, Apr 28, 2020 at 9:59 AM Ori Kam wrote:
> >
> > The AltiVec header file breaks boolean type. [1] [2]
> >
> > Currently the workaround was located only in mlx5 device.
> > Adding the trace module caused this issue to appear again, due to
> > order of includes, it keeps overriding the local fix.
> >
> > This patch solves this issue by resetting the bool type, immediately
> > after it is being changed.
>
>
> With this patch applied, there are still a few remaining spots as
> mentioned by David C.
> I see rte_vect.h too.
>
I will add the missing code.
> $ git grep -w altivec.h
> MAINTAINERS:F: examples/l3fwd/*altivec.h
> drivers/net/i40e/i40e_rxtx_vec_altivec.c:#include
> drivers/net/mlx5/mlx5_rxtx_vec_altivec.h:#include
> drivers/net/virtio/virtio_rxtx_simple_altivec.c:#include
> lib/librte_eal/ppc/include/rte_altivec.h:/* To include altivec.h, GCC
> version must be >= 4.8 */
> lib/librte_eal/ppc/include/rte_altivec.h:#include
> lib/librte_eal/ppc/include/rte_vect.h:#include
>
>
> > diff --git a/lib/librte_eal/ppc/include/rte_memcpy.h
> b/lib/librte_eal/ppc/include/rte_memcpy.h
> > index 25311ba..d234e21 100644
> > --- a/lib/librte_eal/ppc/include/rte_memcpy.h
> > +++ b/lib/librte_eal/ppc/include/rte_memcpy.h
> > @@ -8,13 +8,12 @@
> >
> > #include
> > #include
> > -/*To include altivec.h, GCC version must >= 4.8 */
> > -#include
>
> Why move the inclusion under the __cplusplus check?
>
Just to make it in the same part as other rte includes.
>
> >
> > #ifdef __cplusplus
> > extern "C" {
> > #endif
> >
> > +#include "rte_altivec.h"
> > #include "generic/rte_memcpy.h"
> >
> > static inline void
> > --
> > 1.8.3.1
> >
>
> Thanks.
>
> --
> David Marchand
Re: [dpdk-dev] [PATCH] net/mlx5: fix default rule do RSS regardless rxmode
> -Original Message-
> From: Slava Ovsiienko
> Sent: Thursday, April 30, 2020 11:52
> To: Xiaoyu Min ; Matan Azrad
> ; Shahaf Shuler
> Cc: dev@dpdk.org; sta...@dpdk.org
> Subject: RE: [PATCH] net/mlx5: fix default rule do RSS regardless rxmode
>
> > -Original Message-
> > From: Xiaoyu Min
> > Sent: Wednesday, April 29, 2020 16:01
> > To: Matan Azrad ; Shahaf Shuler
> > ; Slava Ovsiienko
> > Cc: dev@dpdk.org; sta...@dpdk.org
> > Subject: [PATCH] net/mlx5: fix default rule do RSS regardless rxmode
> >
> > PMD create some default control rules with RSS action if it's not
> > isolated mode.
> >
> > However whether default control rules need to do RSS or not should be
> > controlled by device configuration, the mq_mode of rxmode
> > configuration in specific.
> >
> > In another word, only when mq_mode is configured with
> > ETH_MQ_RX_RSS_FLAG set, then RSS is needed for default rules.
> >
> > Fixes: c64ccc0eca2f ("mlx5: fix overwritten RSS configuration")
> > Cc: sta...@dpdk.org
> >
> > Signed-off-by: Xiaoyu Min
Acked-by: Viacheslav Ovsiienko
>
> > ---
> > drivers/net/mlx5/mlx5_flow.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/drivers/net/mlx5/mlx5_flow.c
> > b/drivers/net/mlx5/mlx5_flow.c index e9ae2f782c..cb593c9449 100644
> > --- a/drivers/net/mlx5/mlx5_flow.c
> > +++ b/drivers/net/mlx5/mlx5_flow.c
> > @@ -4912,6 +4912,8 @@ mlx5_ctrl_flow_vlan(struct rte_eth_dev *dev,
> > if (!priv->reta_idx_n || !priv->rxqs_n) {
> > return 0;
> > }
> > + if (!(dev->data->dev_conf.rxmode.mq_mode &
> > ETH_MQ_RX_RSS_FLAG))
> > + action_rss.types = 0;
> > for (i = 0; i != priv->reta_idx_n; ++i)
> > queue[i] = (*priv->reta_idx)[i];
> > flow_idx = flow_list_create(dev, &priv->ctrl_flows,
> > --
> > 2.26.0
Re: [dpdk-dev] [PATCH] eal/ppc: fix redefine bool type
Hi David,
I will add your code.
Thanks,
Ori
> -Original Message-
> From: David Christensen
> Sent: Tuesday, April 28, 2020 9:20 PM
> To: Ori Kam ; Thomas Monjalon
> ; Matan Azrad ; Shahaf
> Shuler ; Slava Ovsiienko
>
> Cc: dev@dpdk.org; ferruh.yi...@intel.com
> Subject: Re: [PATCH] eal/ppc: fix redefine bool type
>
> > Fixes: 725f5dd0bfb5 ("net/mlx5: fix build on PPC64")
> >
> > Signed-off-by: Ori Kam
> > ---
>
> There are a couple of other uses that should be covered in the patch:
>
> diff --git a/drivers/net/i40e/i40e_rxtx_vec_altivec.c
> b/drivers/net/i40e/i40e_rxtx_vec_altivec.c
> index 5fa92bf92..72bd410fc 100644
> --- a/drivers/net/i40e/i40e_rxtx_vec_altivec.c
> +++ b/drivers/net/i40e/i40e_rxtx_vec_altivec.c
> @@ -13,7 +13,7 @@
> #include "i40e_rxtx.h"
> #include "i40e_rxtx_vec_common.h"
>
> -#include
> +#include "rte_altivec.h"
>
> #pragma GCC diagnostic ignored "-Wcast-qual"
>
>
> diff --git a/drivers/net/virtio/virtio_rxtx_simple_altivec.c
> b/drivers/net/virtio/virtio_rxtx_simple_altivec.c
> index 47225f412..b2bdd05c8 100644
> --- a/drivers/net/virtio/virtio_rxtx_simple_altivec.c
> +++ b/drivers/net/virtio/virtio_rxtx_simple_altivec.c
> @@ -9,7 +9,7 @@
> #include
> #include
>
> -#include
> +#include "rte_altivec.h"
>
> #include
> #include
>
> Dave
Re: [dpdk-dev] [PATCH] net/mlx5: fix set VLAN vid size check
> -Original Message-
> From: Wisam Monther
> Sent: Thursday, April 30, 2020 11:31
> To: dev@dpdk.org; Dekel Peled ; Slava Ovsiienko
> ; Raslan Darawsheh
> Cc: Moti Haimovsky ; sta...@dpdk.org
> Subject: [PATCH] net/mlx5: fix set VLAN vid size check
>
> All comparison should be done in CPU endianness, otherwise it will not give
> right results.
>
> for example:
> 255 after converting into RTE_BE16 will be biger than 4096 after converting
> into RTE_BE16.
>
> Fixes: a5f2da0b816b ("net/mlx5: support modify VLAN ID on new VLAN
> header")
> Cc: mo...@mellanox.com
> Cc: sta...@dpdk.org backport
>
> Signed-off-by: Wisam Jaddo
Acked-by: Viacheslav Ovsiienko
> ---
> drivers/net/mlx5/mlx5_flow_dv.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/mlx5/mlx5_flow_dv.c
> b/drivers/net/mlx5/mlx5_flow_dv.c index 6263ecc731..2b88e85248 100644
> --- a/drivers/net/mlx5/mlx5_flow_dv.c
> +++ b/drivers/net/mlx5/mlx5_flow_dv.c
> @@ -1965,7 +1965,7 @@ flow_dv_validate_action_set_vlan_vid(uint64_t
> item_flags,
> const struct rte_flow_action *action = actions;
> const struct rte_flow_action_of_set_vlan_vid *conf = action->conf;
>
> - if (conf->vlan_vid > RTE_BE16(0xFFE))
> + if (rte_be_to_cpu_16(conf->vlan_vid) > 0xFFE)
> return rte_flow_error_set(error, EINVAL,
> RTE_FLOW_ERROR_TYPE_ACTION,
> action,
> "VLAN VID value is too big");
> --
> 2.17.1
Re: [dpdk-dev] [PATCH] eal/ppc: fix redefine bool type
On Thu, Apr 30, 2020 at 10:53 AM Ori Kam wrote: > > > diff --git a/lib/librte_eal/ppc/include/rte_memcpy.h > > b/lib/librte_eal/ppc/include/rte_memcpy.h > > > index 25311ba..d234e21 100644 > > > --- a/lib/librte_eal/ppc/include/rte_memcpy.h > > > +++ b/lib/librte_eal/ppc/include/rte_memcpy.h > > > @@ -8,13 +8,12 @@ > > > > > > #include > > > #include > > > -/*To include altivec.h, GCC version must >= 4.8 */ > > > -#include > > > > Why move the inclusion under the __cplusplus check? > > > Just to make it in the same part as other rte includes. "Normal" rte includes are usually standalone and "#ifdef __cplusplus" safe. The rte_altivec.h header you added does not need any "#ifdef __cplusplus" protection, but it might later). But otoh, "generic/" headers are special/internal headers and this is why generic/rte_memcpy.h is under this check. So if there is no reason on your side, please leave rte_altivec.h inclusion at the same place as the previous altivec.h. Thanks. -- David Marchand
Re: [dpdk-dev] [PATCH] eal/ppc: fix redefine bool type
> -Original Message- > From: David Marchand > Sent: Thursday, April 30, 2020 12:04 PM > To: Ori Kam > Cc: Thomas Monjalon ; Matan Azrad > ; Shahaf Shuler ; Slava > Ovsiienko ; David Christensen > ; dev ; Yigit, Ferruh > > Subject: Re: [dpdk-dev] [PATCH] eal/ppc: fix redefine bool type > > On Thu, Apr 30, 2020 at 10:53 AM Ori Kam wrote: > > > > diff --git a/lib/librte_eal/ppc/include/rte_memcpy.h > > > b/lib/librte_eal/ppc/include/rte_memcpy.h > > > > index 25311ba..d234e21 100644 > > > > --- a/lib/librte_eal/ppc/include/rte_memcpy.h > > > > +++ b/lib/librte_eal/ppc/include/rte_memcpy.h > > > > @@ -8,13 +8,12 @@ > > > > > > > > #include > > > > #include > > > > -/*To include altivec.h, GCC version must >= 4.8 */ > > > > -#include > > > > > > Why move the inclusion under the __cplusplus check? > > > > > Just to make it in the same part as other rte includes. > > "Normal" rte includes are usually standalone and "#ifdef __cplusplus" safe. > The rte_altivec.h header you added does not need any "#ifdef > __cplusplus" protection, but it might later). > > But otoh, "generic/" headers are special/internal headers and this is > why generic/rte_memcpy.h is under this check. > > So if there is no reason on your side, please leave rte_altivec.h > inclusion at the same place as the previous altivec.h. > Sure, I will leave at the original place. Best, Ori > > Thanks. > > -- > David Marchand
Re: [dpdk-dev] [PATCH] examples/vhost_blk: refactor vhost-blk example
On 4/30/20 3:42 AM, Yu, Jin wrote:
> Got it. I will check and fix it.
Thanks, I will need the fix today, just send a v2.
If not possible to do it today, please let me know.
Maxime
> Thanks.
>
>> -Original Message-
>> From: Yigit, Ferruh
>> Sent: Thursday, April 30, 2020 1:54 AM
>> To: Yu, Jin ; Maxime Coquelin
>> ; Tiwei Bie ; Wang,
>> Zhihong ; Mcnamara, John
>> ; Kovacevic, Marko
>> Cc: dev@dpdk.org
>> Subject: Re: [dpdk-dev] [PATCH] examples/vhost_blk: refactor vhost-blk
>> example
>>
>> On 2/28/2020 3:32 PM, Jin Yu wrote:
>>> Decrease the code and make it easier to read. It's useful for
>>> understanding the inflight APIs and how packed ring works. Update the
>>> RST because the packed ring patch has been merged to QEMU master and
>>> ring_packed parameter changes to packed.
>>>
>>> Fixes: c19beb3f38cd ("examples/vhost_blk: introduce vhost storage
>>> sample")
>>>
>>> Signed-off-by: Jin Yu
>>> ---
>>> doc/guides/sample_app_ug/vhost_blk.rst |8 +-
>>> examples/vhost_blk/blk.c | 13 +-
>>> examples/vhost_blk/vhost_blk.c | 1139 ++--
>>> examples/vhost_blk/vhost_blk.h | 39 +-
>>> 4 files changed, 494 insertions(+), 705 deletions(-)
>>
>> Getting following build error with 32-bit build, can you please check it:
>>
>> .../examples/vhost_blk/vhost_blk.c: In function ‘desc_payload_to_iovs’:
>> .../examples/vhost_blk/vhost_blk.c:157:9: error: cast to pointer from
>> integer of
>> different size [-Werror=int-to-pointer-cast]
>> 157 | vva = (void *)gpa_to_vva(ctrlr,
>> | ^
>>
>
Re: [dpdk-dev] [PATCH] eal: fix lcore state bug
W dniu 30.04.2020 o 04:54, Phil Yang pisze: >> -Original Message- >> From: Lukasz Wojciechowski >> Sent: Thursday, April 30, 2020 5:32 AM >> To: Phil Yang ; Harry van Haaren >> ; Jerin Jacob >> >> Cc: dev@dpdk.org; sta...@dpdk.org; nd >> Subject: Re: [dpdk-dev] [PATCH] eal: fix lcore state bug >> >> Hi Phil, >> >> W dniu 29.04.2020 o 17:07, Phil Yang pisze: >>> Hi Lukasz, >>> -Original Message- From: dev On Behalf Of Lukasz Wojciechowski Sent: Tuesday, April 28, 2020 9:22 AM To: Harry van Haaren ; Jerin Jacob Cc: dev@dpdk.org; l.wojciec...@partner.samsung.com; >> sta...@dpdk.org Subject: [dpdk-dev] [PATCH] eal: fix lcore state bug The rte_service_lcore_reset_all function stops execution of services on all lcores and switches them back from ROLE_SERVICE to ROLE_RTE. However the thread loop for slave lcores (eal_thread_loop) distincts >> these roles to set lcore state after processing delegated function. It sets WAIT state for ROLE_SERVICE, but FINISHED for ROLE_RTE. So changing the role to RTE before stopping work in slave lcores causes lcores to end in FINISHED state. That is why the rte_eal_lcore_wait must be run after rte_service_lcore_reset_all to bring back lcores to launchable (WAIT) state. >>> Is that make sense to call rte_eal_mp_wait_lcore() inside >> rte_serice_lcore_reset_all() ? >> >> yeah, I thought about it and in my opinion the answer is no, because if >> the function run on slave lcore is in FINISHED state it means, that >> someone can still read the value returned by the function and the only >> one who can be interested in the value is the one that delegated the >> service. >> >> If we will wait for lcores to end their jobs, read the values and switch >> them to WAIT state, the values will be lost. The application might need >> to read them. We cannot take this possibility from it. > Yeah. I think that is a good point. > > Reviewed-by: Phil Yang Thank you > >>> >>> >>> Thanks, >>> Phil >> -- >> >> Lukasz Wojciechowski >> Principal Software Engineer >> >> Samsung R&D Institute Poland >> Samsung Electronics >> Office +48 22 377 88 25 >> l.wojciec...@partner.samsung.com -- Lukasz Wojciechowski Principal Software Engineer Samsung R&D Institute Poland Samsung Electronics Office +48 22 377 88 25 l.wojciec...@partner.samsung.com
Re: [dpdk-dev] [PATCH v4 0/2] one way barrier for split vring idx
On 4/29/20 7:45 PM, Ferruh Yigit wrote: > On 4/24/2020 4:39 AM, Joyce Kong wrote: >> This patchset replaces the two-way barriers with C11 one-way barriers >> for split vring idx, when the frontend and backend are implemented >> in software. >> >> By doing PVP benchmarking, the test result of 2c1q showed the throughput >> increased 20% with the 0.001% of acceptable loss rate on Thunderx2 >> platform.[1] >> >> By doing vhost-user + virtio-user case benchmarking, 4% performance gain >> was measured on Thunderx2 platform by 2c1q RFC2544 test of 0.001% loss, >> and 4.7% performance was improved on Dell platform by 1c1q RFC2544 test >> of zero packet loss.[2] >> >> [1]https://doc.dpdk.org/guides/howto/pvp_reference_benchmark.html >> [2]https://doc.dpdk.org/dts/test_plans/pvp_multi_paths_performance_test_plan.html >>PVP test with virtio 1.0 normal path >> >> v4: >> Remove some duplicated code comment. >> >> v3: >> Modify some style error. >> >> v2: >> Add test performance statistics. >> >> Joyce Kong (2): >> virtio: one way barrier for split vring used idx >> virtio: one way barrier for split vring avail idx >> > > Hi Joyce, > > When 'CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_DUMP=y' enabled, build fails. Can you > please check it? Hi Joyce, I will need the fix today, just send a v5 for the series. If not possible to do it today, please let me know. Maxime > Thanks, > ferruh >
Re: [dpdk-dev] [PATCH] net/ice: fix core dumped issue in switch filter
Tested-by: Xiao, QimaiX
Regards,
Xiao Qimai
> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Junyu Jiang
> Sent: Wednesday, April 29, 2020 3:25 PM
> To: dev@dpdk.org
> Cc: Yang, Qiming ; Jiang, JunyuX
> ; sta...@dpdk.org
> Subject: [dpdk-dev] [PATCH] net/ice: fix core dumped issue in switch filter
>
> The number of queues in queue group should be checked before using it to
> avoid NULL pointer. This patch fixed the issue.
>
> Fixes: 47d460d63233 ("net/ice: rework switch filter")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Junyu Jiang
> ---
> drivers/net/ice/ice_switch_filter.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/net/ice/ice_switch_filter.c
> b/drivers/net/ice/ice_switch_filter.c
> index 179430136..c2762e331 100644
> --- a/drivers/net/ice/ice_switch_filter.c
> +++ b/drivers/net/ice/ice_switch_filter.c
> @@ -1296,6 +1296,8 @@ ice_switch_parse_action(struct ice_pf *pf,
> switch (action_type) {
> case RTE_FLOW_ACTION_TYPE_RSS:
> act_qgrop = action->conf;
> + if (act_qgrop->queue_num <= 1)
> + goto error;
> rule_info->sw_act.fltr_act =
> ICE_FWD_TO_QGRP;
> rule_info->sw_act.fwd_id.q_id =
> --
> 2.17.1
Re: [dpdk-dev] [RFC] hash: unify crc32 API header for x86 and ARM
> -Original Message-
> From: dev On Behalf Of pbhagavat...@marvell.com
> Sent: Wednesday, April 29, 2020 7:05 PM
> To: jer...@marvell.com; tho...@monjalon.net; Wang, Yipeng1
> ; Gobriel, Sameh ;
> Richardson, Bruce ; Ruifeng Wang
>
> Cc: dev@dpdk.org; Pavan Nikhilesh
> Subject: [dpdk-dev] [RFC] hash: unify crc32 API header for x86 and ARM
>
> From: Pavan Nikhilesh
>
> Merge crc32 hash calculation public API headers for x86 and ARM,
> split implementations of x86 and ARM into their respective private
> headers.
> This reduces the ifdef code clutter while keeping current ABI intact.
>
> Although we install `rte_crc_arm64.h` it is not used in any of the lib or
> drivers layers. All the libs and drivers use `rte_hash_crc.h` which falls
> back to SW crc32 calculation for ARM platform.
> diff --git a/lib/librte_hash/meson.build b/lib/librte_hash/meson.build
> index 6ab46ae9d..90a180bc8 100644
> --- a/lib/librte_hash/meson.build
> +++ b/lib/librte_hash/meson.build
> @@ -1,8 +1,7 @@
> # SPDX-License-Identifier: BSD-3-Clause
> # Copyright(c) 2017 Intel Corporation
>
> -headers = files('rte_crc_arm64.h',
> - 'rte_fbk_hash.h',
> +headers = files('rte_fbk_hash.h',
> 'rte_hash_crc.h',
> 'rte_hash.h',
> 'rte_jhash.h',
Am I right in that previously an application could #include
and hence if we no
longer install that file, this will cause a compilation failure on that
application? Applications shouldn't
include arch specific headers... but we shouldn't knowingly remove publicly
accessible includes either.
Perhaps consider just installing a dummy header file if the code cleanup in the
rest of the patch is desired?
[dpdk-dev] [PATCH v5 1/2] virtio: one way barrier for split vring used idx
In case VIRTIO_F_ORDER_PLATFORM(36) is not negotiated, then the frontend
and backend are assumed to be implemented in software, that is they can
run on identical CPUs in an SMP configuration.
Thus a weak form of memory barriers like rte_smp_r/wmb, other than
rte_cio_r/wmb, is sufficient for this case(vq->hw->weak_barriers == 1)
and yields better performance.
For the above case, this patch helps yielding even better performance
by replacing the two-way barriers with C11 one-way barriers for used
index in split ring.
Signed-off-by: Joyce Kong
Reviewed-by: Gavin Hu
Reviewed-by: Maxime Coquelin
---
drivers/net/virtio/virtio_ethdev.c| 7 +---
drivers/net/virtio/virtio_ring.h | 2 +-
drivers/net/virtio/virtio_rxtx.c | 35 ++---
drivers/net/virtio/virtio_rxtx_simple_neon.c | 5 +--
drivers/net/virtio/virtio_rxtx_simple_sse.c | 4 +-
.../net/virtio/virtio_user/virtio_user_dev.c | 8 ++--
drivers/net/virtio/virtqueue.c| 2 +-
drivers/net/virtio/virtqueue.h| 38 ---
lib/librte_vhost/virtio_net.c | 5 +--
9 files changed, 58 insertions(+), 48 deletions(-)
diff --git a/drivers/net/virtio/virtio_ethdev.c
b/drivers/net/virtio/virtio_ethdev.c
index 37766cbb6..c36404dc6 100644
--- a/drivers/net/virtio/virtio_ethdev.c
+++ b/drivers/net/virtio/virtio_ethdev.c
@@ -289,13 +289,10 @@ virtio_send_command_split(struct virtnet_ctl *cvq,
virtqueue_notify(vq);
- rte_rmb();
- while (VIRTQUEUE_NUSED(vq) == 0) {
- rte_rmb();
+ while (virtqueue_nused(vq) == 0)
usleep(100);
- }
- while (VIRTQUEUE_NUSED(vq)) {
+ while (virtqueue_nused(vq)) {
uint32_t idx, desc_idx, used_idx;
struct vring_used_elem *uep;
diff --git a/drivers/net/virtio/virtio_ring.h b/drivers/net/virtio/virtio_ring.h
index 7ba34662e..0f6574f68 100644
--- a/drivers/net/virtio/virtio_ring.h
+++ b/drivers/net/virtio/virtio_ring.h
@@ -59,7 +59,7 @@ struct vring_used_elem {
struct vring_used {
uint16_t flags;
- volatile uint16_t idx;
+ uint16_t idx;
struct vring_used_elem ring[0];
};
diff --git a/drivers/net/virtio/virtio_rxtx.c b/drivers/net/virtio/virtio_rxtx.c
index 060410577..25703e616 100644
--- a/drivers/net/virtio/virtio_rxtx.c
+++ b/drivers/net/virtio/virtio_rxtx.c
@@ -45,7 +45,7 @@ virtio_dev_rx_queue_done(void *rxq, uint16_t offset)
struct virtnet_rx *rxvq = rxq;
struct virtqueue *vq = rxvq->vq;
- return VIRTQUEUE_NUSED(vq) >= offset;
+ return virtqueue_nused(vq) >= offset;
}
void
@@ -1243,9 +1243,7 @@ virtio_recv_pkts(void *rx_queue, struct rte_mbuf
**rx_pkts, uint16_t nb_pkts)
if (unlikely(hw->started == 0))
return nb_rx;
- nb_used = VIRTQUEUE_NUSED(vq);
-
- virtio_rmb(hw->weak_barriers);
+ nb_used = virtqueue_nused(vq);
num = likely(nb_used <= nb_pkts) ? nb_used : nb_pkts;
if (unlikely(num > VIRTIO_MBUF_BURST_SZ))
@@ -1458,12 +1456,10 @@ virtio_recv_pkts_inorder(void *rx_queue,
if (unlikely(hw->started == 0))
return nb_rx;
- nb_used = VIRTQUEUE_NUSED(vq);
+ nb_used = virtqueue_nused(vq);
nb_used = RTE_MIN(nb_used, nb_pkts);
nb_used = RTE_MIN(nb_used, VIRTIO_MBUF_BURST_SZ);
- virtio_rmb(hw->weak_barriers);
-
PMD_RX_LOG(DEBUG, "used:%d", nb_used);
nb_enqueued = 0;
@@ -1552,8 +1548,7 @@ virtio_recv_pkts_inorder(void *rx_queue,
uint16_t rcv_cnt = RTE_MIN((uint16_t)seg_res,
VIRTIO_MBUF_BURST_SZ);
- if (likely(VIRTQUEUE_NUSED(vq) >= rcv_cnt)) {
- virtio_rmb(hw->weak_barriers);
+ if (likely(virtqueue_nused(vq) >= rcv_cnt)) {
num = virtqueue_dequeue_rx_inorder(vq, rcv_pkts, len,
rcv_cnt);
uint16_t extra_idx = 0;
@@ -1644,9 +1639,7 @@ virtio_recv_mergeable_pkts(void *rx_queue,
if (unlikely(hw->started == 0))
return nb_rx;
- nb_used = VIRTQUEUE_NUSED(vq);
-
- virtio_rmb(hw->weak_barriers);
+ nb_used = virtqueue_nused(vq);
PMD_RX_LOG(DEBUG, "used:%d", nb_used);
@@ -1734,8 +1727,7 @@ virtio_recv_mergeable_pkts(void *rx_queue,
uint16_t rcv_cnt = RTE_MIN((uint16_t)seg_res,
VIRTIO_MBUF_BURST_SZ);
- if (likely(VIRTQUEUE_NUSED(vq) >= rcv_cnt)) {
- virtio_rmb(hw->weak_barriers);
+ if (likely(virtqueue_nused(vq) >= rcv_cnt)) {
num = virtqueue_dequeue_burst_rx(vq, rcv_pkts, len,
rcv_cnt);
uint16_t extra_idx = 0;
@@ -2108,9 +2100,9 @@ virtio_xmit_pkts(void *tx
[dpdk-dev] [PATCH v5 2/2] virtio: one way barrier for split vring avail idx
In case VIRTIO_F_ORDER_PLATFORM(36) is not negotiated, then the frontend
and backend are assumed to be implemented in software, that is they can
run on identical CPUs in an SMP configuration.
Thus a weak form of memory barriers like rte_smp_r/wmb, other than
rte_cio_r/wmb, is sufficient for this case(vq->hw->weak_barriers == 1)
and yields better performance.
For the above case, this patch helps yielding even better performance
by replacing the two-way barriers with C11 one-way barriers for avail
index in split ring.
Signed-off-by: Joyce Kong
Reviewed-by: Gavin Hu
Reviewed-by: Maxime Coquelin
---
drivers/net/virtio/virtqueue.h | 20 ++--
lib/librte_vhost/virtio_net.c | 14 +-
2 files changed, 23 insertions(+), 11 deletions(-)
diff --git a/drivers/net/virtio/virtqueue.h b/drivers/net/virtio/virtqueue.h
index 6a70299a9..4fae22400 100644
--- a/drivers/net/virtio/virtqueue.h
+++ b/drivers/net/virtio/virtqueue.h
@@ -500,8 +500,24 @@ void vq_ring_free_inorder(struct virtqueue *vq, uint16_t
desc_idx,
static inline void
vq_update_avail_idx(struct virtqueue *vq)
{
- virtio_wmb(vq->hw->weak_barriers);
- vq->vq_split.ring.avail->idx = vq->vq_avail_idx;
+ if (vq->hw->weak_barriers) {
+ /* x86 prefers to using rte_smp_wmb over __atomic_store_n as
+* it reports a slightly better perf, which comes from the
+* saved branch by the compiler.
+* The if and else branches are identical with the smp and
+* cio barriers both defined as compiler barriers on x86.
+*/
+#ifdef RTE_ARCH_X86_64
+ rte_smp_wmb();
+ vq->vq_split.ring.avail->idx = vq->vq_avail_idx;
+#else
+ __atomic_store_n(&vq->vq_split.ring.avail->idx,
+vq->vq_avail_idx, __ATOMIC_RELEASE);
+#endif
+ } else {
+ rte_cio_wmb();
+ vq->vq_split.ring.avail->idx = vq->vq_avail_idx;
+ }
}
static inline void
diff --git a/lib/librte_vhost/virtio_net.c b/lib/librte_vhost/virtio_net.c
index 494e574c2..db3413dd9 100644
--- a/lib/librte_vhost/virtio_net.c
+++ b/lib/librte_vhost/virtio_net.c
@@ -977,13 +977,11 @@ virtio_dev_rx_split(struct virtio_net *dev, struct
vhost_virtqueue *vq,
struct buf_vector buf_vec[BUF_VECTOR_MAX];
uint16_t avail_head;
- avail_head = *((volatile uint16_t *)&vq->avail->idx);
-
/*
* The ordering between avail index and
* desc reads needs to be enforced.
*/
- rte_smp_rmb();
+ avail_head = __atomic_load_n(&vq->avail->idx, __ATOMIC_ACQUIRE);
rte_prefetch0(&vq->avail->ring[vq->last_avail_idx & (vq->size - 1)]);
@@ -1698,16 +1696,14 @@ virtio_dev_tx_split(struct virtio_net *dev, struct
vhost_virtqueue *vq,
}
}
- free_entries = *((volatile uint16_t *)&vq->avail->idx) -
- vq->last_avail_idx;
- if (free_entries == 0)
- return 0;
-
/*
* The ordering between avail index and
* desc reads needs to be enforced.
*/
- rte_smp_rmb();
+ free_entries = __atomic_load_n(&vq->avail->idx, __ATOMIC_ACQUIRE) -
+ vq->last_avail_idx;
+ if (free_entries == 0)
+ return 0;
rte_prefetch0(&vq->avail->ring[vq->last_avail_idx & (vq->size - 1)]);
--
2.17.1
[dpdk-dev] [PATCH v5 0/2] one way barrier for split vring idx
This patchset replaces the two-way barriers with C11 one-way barriers for split vring idx, when the frontend and backend are implemented in software. By doing PVP benchmarking, the test result of 2c1q showed the throughput increased 20% with the 0.001% of acceptable loss rate on Thunderx2 platform.[1] By doing vhost-user + virtio-user case benchmarking, 4% performance gain was measured on Thunderx2 platform by 2c1q RFC2544 test of 0.001% loss, and 4.7% performance was improved on Dell platform by 1c1q RFC2544 test of zero packet loss.[2] [1]https://doc.dpdk.org/guides/howto/pvp_reference_benchmark.html [2]https://doc.dpdk.org/dts/test_plans/pvp_multi_paths_performance_test_plan.html PVP test with virtio 1.0 normal path v5: Fix the compling issue when 'CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_DUMP=y' is enabled. v4: Remove some duplicated code comment. v3: Modify some style error. v2: Add test performance statistics. Joyce Kong (2): virtio: one way barrier for split vring used idx virtio: one way barrier for split vring avail idx drivers/net/virtio/virtio_ethdev.c| 7 +-- drivers/net/virtio/virtio_ring.h | 2 +- drivers/net/virtio/virtio_rxtx.c | 35 --- drivers/net/virtio/virtio_rxtx_simple_neon.c | 5 +- drivers/net/virtio/virtio_rxtx_simple_sse.c | 4 +- .../net/virtio/virtio_user/virtio_user_dev.c | 8 ++- drivers/net/virtio/virtqueue.c| 2 +- drivers/net/virtio/virtqueue.h| 58 --- lib/librte_vhost/virtio_net.c | 19 +++--- 9 files changed, 81 insertions(+), 59 deletions(-) -- 2.17.1
Re: [dpdk-dev] eal: can not run secondary process on openstack environment
On 30-Apr-20 5:14 AM, 陈亚辉-云杉研发部 wrote: Deleting xdg_runtime_dir and fallback, runtime_dir will always be "/var/run" defined by code: static const char *default_runtime_dir = "/var/run" I'm not sure this is a good solution. Generally, IMO, having separate directories for DPDK processes for different users is a good thing. Also, XDG directory exists for a reason, and i think on some distros /var/run is not even there any more (or symlinked to /run, or...). So, i don't think this is the way to go. David, thoughts? -- Thanks, Anatoly
Re: [dpdk-dev] [PATCH] app/testpmd: add cmdline option to set Rx mq mode
Hi Xiaoyu,
> -Original Message-
> From: Xiaoyu Min
> Sent: Wednesday, April 29, 2020 2:04 PM
> To: Lu, Wenzhuo ; Wu, Jingjing
> ; Iremonger, Bernard
> ; Mcnamara, John
> ; Kovacevic, Marko
>
> Cc: dev@dpdk.org
> Subject: [PATCH] app/testpmd: add cmdline option to set Rx mq mode
>
> One new cmdline option `--rx-mq-mode` is added in order to have the
> possibility to check whether PMD handle the mq mode correctly or not.
>
> The reason is some NICs need to do different settings based on different RX
> mq mode, i.e RSS or not.
>
> With this support in testpmd, the above scenario can be tested easily.
>
> Signed-off-by: Xiaoyu Min
> ---
> app/test-pmd/parameters.c | 12
> app/test-pmd/testpmd.c| 17 ++---
> app/test-pmd/testpmd.h| 3 +++
> doc/guides/testpmd_app_ug/run_app.rst | 7 +++
> 4 files changed, 36 insertions(+), 3 deletions(-)
>
> diff --git a/app/test-pmd/parameters.c b/app/test-pmd/parameters.c index
> 30c1753c32..a9dd58e96b 100644
> --- a/app/test-pmd/parameters.c
> +++ b/app/test-pmd/parameters.c
> @@ -212,6 +212,7 @@ usage(char* progname)
> printf(" --noisy-lkup-num-writes=N: do N random reads and writes
> per packet\n");
> printf(" --no-iova-contig: mempool memory can be IOVA non
> contiguous. "
> "valid only with --mp-alloc=anon\n");
> + printf(" --rx-mq-mode=0xX: hexadecimal bitmask of RX mq
> mode\n");
> }
>
> #ifdef RTE_LIBRTE_CMDLINE
> @@ -670,6 +671,7 @@ launch_args_parse(int argc, char** argv)
> { "noisy-lkup-num-reads", 1, 0, 0 },
> { "noisy-lkup-num-reads-writes", 1, 0, 0 },
> { "no-iova-contig", 0, 0, 0 },
> + { "rx-mq-mode", 1, 0, 0 },
> { 0, 0, 0, 0 },
> };
>
> @@ -1363,6 +1365,16 @@ launch_args_parse(int argc, char** argv)
> }
> if (!strcmp(lgopts[opt_idx].name, "no-iova-contig"))
> mempool_flags =
> MEMPOOL_F_NO_IOVA_CONTIG;
> +
> + if (!strcmp(lgopts[opt_idx].name, "rx-mq-mode")) {
> + char *end = NULL;
> + n = strtoul(optarg, &end, 16);
> + if (n >= 0)
> + rx_mq_mode = (enum
> rte_eth_rx_mq_mode)n;
> + else
> + rte_exit(EXIT_FAILURE,
> + "rx-mq-mode must be >=
> 0\n");
> + }
> break;
> case 'h':
> usage(argv[0]);
> diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c index
> 99bacddbfd..9536d6ee27 100644
> --- a/app/test-pmd/testpmd.c
> +++ b/app/test-pmd/testpmd.c
> @@ -482,6 +482,11 @@ uint8_t bitrate_enabled; struct gro_status
> gro_ports[RTE_MAX_ETHPORTS]; uint8_t gro_flush_cycles =
> GRO_DEFAULT_FLUSH_CYCLES;
>
> +/*
> + * RX mq mode value set in the commandline */ enum
> rte_eth_rx_mq_mode
> +rx_mq_mode = ETH_MQ_RX_VMDQ_DCB_RSS;
> +
> /* Forward function declarations */
> static void setup_attached_port(portid_t pi); static void
> map_port_queue_stats_mapping_registers(portid_t pi, @@ -3337,7 +3342,9
> @@ init_port_config(void)
>
> if (port->dcb_flag == 0) {
> if( port->dev_conf.rx_adv_conf.rss_conf.rss_hf != 0)
> - port->dev_conf.rxmode.mq_mode =
> ETH_MQ_RX_RSS;
> + port->dev_conf.rxmode.mq_mode =
> + (enum rte_eth_rx_mq_mode)
> + (rx_mq_mode &
> ETH_MQ_RX_RSS);
> else
> port->dev_conf.rxmode.mq_mode =
> ETH_MQ_RX_NONE;
> }
> @@ -3438,7 +3445,9 @@ get_eth_dcb_conf(portid_t pid, struct
> rte_eth_conf *eth_conf,
> }
>
> /* set DCB mode of RX and TX of multiple queues */
> - eth_conf->rxmode.mq_mode = ETH_MQ_RX_VMDQ_DCB;
> + eth_conf->rxmode.mq_mode =
> + (enum rte_eth_rx_mq_mode)
> + (rx_mq_mode &
> ETH_MQ_RX_VMDQ_DCB);
> eth_conf->txmode.mq_mode = ETH_MQ_TX_VMDQ_DCB;
> } else {
> struct rte_eth_dcb_rx_conf *rx_conf = @@ -3458,7 +3467,9
> @@ get_eth_dcb_conf(portid_t pid, struct rte_eth_conf *eth_conf,
> tx_conf->dcb_tc[i] = i % num_tcs;
> }
>
> - eth_conf->rxmode.mq_mode = ETH_MQ_RX_DCB_RSS;
> + eth_conf->rxmode.mq_mode =
> + (enum rte_eth_rx_mq_mode)
> + (rx_mq_mode &
> ETH_MQ_RX_DCB_RSS);
> eth_conf->rx_adv_conf.rss_conf = rss_conf;
> eth_conf->txmode.mq_mode = ETH_MQ_TX_DCB;
> }
> diff --gi
Re: [dpdk-dev] [PATCH] net/mlx5: fix assert in dynamic metadata handling
Hi,
> -Original Message-
> From: Alexander Kozyrev
> Sent: Monday, April 27, 2020 9:20 PM
> To: dev@dpdk.org
> Cc: sta...@dpdk.org; Raslan Darawsheh ; Slava
> Ovsiienko
> Subject: [PATCH] net/mlx5: fix assert in dynamic metadata handling
>
> The assert in dynamic flow metadata handling is wrong after the
> fix for the performance degradation. The assert meant to check
> the metadata mask but was updated with the metadata offset instead.
> Fix this assert and restore proper metadata mask checking.
>
> Fixes: 6c55b62 ("net/mlx5: set dynamic flow metadata in Rx queues")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Alexander Kozyrev
> Acked-by: Viacheslav Ovsiienko
> ---
> drivers/net/mlx5/mlx5_rxtx_vec_altivec.h | 7 ---
> drivers/net/mlx5/mlx5_rxtx_vec_neon.h| 5 +++--
> drivers/net/mlx5/mlx5_rxtx_vec_sse.h | 3 ++-
> 3 files changed, 9 insertions(+), 6 deletions(-)
>
Patch applied to next-net-mlx,
Kindest regards,
Raslan Darawsheh
Re: [dpdk-dev] [PATCH v4 0/2] one way barrier for split vring idx
> -Original Message- > From: Maxime Coquelin > Sent: Thursday, April 30, 2020 5:09 PM > To: Ferruh Yigit ; Joyce Kong > ; step...@networkplumber.org; > xiaolong...@intel.com; tiwei@intel.com; zhihong.w...@intel.com; > tho...@monjalon.net; jer...@marvell.com; yinan.w...@intel.com; > Honnappa Nagarahalli ; Gavin Hu > > Cc: nd ; dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH v4 0/2] one way barrier for split vring idx > > > > On 4/29/20 7:45 PM, Ferruh Yigit wrote: > > On 4/24/2020 4:39 AM, Joyce Kong wrote: > >> This patchset replaces the two-way barriers with C11 one-way barriers > >> for split vring idx, when the frontend and backend are implemented in > >> software. > >> > >> By doing PVP benchmarking, the test result of 2c1q showed the > >> throughput increased 20% with the 0.001% of acceptable loss rate on > >> Thunderx2 platform.[1] > >> > >> By doing vhost-user + virtio-user case benchmarking, 4% performance > >> gain was measured on Thunderx2 platform by 2c1q RFC2544 test of > >> 0.001% loss, and 4.7% performance was improved on Dell platform by > >> 1c1q RFC2544 test of zero packet loss.[2] > >> > >> [1]https://doc.dpdk.org/guides/howto/pvp_reference_benchmark.html > >> > [2]https://doc.dpdk.org/dts/test_plans/pvp_multi_paths_performance_test > _plan.html > >>PVP test with virtio 1.0 normal path > >> > >> v4: > >> Remove some duplicated code comment. > >> > >> v3: > >> Modify some style error. > >> > >> v2: > >> Add test performance statistics. > >> > >> Joyce Kong (2): > >> virtio: one way barrier for split vring used idx > >> virtio: one way barrier for split vring avail idx > >> > > > > Hi Joyce, > > > > When 'CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_DUMP=y' enabled, build fails. > Can > > you please check it? > > Hi Joyce, > > I will need the fix today, just send a v5 for the series. > If not possible to do it today, please let me know. > > Maxime > Hi Maxime, I have just fixed the issue and sent out the v5, please have a review. Thanks. > > > Thanks, > > ferruh > >
Re: [dpdk-dev] [PATCH v2] net/ice: support mark only action for FDIR
> -Original Message-
> From: Su, Simei
> Sent: Tuesday, April 14, 2020 11:11 PM
> To: Zhang, Qi Z ; Ye, Xiaolong
> Cc: dev@dpdk.org; Cao, Yahui ; Su, Simei
> ; sta...@dpdk.org
> Subject: [PATCH v2] net/ice: support mark only action for FDIR
>
> This patch fixes issue that doesn't support mark only case.
> Mark only action is equal to mark + passthru action.
>
> Fixes: f5cafa961fae ("net/ice: add flow director create and destroy")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Simei Su
Acked-by: Qi Zhang
Re: [dpdk-dev] [RFC] ring: count and empty optimizations
> From: Honnappa Nagarahalli [mailto:honnappa.nagaraha...@arm.com]
> Sent: Thursday, April 30, 2020 3:12 AM
>
>
>
> >
> > Hi Morten,
> >
> > On Tue, Apr 28, 2020 at 03:53:15PM +0200, Morten Brørup wrote:
> > > Olivier (maintainer of the Ring),
> >
> > I'm not anymore, CC'ing Konstantin and Honnappa.
> >
> > > I would like to suggest a couple of minor optimizations to the ring
> library.
> > >
> > >
> > > 1. Testing if the ring is empty is as simple as comparing the
> producer and
> > consumer pointers:
> > >
> > > static inline int
> > > rte_ring_empty(const struct rte_ring *r) {
> > > - return rte_ring_count(r) == 0;
> > > + uint32_t prod_tail = r->prod.tail;
> > > + uint32_t cons_tail = r->cons.tail;
> > > + return cons_tail == prod_tail;
> > > }
> > >
> > > In theory, this optimization reduces the number of potential cache
> misses
> > from 3 to 2 by not having to read r->mask in rte_ring_count().
> >
> > This one looks correct to me.
> >
> >
> > > 2. It is not possible to enqueue more elements than the capacity of
> a ring,
> > so the count function does not need to test if the capacity is
> exceeded:
> > >
> > > static inline unsigned
> > > rte_ring_count(const struct rte_ring *r) {
> > > uint32_t prod_tail = r->prod.tail;
> > > uint32_t cons_tail = r->cons.tail;
> > > uint32_t count = (prod_tail - cons_tail) & r->mask;
> > > - return (count > r->capacity) ? r->capacity : count;
> > > + return count;
> > > }
> > >
> > > I cannot even come up with a race condition in this function where
> the
> > count would exceed the capacity. Maybe I missed something?
> >
> > Since there is no memory barrier, the order in which prod_tail and
> cons_tail
> > are fetched is not guaranteed. Or the thread could be interrupted by
> the
> > kernel in between.
> The '__rte_ring_move_prod_head' function ensures that the distance
> between prod.head and cons.tail is always within the capacity
> irrespective of whether the consumers/producers are sleeping.
Yes, this is exactly what I was thinking.
The tails are the pointers after any updates, which is shown very nicely in the
documentation.
And certainly prod.tail will not move further ahead than prod.head.
So it makes sense using the tails outside the functions that move the pointers.
Olivier found the race I couldn't find:
1. The thread calls rte_ring_count(), and since there is no memory barrier it
reads cons.tail, and has not yet read prod.tail.
2. Other threads use the ring simultaneously. A consumer thread moves cons.tail
ahead and a producer thread then moves prod.tail ahead. Note: Without first
moving cons.tail ahead, prod.tail cannot move too far ahead.
3. The thread proceeds to read prod.tail. Now the count is completely
incorrect, and may even exceed the capacity.
Olivier pointed out that this could happen if the rte_ring_count thread is
interrupted by the kernel, and I agree. However, intuitively I don't think that
it can happen in a non-EAL thread, because the consumer thread needs to finish
moving cons.tail before the producer thread can move prod.tail too far ahead.
And by then the rte_ring_count thread has had plenty of time to read prod.tail.
But it could happen in theory.
> > This function may probably return invalid results in MC/MP cases.
> > We just ensure that the result is between 0 and r->capacity.
So should we update the documentation to say that it might return an incorrect
count (if there is a race), or should we fix the function to always provide a
correct value?
Furthermore, the same race condition probably affects rte_ring_empty()
similarly, even in my improved version.
And do these functions need to support non-EAL threads? I don't think so. What
do you think?
-Morten
[dpdk-dev] [PATCH] maintainers: update for ice
Replace Wenzhuo Lu with Qi Zhang. Signed-off-by: Qi Zhang --- MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index e05c80504..a2f031b4a 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -694,7 +694,7 @@ F: doc/guides/nics/features/iavf*.ini Intel ice M: Qiming Yang -M: Wenzhuo Lu +M: Qi Zhang T: git://dpdk.org/next/dpdk-next-net-intel F: drivers/net/ice/ F: doc/guides/nics/ice.rst -- 2.13.6
Re: [dpdk-dev] [PATCH v4 0/2] one way barrier for split vring idx
On 4/30/20 11:16 AM, Joyce Kong wrote: >> -Original Message- >> From: Maxime Coquelin >> Sent: Thursday, April 30, 2020 5:09 PM >> To: Ferruh Yigit ; Joyce Kong >> ; step...@networkplumber.org; >> xiaolong...@intel.com; tiwei@intel.com; zhihong.w...@intel.com; >> tho...@monjalon.net; jer...@marvell.com; yinan.w...@intel.com; >> Honnappa Nagarahalli ; Gavin Hu >> >> Cc: nd ; dev@dpdk.org >> Subject: Re: [dpdk-dev] [PATCH v4 0/2] one way barrier for split vring idx >> >> >> >> On 4/29/20 7:45 PM, Ferruh Yigit wrote: >>> On 4/24/2020 4:39 AM, Joyce Kong wrote: This patchset replaces the two-way barriers with C11 one-way barriers for split vring idx, when the frontend and backend are implemented in software. By doing PVP benchmarking, the test result of 2c1q showed the throughput increased 20% with the 0.001% of acceptable loss rate on Thunderx2 platform.[1] By doing vhost-user + virtio-user case benchmarking, 4% performance gain was measured on Thunderx2 platform by 2c1q RFC2544 test of 0.001% loss, and 4.7% performance was improved on Dell platform by 1c1q RFC2544 test of zero packet loss.[2] [1]https://doc.dpdk.org/guides/howto/pvp_reference_benchmark.html >> [2]https://doc.dpdk.org/dts/test_plans/pvp_multi_paths_performance_test >> _plan.html PVP test with virtio 1.0 normal path v4: Remove some duplicated code comment. v3: Modify some style error. v2: Add test performance statistics. Joyce Kong (2): virtio: one way barrier for split vring used idx virtio: one way barrier for split vring avail idx >>> >>> Hi Joyce, >>> >>> When 'CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_DUMP=y' enabled, build fails. >> Can >>> you please check it? >> >> Hi Joyce, >> >> I will need the fix today, just send a v5 for the series. >> If not possible to do it today, please let me know. >> >> Maxime >> > Hi Maxime, > I have just fixed the issue and sent out the v5, please have a review. > Thanks. Thanks! That was fast :) Maxime >> >>> Thanks, >>> ferruh >>> >
Re: [dpdk-dev] [RFC] hash: unify crc32 API header for x86 and ARM
>> -Original Message-
>> From: dev On Behalf Of
>pbhagavat...@marvell.com
>> Sent: Wednesday, April 29, 2020 7:05 PM
>> To: jer...@marvell.com; tho...@monjalon.net; Wang, Yipeng1
>> ; Gobriel, Sameh
>;
>> Richardson, Bruce ; Ruifeng Wang
>>
>> Cc: dev@dpdk.org; Pavan Nikhilesh
>> Subject: [dpdk-dev] [RFC] hash: unify crc32 API header for x86 and
>ARM
>>
>> From: Pavan Nikhilesh
>>
>> Merge crc32 hash calculation public API headers for x86 and ARM,
>> split implementations of x86 and ARM into their respective private
>> headers.
>> This reduces the ifdef code clutter while keeping current ABI intact.
>>
>> Although we install `rte_crc_arm64.h` it is not used in any of the lib or
>> drivers layers. All the libs and drivers use `rte_hash_crc.h` which falls
>> back to SW crc32 calculation for ARM platform.
>
>
>
>> diff --git a/lib/librte_hash/meson.build b/lib/librte_hash/meson.build
>> index 6ab46ae9d..90a180bc8 100644
>> --- a/lib/librte_hash/meson.build
>> +++ b/lib/librte_hash/meson.build
>> @@ -1,8 +1,7 @@
>> # SPDX-License-Identifier: BSD-3-Clause
>> # Copyright(c) 2017 Intel Corporation
>>
>> -headers = files('rte_crc_arm64.h',
>> -'rte_fbk_hash.h',
>> +headers = files('rte_fbk_hash.h',
>> 'rte_hash_crc.h',
>> 'rte_hash.h',
>> 'rte_jhash.h',
>
>Am I right in that previously an application could #include
> and hence if we no
>longer install that file, this will cause a compilation failure on that
>application? Applications shouldn't
>include arch specific headers... but we shouldn't knowingly remove
>publicly accessible includes either.
>
>Perhaps consider just installing a dummy header file if the code cleanup
>in the rest of the patch is desired?
Sure we could either symlink `rte_hash_crc.h` as `rte_crc_arm64.h` or
Just include rte_hash_crc.h in rte_crc_arm64.h for now and remove
rte_crc_arm64.h later with a deprecation notice?
[dpdk-dev] [PATCH v3 0/5] *** Introduce flow perf application ***
Add new application to test rte flow performance from: - Insertion rate. - Deletion rate. - Memory consumption. - PPS forward measurement. --- v3: * Fix passing hairpin queues to hairpin rss action. v2: * reset cpu_time_used every port. * generate different RSS action every flow with different RETA. * Fix in commit log message Wisam Jaddo (5): app/test-flow-perf: add flow performance skeleton app/test-flow-perf: add insertion rate calculation app/test-flow-perf: add deletion rate calculation app/test-flow-perf: add memory dump to app app/test-flow-perf: add packet forwarding support MAINTAINERS |5 + app/Makefile |1 + app/meson.build |1 + app/test-flow-perf/Makefile | 29 + app/test-flow-perf/actions_gen.c | 86 +++ app/test-flow-perf/actions_gen.h | 48 ++ app/test-flow-perf/flow_gen.c| 176 + app/test-flow-perf/flow_gen.h| 61 ++ app/test-flow-perf/items_gen.c | 265 +++ app/test-flow-perf/items_gen.h | 68 ++ app/test-flow-perf/main.c| 1071 ++ app/test-flow-perf/meson.build | 19 + app/test-flow-perf/user_parameters.h | 31 + config/common_base |5 + doc/guides/tools/flow-perf.rst | 265 +++ doc/guides/tools/index.rst |1 + 16 files changed, 2132 insertions(+) create mode 100644 app/test-flow-perf/Makefile create mode 100644 app/test-flow-perf/actions_gen.c create mode 100644 app/test-flow-perf/actions_gen.h create mode 100644 app/test-flow-perf/flow_gen.c create mode 100644 app/test-flow-perf/flow_gen.h create mode 100644 app/test-flow-perf/items_gen.c create mode 100644 app/test-flow-perf/items_gen.h create mode 100644 app/test-flow-perf/main.c create mode 100644 app/test-flow-perf/meson.build create mode 100644 app/test-flow-perf/user_parameters.h create mode 100644 doc/guides/tools/flow-perf.rst -- 2.17.1
[dpdk-dev] [PATCH v3 1/5] app/test-flow-perf: add flow performance skeleton
Add flow performance application skeleton.
Signed-off-by: Wisam Jaddo
---
MAINTAINERS | 5 +
app/Makefile | 1 +
app/meson.build | 1 +
app/test-flow-perf/Makefile | 26 +++
app/test-flow-perf/main.c| 246 +++
app/test-flow-perf/meson.build | 11 ++
app/test-flow-perf/user_parameters.h | 16 ++
config/common_base | 5 +
doc/guides/tools/flow-perf.rst | 69
doc/guides/tools/index.rst | 1 +
10 files changed, 381 insertions(+)
create mode 100644 app/test-flow-perf/Makefile
create mode 100644 app/test-flow-perf/main.c
create mode 100644 app/test-flow-perf/meson.build
create mode 100644 app/test-flow-perf/user_parameters.h
create mode 100644 doc/guides/tools/flow-perf.rst
diff --git a/MAINTAINERS b/MAINTAINERS
index d31a809292..b5632c1bf5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1504,6 +1504,11 @@ T: git://dpdk.org/next/dpdk-next-net
F: app/test-pmd/
F: doc/guides/testpmd_app_ug/
+Flow performance tool
+M: Wisam Jaddo
+F: app/test-flow-perf
+F: doc/guides/flow-perf.rst
+
Compression performance test application
T: git://dpdk.org/next/dpdk-next-crypto
F: app/test-compress-perf/
diff --git a/app/Makefile b/app/Makefile
index 823771c5fc..bd823f3db7 100644
--- a/app/Makefile
+++ b/app/Makefile
@@ -9,6 +9,7 @@ DIRS-$(CONFIG_RTE_PROC_INFO) += proc-info
DIRS-$(CONFIG_RTE_LIBRTE_PDUMP) += pdump
DIRS-$(CONFIG_RTE_LIBRTE_ACL) += test-acl
DIRS-$(CONFIG_RTE_LIBRTE_CMDLINE) += test-cmdline
+DIRS-$(CONFIG_RTE_TEST_FLOW_PERF) += test-flow-perf
DIRS-$(CONFIG_RTE_LIBRTE_FIB) += test-fib
DIRS-$(CONFIG_RTE_LIBRTE_PIPELINE) += test-pipeline
DIRS-$(CONFIG_RTE_LIBRTE_IPSEC) += test-sad
diff --git a/app/meson.build b/app/meson.build
index 0f7fe94649..e26f5b72f5 100644
--- a/app/meson.build
+++ b/app/meson.build
@@ -14,6 +14,7 @@ apps = [
'test-compress-perf',
'test-crypto-perf',
'test-eventdev',
+ 'test-flow-perf',
'test-fib',
'test-pipeline',
'test-pmd',
diff --git a/app/test-flow-perf/Makefile b/app/test-flow-perf/Makefile
new file mode 100644
index 00..45b1fb1464
--- /dev/null
+++ b/app/test-flow-perf/Makefile
@@ -0,0 +1,26 @@
+# SPDX-License-Identifier: BSD-3-Clause
+# Copyright 2020 Mellanox Technologies, Ltd
+
+include $(RTE_SDK)/mk/rte.vars.mk
+
+ifeq ($(CONFIG_RTE_TEST_FLOW_PERF),y)
+
+#
+# library name
+#
+APP = flow_perf
+
+CFLAGS += -DALLOW_EXPERIMENTAL_API
+CFLAGS += -O3
+CFLAGS += $(WERROR_FLAGS)
+CFLAGS += -Wno-deprecated-declarations
+CFLAGS += -Wno-unused-function
+
+#
+# all source are stored in SRCS-y
+#
+SRCS-y += main.c
+
+include $(RTE_SDK)/mk/rte.app.mk
+
+endif
diff --git a/app/test-flow-perf/main.c b/app/test-flow-perf/main.c
new file mode 100644
index 00..156b9ef553
--- /dev/null
+++ b/app/test-flow-perf/main.c
@@ -0,0 +1,246 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ *
+ * This file contain the application main file
+ * This application provides the user the ability to test the
+ * insertion rate for specific rte_flow rule under stress state ~4M rule/
+ *
+ * Then it will also provide packet per second measurement after installing
+ * all rules, the user may send traffic to test the PPS that match the rules
+ * after all rules are installed, to check performance or functionality after
+ * the stress.
+ *
+ * The flows insertion will go for all ports first, then it will print the
+ * results, after that the application will go into forwarding packets mode
+ * it will start receiving traffic if any and then forwarding it back and
+ * gives packet per second measurement.
+ *
+ * Copyright 2020 Mellanox Technologies, Ltd
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "user_parameters.h"
+
+static uint32_t nb_lcores;
+static struct rte_mempool *mbuf_mp;
+
+static void usage(char *progname)
+{
+ printf("\nusage: %s", progname);
+}
+
+static void
+args_parse(int argc, char **argv)
+{
+ char **argvopt;
+ int opt;
+ int opt_idx;
+ static struct option lgopts[] = {
+ /* Control */
+ { "help", 0, 0, 0 },
+ };
+
+ argvopt = argv;
+
+ while ((opt = getopt_long(argc, argvopt, "",
+ lgopts, &opt_idx)) != EOF) {
+ switch (opt) {
+ case 0:
+ if (!strcmp(lgopts[opt_idx].name, "help")) {
+ usage(argv[0]);
+ rte_exit(EXIT_SUCCESS, "Displayed help\n");
+ }
+ break;
+
[dpdk-dev] [PATCH v3 2/5] app/test-flow-perf: add insertion rate calculation
Add insertion rate calculation feature into flow
performance application.
The application now provide the ability to test
insertion rate of specific rte_flow rule, by
stressing it to the NIC, and calculate the
insertion rate.
The application offers some options in the command
line, to configure which rule to apply.
After that the application will start producing
rules with same pattern but increasing the outer IP
source address by 1 each time, thus it will give
different flow each time, and all other items will
have open masks.
The current design have single core insertion rate.
In the future we may have a multi core insertion
rate measurement support in the app.
Signed-off-by: Wisam Jaddo
---
app/test-flow-perf/Makefile | 3 +
app/test-flow-perf/actions_gen.c | 86 ++
app/test-flow-perf/actions_gen.h | 48
app/test-flow-perf/flow_gen.c| 176
app/test-flow-perf/flow_gen.h| 61
app/test-flow-perf/items_gen.c | 265 +
app/test-flow-perf/items_gen.h | 68 +
app/test-flow-perf/main.c| 416 +--
app/test-flow-perf/meson.build | 8 +
app/test-flow-perf/user_parameters.h | 15 +
doc/guides/tools/flow-perf.rst | 186 +++-
11 files changed, 1307 insertions(+), 25 deletions(-)
create mode 100644 app/test-flow-perf/actions_gen.c
create mode 100644 app/test-flow-perf/actions_gen.h
create mode 100644 app/test-flow-perf/flow_gen.c
create mode 100644 app/test-flow-perf/flow_gen.h
create mode 100644 app/test-flow-perf/items_gen.c
create mode 100644 app/test-flow-perf/items_gen.h
diff --git a/app/test-flow-perf/Makefile b/app/test-flow-perf/Makefile
index 45b1fb1464..968c7c60dd 100644
--- a/app/test-flow-perf/Makefile
+++ b/app/test-flow-perf/Makefile
@@ -19,6 +19,9 @@ CFLAGS += -Wno-unused-function
#
# all source are stored in SRCS-y
#
+SRCS-y += actions_gen.c
+SRCS-y += flow_gen.c
+SRCS-y += items_gen.c
SRCS-y += main.c
include $(RTE_SDK)/mk/rte.app.mk
diff --git a/app/test-flow-perf/actions_gen.c b/app/test-flow-perf/actions_gen.c
new file mode 100644
index 00..564ed820e4
--- /dev/null
+++ b/app/test-flow-perf/actions_gen.c
@@ -0,0 +1,86 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ *
+ * The file contains the implementations of actions generators.
+ * Each generator is responsible for preparing it's action instance
+ * and initializing it with needed data.
+ *
+ * Copyright 2020 Mellanox Technologies, Ltd
+ **/
+
+#include
+#include
+#include
+#include
+
+#include "actions_gen.h"
+#include "user_parameters.h"
+
+void
+gen_mark(void)
+{
+ mark_action.id = MARK_ID;
+}
+
+void
+gen_queue(uint16_t queue)
+{
+ queue_action.index = queue;
+}
+
+void
+gen_jump(uint16_t next_table)
+{
+ jump_action.group = next_table;
+}
+
+void
+gen_rss(uint16_t *queues, uint16_t queues_number)
+{
+ uint16_t queue;
+ struct action_rss_data *rss_data;
+ rss_data = rte_malloc("rss_data",
+ sizeof(struct action_rss_data), 0);
+
+ if (rss_data == NULL)
+ rte_exit(EXIT_FAILURE, "No Memory available!");
+
+ *rss_data = (struct action_rss_data){
+ .conf = (struct rte_flow_action_rss){
+ .func = RTE_ETH_HASH_FUNCTION_DEFAULT,
+ .level = 0,
+ .types = ETH_RSS_IP,
+ .key_len = 0,
+ .queue_num = queues_number,
+ .key = 0,
+ .queue = rss_data->queue,
+ },
+ .key = { 0 },
+ .queue = { 0 },
+ };
+
+ for (queue = 0; queue < queues_number; queue++)
+ rss_data->queue[queue] = queues[queue];
+
+ rss_action = &rss_data->conf;
+}
+
+void
+gen_set_meta(void)
+{
+ meta_action.data = RTE_BE32(META_DATA);
+ meta_action.mask = RTE_BE32(0x);
+}
+
+void
+gen_set_tag(void)
+{
+ tag_action.data = RTE_BE32(META_DATA);
+ tag_action.mask = RTE_BE32(0x);
+ tag_action.index = TAG_INDEX;
+}
+
+void
+gen_port_id(void)
+{
+ port_id.id = PORT_ID_DST;
+}
diff --git a/app/test-flow-perf/actions_gen.h b/app/test-flow-perf/actions_gen.h
new file mode 100644
index 00..556d48b871
--- /dev/null
+++ b/app/test-flow-perf/actions_gen.h
@@ -0,0 +1,48 @@
+/** SPDX-License-Identifier: BSD-3-Clause
+ *
+ * This file contains the functions definitions to
+ * generate each supported action.
+ *
+ * Copyright 2020 Mellanox Technologies, Ltd
+ **/
+
+#ifndef _ACTION_GEN_
+#define _ACTION_GEN_
+
+struct rte_flow_action_mark mark_action;
+struct rte_flow_action_queue queue_action;
+struct rte_flow_action_jump jump_action;
+struct rte_flow_action_rss *rss_action;
+struct rte_flow_action_set_meta meta_action;
+struct rte_flow_action_set_tag tag_action;
+struct rte_flow_action_port_id port_id;
+
+/* Storage for struct rte_flow_action_rss includi
[dpdk-dev] [PATCH v3 5/5] app/test-flow-perf: add packet forwarding support
Introduce packet forwarding support to the app to do
some performance measurements.
The measurements are reported in term of packet per
second unit. The forwarding will start after the end
of insertion/deletion operations.
The support has single and multi core performance measurements.
Signed-off-by: Wisam Jaddo
---
app/test-flow-perf/main.c | 300 +
doc/guides/tools/flow-perf.rst | 6 +
2 files changed, 306 insertions(+)
diff --git a/app/test-flow-perf/main.c b/app/test-flow-perf/main.c
index 95435910de..2596d05dc2 100644
--- a/app/test-flow-perf/main.c
+++ b/app/test-flow-perf/main.c
@@ -60,14 +60,45 @@ static uint8_t flow_group;
static uint16_t flow_items;
static uint16_t flow_actions;
static uint8_t flow_attrs;
+
static volatile bool force_quit;
static volatile bool dump_iterations;
static volatile bool dump_socket_mem_flag;
static volatile bool delete_flag;
+static volatile bool enable_fwd;
+
static struct rte_mempool *mbuf_mp;
static uint32_t nb_lcores;
static uint32_t flows_count;
static uint32_t iterations_number;
+static uint32_t nb_lcores;
+
+#define MAX_PKT_BURST 32
+#define LCORE_MODE_PKT 1
+#define LCORE_MODE_STATS 2
+#define MAX_STREAMS 64
+#define MAX_LCORES 64
+
+struct stream {
+ int tx_port;
+ int tx_queue;
+ int rx_port;
+ int rx_queue;
+};
+
+struct lcore_info {
+ int mode;
+ int streams_nb;
+ struct stream streams[MAX_STREAMS];
+ /* stats */
+ uint64_t tx_pkts;
+ uint64_t tx_drops;
+ uint64_t rx_pkts;
+ struct rte_mbuf *pkts[MAX_PKT_BURST];
+} __attribute__((__aligned__(64))); /* let it be cacheline aligned */
+
+
+static struct lcore_info lcore_infos[MAX_LCORES];
static void usage(char *progname)
{
@@ -80,6 +111,8 @@ static void usage(char *progname)
printf(" --deletion-rate: Enable deletion rate"
" calculations\n");
printf(" --dump-socket-mem: to dump all socket memory\n");
+ printf(" --enable-fwd: to enable packets forwarding"
+ " after insertion\n");
printf("To set flow attributes:\n");
printf(" --ingress: set ingress attribute in flows\n");
@@ -130,6 +163,7 @@ args_parse(int argc, char **argv)
{ "dump-iterations",0, 0, 0 },
{ "deletion-rate", 0, 0, 0 },
{ "dump-socket-mem",0, 0, 0 },
+ { "enable-fwd", 0, 0, 0 },
/* Attributes */
{ "ingress",0, 0, 0 },
{ "egress", 0, 0, 0 },
@@ -315,6 +349,8 @@ args_parse(int argc, char **argv)
delete_flag = true;
if (!strcmp(lgopts[opt_idx].name, "dump-socket-mem"))
dump_socket_mem_flag = true;
+ if (!strcmp(lgopts[opt_idx].name, "enable-fwd"))
+ enable_fwd = true;
break;
default:
usage(argv[0]);
@@ -582,6 +618,265 @@ signal_handler(int signum)
}
}
+static inline uint16_t
+do_rx(struct lcore_info *li, uint16_t rx_port, uint16_t rx_queue)
+{
+ uint16_t cnt = 0;
+ cnt = rte_eth_rx_burst(rx_port, rx_queue, li->pkts, MAX_PKT_BURST);
+ li->rx_pkts += cnt;
+ return cnt;
+}
+
+static inline void
+do_tx(struct lcore_info *li, uint16_t cnt, uint16_t tx_port,
+ uint16_t tx_queue)
+{
+ uint16_t nr_tx = 0;
+ uint16_t i;
+
+ nr_tx = rte_eth_tx_burst(tx_port, tx_queue, li->pkts, cnt);
+ li->tx_pkts += nr_tx;
+ li->tx_drops += cnt - nr_tx;
+
+ for (i = nr_tx; i < cnt; i++)
+ rte_pktmbuf_free(li->pkts[i]);
+}
+
+/*
+ * Method to convert numbers into pretty numbers that easy
+ * to read. The design here is to add comma after each three
+ * digits and set all of this inside buffer.
+ *
+ * For example if n = 1799321, the output will be
+ * 1,799,321 after this method which is easier to read.
+ */
+static char *
+pretty_number(uint64_t n, char *buf)
+{
+ char p[6][4];
+ int i = 0;
+ int off = 0;
+
+ while (n > 1000) {
+ sprintf(p[i], "%03d", (int)(n % 1000));
+ n /= 1000;
+ i += 1;
+ }
+
+ sprintf(p[i++], "%d", (int)n);
+
+ while (i--)
+ off += sprintf(buf + off, "%s,", p[i]);
+ buf[strlen(buf) - 1] = '\0';
+
+ return buf;
+}
+
+static void
+packet_per_second_stats(void)
+{
+ struct lcore_info *old;
+ struct lcore_info *li, *oli;
+ int nr_lines = 0;
+ int i;
+
+ old = rte_zmalloc("old",
+ sizeof(struct lcore_info) * MAX_LCORES, 0);
+ if (old == NULL)
+ rte_exit(EXIT_FAILURE, "No Memory available!");
+
+ memcpy(old, lcore_infos,
+ sizeof(struct lcore_info) * MAX_LCORES)
[dpdk-dev] [PATCH v3 4/5] app/test-flow-perf: add memory dump to app
Introduce new feature to dump memory statistics of each socket
and a total for all before and after the creation.
This will give two main advantage:
1- Check the memory consumption for large number of flows
"insertion rate scenario alone"
2- Check that no memory leackage after doing insertion then
deletion.
Signed-off-by: Suanming Mou
Signed-off-by: Wisam Jaddo
---
app/test-flow-perf/main.c | 69 ++
doc/guides/tools/flow-perf.rst | 6 ++-
2 files changed, 74 insertions(+), 1 deletion(-)
diff --git a/app/test-flow-perf/main.c b/app/test-flow-perf/main.c
index 7c11c0b577..95435910de 100644
--- a/app/test-flow-perf/main.c
+++ b/app/test-flow-perf/main.c
@@ -62,6 +62,7 @@ static uint16_t flow_actions;
static uint8_t flow_attrs;
static volatile bool force_quit;
static volatile bool dump_iterations;
+static volatile bool dump_socket_mem_flag;
static volatile bool delete_flag;
static struct rte_mempool *mbuf_mp;
static uint32_t nb_lcores;
@@ -78,6 +79,7 @@ static void usage(char *progname)
" iteration\n");
printf(" --deletion-rate: Enable deletion rate"
" calculations\n");
+ printf(" --dump-socket-mem: to dump all socket memory\n");
printf("To set flow attributes:\n");
printf(" --ingress: set ingress attribute in flows\n");
@@ -127,6 +129,7 @@ args_parse(int argc, char **argv)
{ "flows-count",1, 0, 0 },
{ "dump-iterations",0, 0, 0 },
{ "deletion-rate", 0, 0, 0 },
+ { "dump-socket-mem",0, 0, 0 },
/* Attributes */
{ "ingress",0, 0, 0 },
{ "egress", 0, 0, 0 },
@@ -310,6 +313,8 @@ args_parse(int argc, char **argv)
dump_iterations = true;
if (!strcmp(lgopts[opt_idx].name, "deletion-rate"))
delete_flag = true;
+ if (!strcmp(lgopts[opt_idx].name, "dump-socket-mem"))
+ dump_socket_mem_flag = true;
break;
default:
usage(argv[0]);
@@ -321,6 +326,62 @@ args_parse(int argc, char **argv)
printf("end_flow\n");
}
+/* Dump the socket memory statistics on console */
+static size_t
+dump_socket_mem(FILE *f)
+{
+ struct rte_malloc_socket_stats socket_stats;
+ unsigned int i = 0;
+ size_t total = 0;
+ size_t alloc = 0;
+ size_t free = 0;
+ unsigned int n_alloc = 0;
+ unsigned int n_free = 0;
+ bool active_nodes = false;
+
+
+ for (i = 0; i < RTE_MAX_NUMA_NODES; i++) {
+ if (rte_malloc_get_socket_stats(i, &socket_stats) ||
+ !socket_stats.heap_totalsz_bytes)
+ continue;
+ active_nodes = true;
+ total += socket_stats.heap_totalsz_bytes;
+ alloc += socket_stats.heap_allocsz_bytes;
+ free += socket_stats.heap_freesz_bytes;
+ n_alloc += socket_stats.alloc_count;
+ n_free += socket_stats.free_count;
+ if (dump_socket_mem_flag) {
+ fprintf(f, "");
+ fprintf(f,
+ "\nSocket %u:\nsize(M) total: %.6lf\nalloc:"
+ " %.6lf(%.3lf%%)\nfree: %.6lf"
+ "\nmax: %.6lf"
+ "\ncount alloc: %u\nfree: %u\n",
+ i,
+ socket_stats.heap_totalsz_bytes / 1.0e6,
+ socket_stats.heap_allocsz_bytes / 1.0e6,
+ (double)socket_stats.heap_allocsz_bytes * 100 /
+ (double)socket_stats.heap_totalsz_bytes,
+ socket_stats.heap_freesz_bytes / 1.0e6,
+ socket_stats.greatest_free_size / 1.0e6,
+ socket_stats.alloc_count,
+ socket_stats.free_count);
+ fprintf(f,
"");
+ }
+ }
+ if (dump_socket_mem_flag && active_nodes) {
+ fprintf(f,
+ "\nTotal: size(M)\ntotal: %.6lf"
+ "\nalloc: %.6lf(%.3lf%%)\nfree: %.6lf"
+ "\ncount alloc: %u\nfree: %u\n",
+ total / 1.0e6, alloc / 1.0e6,
+ (double)alloc * 100 / (double)total, free / 1.0e6,
+ n_alloc, n_free);
+ fprintf(f, "\n");
+ }
+ return alloc;
+}
+
static void
print_flow_error(struct rte_flow_error error)
{
@@ -657,6 +718,7 @@ main(int argc,
[dpdk-dev] [PATCH v3 3/5] app/test-flow-perf: add deletion rate calculation
Add the ability to test deletion rate for flow performance
application.
This feature is disabled by default, and can be enabled by
add "--deletion-rate" in the application command line options.
Signed-off-by: Wisam Jaddo
---
app/test-flow-perf/main.c | 86 ++
doc/guides/tools/flow-perf.rst | 4 ++
2 files changed, 90 insertions(+)
diff --git a/app/test-flow-perf/main.c b/app/test-flow-perf/main.c
index 115af4f302..7c11c0b577 100644
--- a/app/test-flow-perf/main.c
+++ b/app/test-flow-perf/main.c
@@ -62,6 +62,7 @@ static uint16_t flow_actions;
static uint8_t flow_attrs;
static volatile bool force_quit;
static volatile bool dump_iterations;
+static volatile bool delete_flag;
static struct rte_mempool *mbuf_mp;
static uint32_t nb_lcores;
static uint32_t flows_count;
@@ -75,6 +76,8 @@ static void usage(char *progname)
" flows to insert, default is 4,000,000\n");
printf(" --dump-iterations: To print rates for each"
" iteration\n");
+ printf(" --deletion-rate: Enable deletion rate"
+ " calculations\n");
printf("To set flow attributes:\n");
printf(" --ingress: set ingress attribute in flows\n");
@@ -123,6 +126,7 @@ args_parse(int argc, char **argv)
{ "help", 0, 0, 0 },
{ "flows-count",1, 0, 0 },
{ "dump-iterations",0, 0, 0 },
+ { "deletion-rate", 0, 0, 0 },
/* Attributes */
{ "ingress",0, 0, 0 },
{ "egress", 0, 0, 0 },
@@ -304,6 +308,8 @@ args_parse(int argc, char **argv)
}
if (!strcmp(lgopts[opt_idx].name, "dump-iterations"))
dump_iterations = true;
+ if (!strcmp(lgopts[opt_idx].name, "deletion-rate"))
+ delete_flag = true;
break;
default:
usage(argv[0]);
@@ -323,9 +329,75 @@ print_flow_error(struct rte_flow_error error)
error.message ? error.message : "(no stated reason)");
}
+static inline void
+destroy_flows(int port_id, struct rte_flow **flow_list)
+{
+ struct rte_flow_error error;
+ clock_t start_iter, end_iter;
+ double cpu_time_used = 0;
+ double flows_rate;
+ double cpu_time_per_iter[MAX_ITERATIONS];
+ double delta;
+ uint32_t i;
+ int iter_id;
+
+ for (i = 0; i < MAX_ITERATIONS; i++)
+ cpu_time_per_iter[i] = -1;
+
+ if (iterations_number > flows_count)
+ iterations_number = flows_count;
+
+ /* Deletion Rate */
+ printf("Flows Deletion on port = %d\n", port_id);
+ start_iter = clock();
+ for (i = 0; i < flows_count; i++) {
+ if (!flow_list[i])
+ break;
+
+ memset(&error, 0x33, sizeof(error));
+ if (rte_flow_destroy(port_id, flow_list[i], &error)) {
+ print_flow_error(error);
+ rte_exit(EXIT_FAILURE, "Error in deleting flow");
+ }
+
+ if (i && !((i + 1) % iterations_number)) {
+ /* Save the deletion rate of each iter */
+ end_iter = clock();
+ delta = (double) (end_iter - start_iter);
+ iter_id = ((i + 1) / iterations_number) - 1;
+ cpu_time_per_iter[iter_id] =
+ delta / CLOCKS_PER_SEC;
+ cpu_time_used += cpu_time_per_iter[iter_id];
+ start_iter = clock();
+ }
+ }
+
+ /* Deletion rate per iteration */
+ if (dump_iterations)
+ for (i = 0; i < MAX_ITERATIONS; i++) {
+ if (cpu_time_per_iter[i] == -1)
+ continue;
+ delta = (double)(iterations_number /
+ cpu_time_per_iter[i]);
+ flows_rate = delta / 1000;
+ printf(":: Iteration #%d: %d flows "
+ "in %f sec[ Rate = %f K/Sec ]\n",
+ i, iterations_number,
+ cpu_time_per_iter[i], flows_rate);
+ }
+
+ /* Deletion rate for all flows */
+ flows_rate = ((double) (flows_count / cpu_time_used) / 1000);
+ printf("\n:: Total flow deletion rate -> %f K/Sec\n",
+ flows_rate);
+ printf(":: The time for deleting %d in flows %f seconds\n",
+ flows_count, cpu_time_used);
+}
+
static inline void
flows_handler(void)
{
+ struct rte_flow **flow_list;
struct rte_flow_error error;
clock_t start_iter, end_iter;
double cpu_time_used;
@@ -33
[dpdk-dev] [Bug 465] app/test compile failed with gcc and clang
https://bugs.dpdk.org/show_bug.cgi?id=465 David Marchand (david.march...@redhat.com) changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #7 from David Marchand (david.march...@redhat.com) --- Ok. The XXX_sub targets have been working from the start in dpdk and should be preferred over jumping into a XXX directory with -C. Thanks. -- You are receiving this mail because: You are the assignee for the bug.
[dpdk-dev] [PATCH v2] examples/vhost_blk: refactor vhost-blk example
Decrease the code and make it easier to read. It's
useful for understanding the inflight APIs and how
packed ring works. Update the RST because the packed
ring patch has been merged to QEMU master and ring_packed
parameter changes to packed.
Fixes: c19beb3f38cd ("examples/vhost_blk: introduce vhost storage sample")
Signed-off-by: Jin Yu
---
V2 - fix build error in 32-bit
---
doc/guides/sample_app_ug/vhost_blk.rst |8 +-
examples/vhost_blk/blk.c | 13 +-
examples/vhost_blk/vhost_blk.c | 1139 ++--
examples/vhost_blk/vhost_blk.h | 39 +-
4 files changed, 494 insertions(+), 705 deletions(-)
diff --git a/doc/guides/sample_app_ug/vhost_blk.rst
b/doc/guides/sample_app_ug/vhost_blk.rst
index 39096e2e4..681de6f3e 100644
--- a/doc/guides/sample_app_ug/vhost_blk.rst
+++ b/doc/guides/sample_app_ug/vhost_blk.rst
@@ -51,7 +51,7 @@ Start the VM
-drive file=os.img,if=none,id=disk \
-device ide-hd,drive=disk,bootindex=0 \
-chardev socket,id=char0,reconnect=1,path=/tmp/vhost.socket \
--device vhost-user-blk-pci,ring_packed=1,chardev=char0,num-queues=1 \
+-device vhost-user-blk-pci,packed=on,chardev=char0,num-queues=1 \
...
.. note::
@@ -59,5 +59,7 @@ Start the VM
Qemu v4.0 or newer version is required.
reconnect=1 means live recovery support that qemu can reconnect vhost_blk
after we restart vhost_blk example.
-ring_packed=1 means the device support packed ring but need the guest
kernel
-version >= 5.0
+packed=on means the device support packed ring but need the guest kernel
+version >= 5.0.
+Now Qemu commit 9bb73502321d46f4d320fa17aa38201445783fc4 both support the
+vhost-blk reconnect and packed ring.
diff --git a/examples/vhost_blk/blk.c b/examples/vhost_blk/blk.c
index 1b0b764b2..9048e2f8a 100644
--- a/examples/vhost_blk/blk.c
+++ b/examples/vhost_blk/blk.c
@@ -50,7 +50,10 @@ vhost_bdev_blk_readwrite(struct vhost_block_dev *bdev,
offset = lba_512 * 512;
- for (i = 0; i < task->iovs_cnt; i++) {
+ /* iovs[0] is the head and iovs[iovs_cnt - 1] is the tail
+* Middle is the data range
+*/
+ for (i = 1; i < task->iovs_cnt - 1; i++) {
if (task->dxfer_dir == BLK_DIR_TO_DEV)
memcpy(bdev->data + offset, task->iovs[i].iov_base,
task->iovs[i].iov_len);
@@ -83,7 +86,7 @@ vhost_bdev_process_blk_commands(struct vhost_block_dev *bdev,
"%s - passed IO buffer is not multiple of 512b"
"(req_idx = %"PRIu16").\n",
task->req->type ? "WRITE" : "READ",
- task->head_idx);
+ task->req_idx);
return VIRTIO_BLK_S_UNSUPP;
}
@@ -98,14 +101,10 @@ vhost_bdev_process_blk_commands(struct vhost_block_dev
*bdev,
"%s - passed IO buffer is not multiple of 512b"
"(req_idx = %"PRIu16").\n",
task->req->type ? "WRITE" : "READ",
- task->head_idx);
+ task->req_idx);
return VIRTIO_BLK_S_UNSUPP;
}
- if (task->readtype) {
- fprintf(stderr, "type isn't right\n");
- return VIRTIO_BLK_S_IOERR;
- }
task->dxfer_dir = BLK_DIR_TO_DEV;
vhost_bdev_blk_readwrite(bdev, task,
task->req->sector, task->data_len);
diff --git a/examples/vhost_blk/vhost_blk.c b/examples/vhost_blk/vhost_blk.c
index 74c82a900..82037ea9e 100644
--- a/examples/vhost_blk/vhost_blk.c
+++ b/examples/vhost_blk/vhost_blk.c
@@ -26,15 +26,22 @@
#define MAX_TASK 12
-#define VHOST_BLK_FEATURES ((1ULL << VIRTIO_F_RING_PACKED) | \
+#define VHOST_BLK_FEATURES ((1ULL << VIRTIO_F_RING_PACKED) |\
(1ULL << VIRTIO_F_VERSION_1) |\
(1ULL << VIRTIO_F_NOTIFY_ON_EMPTY) | \
(1ULL << VHOST_USER_F_PROTOCOL_FEATURES))
+#define CTRLR_NAME "vhost.socket"
+
+enum CTRLR_WORKER_STATUS {
+ WORKER_STATE_START = 0,
+ WORKER_STATE_STOP,
+};
+
/* Path to folder where character device will be created. Can be set by user.
*/
static char dev_pathname[PATH_MAX] = "";
static sem_t exit_sem;
-static int g_should_stop = -1;
+static enum CTRLR_WORKER_STATUS worker_thread_status;
struct vhost_blk_ctrlr *
vhost_blk_ctrlr_find(const char *ctrlr_name)
@@ -46,716 +53,478 @@ vhost_blk_ctrlr_find(const char *ctrlr_name)
return g_vhost_ctrlr;
}
-static uint64_t gpa_to_vva(int vid, uint64_t gpa, uint64_t *len)
+static uint64_t
+gpa_to_vva(struct vhost_blk_ctrlr *ctrlr, uint64_t gpa, uint64_t *len)
{
-
Re: [dpdk-dev] [PATCH] kvargs: fix crash when parsing an invalid token on FreeBSD
Tested-by: Huang, ZhiminX
Regards,
HuangZhiMin
-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Olivier Matz
Sent: Wednesday, April 29, 2020 9:17 PM
To: dev@dpdk.org
Cc: sta...@dpdk.org
Subject: [dpdk-dev] [PATCH] kvargs: fix crash when parsing an invalid token on
FreeBSD
The behavior of strtok_r() is not the same between GNU libc and FreeBSD
libc: in the first case, the context is set to "" when the last token is
returned, while in the second case it is set to NULL.
On FreeBSD, the current code crashes because we are dereferencing a NULL
pointer (ctx1). Fix it by first checking if it is NULL. This works with both
GNU and FreeBSD libc.
Fixes: ffcf831454a9 ("kvargs: fix buffer overflow when parsing list")
Cc: sta...@dpdk.org
Signed-off-by: Olivier Matz
---
lib/librte_kvargs/rte_kvargs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/librte_kvargs/rte_kvargs.c b/lib/librte_kvargs/rte_kvargs.c
index 1d815dcd9..285081c86 100644
--- a/lib/librte_kvargs/rte_kvargs.c
+++ b/lib/librte_kvargs/rte_kvargs.c
@@ -50,7 +50,7 @@ rte_kvargs_tokenize(struct rte_kvargs *kvlist, const char
*params)
/* Find the end of the list. */
while (str[strlen(str) - 1] != ']') {
/* Restore the comma erased by strtok_r(). */
- if (ctx1[0] == '\0')
+ if (ctx1 == NULL || ctx1[0] == '\0')
return -1; /* no closing bracket */
str[strlen(str)] = ',';
/* Parse until next comma. */
--
2.25.1
Re: [dpdk-dev] [PATCH] examples/vhost_blk: refactor vhost-blk example
Thanks Maxime.
I just send the V2. Sorry for late.
Jin
> -Original Message-
> From: Maxime Coquelin
> Sent: Thursday, April 30, 2020 5:08 PM
> To: Yu, Jin ; Yigit, Ferruh ; Tiwei
> Bie ; Wang, Zhihong ;
> Mcnamara, John ; Kovacevic, Marko
>
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] examples/vhost_blk: refactor vhost-blk
> example
>
>
>
> On 4/30/20 3:42 AM, Yu, Jin wrote:
> > Got it. I will check and fix it.
>
> Thanks, I will need the fix today, just send a v2.
> If not possible to do it today, please let me know.
>
> Maxime
>
> > Thanks.
> >
> >> -Original Message-
> >> From: Yigit, Ferruh
> >> Sent: Thursday, April 30, 2020 1:54 AM
> >> To: Yu, Jin ; Maxime Coquelin
> >> ; Tiwei Bie ; Wang,
> >> Zhihong ; Mcnamara, John
> >> ; Kovacevic, Marko
> >>
> >> Cc: dev@dpdk.org
> >> Subject: Re: [dpdk-dev] [PATCH] examples/vhost_blk: refactor
> >> vhost-blk example
> >>
> >> On 2/28/2020 3:32 PM, Jin Yu wrote:
> >>> Decrease the code and make it easier to read. It's useful for
> >>> understanding the inflight APIs and how packed ring works. Update
> >>> the RST because the packed ring patch has been merged to QEMU
> master
> >>> and ring_packed parameter changes to packed.
> >>>
> >>> Fixes: c19beb3f38cd ("examples/vhost_blk: introduce vhost storage
> >>> sample")
> >>>
> >>> Signed-off-by: Jin Yu
> >>> ---
> >>> doc/guides/sample_app_ug/vhost_blk.rst |8 +-
> >>> examples/vhost_blk/blk.c | 13 +-
> >>> examples/vhost_blk/vhost_blk.c | 1139 ++--
> >>> examples/vhost_blk/vhost_blk.h | 39 +-
> >>> 4 files changed, 494 insertions(+), 705 deletions(-)
> >>
> >> Getting following build error with 32-bit build, can you please check it:
> >>
> >> .../examples/vhost_blk/vhost_blk.c: In function ‘desc_payload_to_iovs’:
> >> .../examples/vhost_blk/vhost_blk.c:157:9: error: cast to pointer from
> >> integer of different size [-Werror=int-to-pointer-cast]
> >> 157 | vva = (void *)gpa_to_vva(ctrlr,
> >> | ^
> >>
> >
Re: [dpdk-dev] [PATCH v11 6/9] net/virtio: add vectorized packed ring Rx path
On 4/28/2020 9:32 AM, Marvin Liu wrote:
> Optimize packed ring Rx path with SIMD instructions. Solution of
> optimization is pretty like vhost, is that split path into batch and
> single functions. Batch function is further optimized by AVX512
> instructions. Also pad desc extra structure to 16 bytes aligned, thus
> four elements will be saved in one batch.
>
> Signed-off-by: Marvin Liu
> Reviewed-by: Maxime Coquelin
<...>
> @@ -9,6 +9,20 @@ sources += files('virtio_ethdev.c',
> deps += ['kvargs', 'bus_pci']
>
> if arch_subdir == 'x86'
> + if '-mno-avx512f' not in machine_args
> + if cc.has_argument('-mavx512f') and
> cc.has_argument('-mavx512vl') and cc.has_argument('-mavx512bw')
> + cflags += ['-mavx512f', '-mavx512bw', '-mavx512vl']
> + cflags += ['-DCC_AVX512_SUPPORT']
> + if (toolchain == 'gcc' and
> cc.version().version_compare('>=8.3.0'))
> + cflags += '-DVHOST_GCC_UNROLL_PRAGMA'
> + elif (toolchain == 'clang' and
> cc.version().version_compare('>=3.7.0'))
> + cflags += '-DVHOST_CLANG_UNROLL_PRAGMA'
> + elif (toolchain == 'icc' and
> cc.version().version_compare('>=16.0.0'))
> + cflags += '-DVHOST_ICC_UNROLL_PRAGMA'
> + endif
> + sources += files('virtio_rxtx_packed_avx.c')
> + endif
> + endif
This is giving following error in Travis build [1], it is seems this usage is
supported since meson 0.49 [2] and Travis has 0.47 [3], also DPDK supports
version 0.47.1+ [4].
Can you please check for meson v0.47 version way of doing same thing?
[1]
drivers/net/virtio/meson.build:12:19: ERROR: Expecting eol got not.
if '-mno-avx512f' not in machine_args
^
[2]
https://mesonbuild.com/Syntax.html#dictionaries
Since 0.49.0, you can check if a dictionary contains a key like this:
if 'foo' not in my_dict
# This condition is false
endif
[3]
The Meson build system
Version: 0.47.1
[4]
doc/guides/linux_gsg/sys_reqs.rst
* Meson (version 0.47.1+) and ninja
Re: [dpdk-dev] [PATCH] net/mlx5: fix packet length check assert in MPRQ
Hi,
> -Original Message-
> From: Alexander Kozyrev
> Sent: Monday, April 27, 2020 9:23 PM
> To: dev@dpdk.org
> Cc: sta...@dpdk.org; Raslan Darawsheh ; Slava
> Ovsiienko
> Subject: [PATCH] net/mlx5: fix packet length check assert in MPRQ
>
> The assert that checks if there is a enough room for the
> whole packet minus headroom data is written incorrectly.
> The check should be negated in order to work properly.
>
> Fixes: bd0d593 ("net/mlx5: enable MPRQ multi-stride operations")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Alexander Kozyrev
> Acked-by: Viacheslav Ovsiienko
> ---
> drivers/net/mlx5/mlx5_rxtx.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/mlx5/mlx5_rxtx.c b/drivers/net/mlx5/mlx5_rxtx.c
> index a212010..6a17a9a 100644
> --- a/drivers/net/mlx5/mlx5_rxtx.c
> +++ b/drivers/net/mlx5/mlx5_rxtx.c
> @@ -1814,7 +1814,7 @@ enum mlx5_txcmp_code {
> /* Set mbuf head-room. */
> SET_DATA_OFF(pkt, RTE_PKTMBUF_HEADROOM);
> MLX5_ASSERT(pkt->ol_flags ==
> EXT_ATTACHED_MBUF);
> - MLX5_ASSERT(rte_pktmbuf_tailroom(pkt) <
> + MLX5_ASSERT(rte_pktmbuf_tailroom(pkt) >=
> len - (hdrm_overlap > 0 ? hdrm_overlap : 0));
> DATA_LEN(pkt) = len;
> /*
> --
> 1.8.3.1
Patch applied to next-net-mlx,
Kindest regards,
Raslan Darawsheh
Re: [dpdk-dev] [PATCH v5] eal/cpuflags: add x86 based cpu flags
So that isn't the issue either. $ grep RTE_CPUFLAG_NUMFLAGS build-gcc-shared/install/dump/librte_eal.dump 4646: $ grep RTE_CPUFLAG_NUMFLAGS /build/dpdk/reference/v20.02/build-gcc-shared/dump/librte_eal.dump 3296: 1.7-1.fc31 @updates I finally got libabigail complaining about rte_cpu_flag_t, after doing a complete clear down. So the suppression _is_ required. I then spent the following hour trying to identify the gremlin in the system with no luck. In anycase, added my ack below. On 29/04/2020 12:39, David Marchand wrote: > On Tue, Apr 28, 2020 at 6:39 PM Ray Kinsella wrote: >>> diff --git a/devtools/libabigail.abignore b/devtools/libabigail.abignore >>> index a59df8f13..045f436fb 100644 >>> --- a/devtools/libabigail.abignore >>> +++ b/devtools/libabigail.abignore >> >> Kevin - you still have the surpession. >> I am testing locally with 1.7.1, and it doesn't complain when I disable the >> supression. >> Are you seeing something different? > > Using current master libabigail, without the rule Kevin included, I > get the warning: > > 1 function with some indirect sub-type change: > > [C] 'function int rte_cpu_get_flag_enabled(rte_cpu_flag_t)' at > rte_cpuflags.c:144:1 has some indirect sub-type changes: > parameter 1 of type 'enum rte_cpu_flag_t' has sub-type changes: > type size hasn't changed > 17 enumerator insertions: > 'rte_cpu_flag_t::RTE_CPUFLAG_AVX512DQ' value '87' > 'rte_cpu_flag_t::RTE_CPUFLAG_AVX512IFMA' value '88' > 'rte_cpu_flag_t::RTE_CPUFLAG_AVX512CD' value '89' > 'rte_cpu_flag_t::RTE_CPUFLAG_AVX512BW' value '90' > 'rte_cpu_flag_t::RTE_CPUFLAG_AVX512VL' value '91' > 'rte_cpu_flag_t::RTE_CPUFLAG_AVX512VBMI' value '92' > 'rte_cpu_flag_t::RTE_CPUFLAG_AVX512VBMI2' value '93' > 'rte_cpu_flag_t::RTE_CPUFLAG_GFNI' value '94' > 'rte_cpu_flag_t::RTE_CPUFLAG_VAES' value '95' > 'rte_cpu_flag_t::RTE_CPUFLAG_VPCLMULQDQ' value '96' > 'rte_cpu_flag_t::RTE_CPUFLAG_AVX512VNNI' value '97' > 'rte_cpu_flag_t::RTE_CPUFLAG_AVX512BITALG' value '98' > 'rte_cpu_flag_t::RTE_CPUFLAG_AVX512VPOPCNTDQ' value '99' > 'rte_cpu_flag_t::RTE_CPUFLAG_CLDEMOTE' value '100' > 'rte_cpu_flag_t::RTE_CPUFLAG_MOVDIRI' value '101' > 'rte_cpu_flag_t::RTE_CPUFLAG_MOVDIR64B' value '102' > 'rte_cpu_flag_t::RTE_CPUFLAG_AVX512VP2INTERSECT' value '103' > 1 enumerator change: > 'rte_cpu_flag_t::RTE_CPUFLAG_NUMFLAGS' from value '87' to > '104' at rte_cpuflags.h:12:1 > > > Ray, could you check that the reference and new dumps in your env > contain this enum? > > $ grep RTE_CPUFLAG_NUMFLAGS > $HOME/abi/v20.02/x86_64-native-linux-gcc+shared+debug+ASSERT+RTE_IBVERBS_LINK_DLOPEN/dump/librte_eal.dump > > $ grep RTE_CPUFLAG_NUMFLAGS > $HOME/builds/x86_64-native-linux-gcc+shared+debug+ASSERT+RTE_IBVERBS_LINK_DLOPEN/install/dump/librte_eal.dump > > > If you are missing those, you might have built dpdk without debuginfo. > Acked-By: Ray Kinsella
[dpdk-dev] [PATCH] net/bnxt: fix a possible stack smashing
We see a stack smashing as a result of defensive code missing. Once the
nb_pkts is less than RTE_BNXT_DESCS_PER_LOOP, it will be modified to
zero after doing a floor align, and we can not exit the following
receiving packets loop. And the buffers will be overwrite, then the
stack frame was ruined.
Fix the problem by adding defensive code, once the nb_pkts is zero, just
directly return with no packets.
__GI___backtrace (array=0x7fcec7ac3f00, size=256) at
../sysdeps/x86_64/backtrace.c:103
catch_segfault () from /lib64/libSegFault.so
__GI___backtrace (array=array@entry=0x7fcec7ac62e0, size=size@entry=64) at
../sysdeps/x86_64/backtrace.c:103
backtrace_and_maps (do_abort=do_abort@entry=2, written=,
fd=fd@entry=2) at ../sysdeps/unix/sysv/linux/libc_fatal.c:47
__libc_message (do_abort=do_abort@entry=2, fmt=fmt@entry=0x7fced6091c60 "*** %s
***: %s terminated\n") at ../sysdeps/posix/libc_fatal.c:172
__GI___fortify_fail (msg=msg@entry=0x7fced6091c48 "stack smashing detected") at
fortify_fail.c:31
__stack_chk_fail () at stack_chk_fail.c:28
bnxt_recv_pkts_vec (rx_queue=0x14c571f00, rx_pkts=0x7fcec7ac6f28, nb_pkts=0)
rte_eth_rx_burst (port_id=1, queue_id=3, rx_pkts=0x7fcec7ac6f28, nb_pkts=1)
Signed-off-by: yuanlinsi01
Signed-off-by: rongdongsheng
---
drivers/net/bnxt/bnxt_rxtx_vec_sse.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/net/bnxt/bnxt_rxtx_vec_sse.c
b/drivers/net/bnxt/bnxt_rxtx_vec_sse.c
index d0e7910e7..c4adccdbc 100644
--- a/drivers/net/bnxt/bnxt_rxtx_vec_sse.c
+++ b/drivers/net/bnxt/bnxt_rxtx_vec_sse.c
@@ -233,8 +233,13 @@ bnxt_recv_pkts_vec(void *rx_queue, struct rte_mbuf
**rx_pkts,
/* Return no more than RTE_BNXT_MAX_RX_BURST per call. */
nb_pkts = RTE_MIN(nb_pkts, RTE_BNXT_MAX_RX_BURST);
- /* Make nb_pkts an integer multiple of RTE_BNXT_DESCS_PER_LOOP */
+ /*
+* Make nb_pkts an integer multiple of RTE_BNXT_DESCS_PER_LOOP
+* nb_pkts < RTE_BNXT_DESCS_PER_LOOP, just return no packet
+*/
nb_pkts = RTE_ALIGN_FLOOR(nb_pkts, RTE_BNXT_DESCS_PER_LOOP);
+ if (!nb_pkts)
+ return 0;
/* Handle RX burst request */
while (1) {
--
2.11.0
[dpdk-dev] [PATCH] net/bnxt: fix a possible stack smashing
We see a stack smashing as a result of defensive code missing. Once the
nb_pkts is less than RTE_BNXT_DESCS_PER_LOOP, it will be modified to
zero after doing a floor align, and we can not exit the following
receiving packets loop. And the buffers will be overwrite, then the
stack frame was ruined.
Fix the problem by adding defensive code, once the nb_pkts is zero, just
directly return with no packets.
__GI___backtrace (array=0x7fcec7ac3f00, size=256) at
../sysdeps/x86_64/backtrace.c:103
catch_segfault () from /lib64/libSegFault.so
__GI___backtrace (array=array@entry=0x7fcec7ac62e0, size=size@entry=64) at
../sysdeps/x86_64/backtrace.c:103
backtrace_and_maps (do_abort=do_abort@entry=2, written=,
fd=fd@entry=2) at ../sysdeps/unix/sysv/linux/libc_fatal.c:47
__libc_message (do_abort=do_abort@entry=2, fmt=fmt@entry=0x7fced6091c60 "*** %s
***: %s terminated\n") at ../sysdeps/posix/libc_fatal.c:172
__GI___fortify_fail (msg=msg@entry=0x7fced6091c48 "stack smashing detected") at
fortify_fail.c:31
__stack_chk_fail () at stack_chk_fail.c:28
bnxt_recv_pkts_vec (rx_queue=0x14c571f00, rx_pkts=0x7fcec7ac6f28, nb_pkts=0)
rte_eth_rx_burst (port_id=1, queue_id=3, rx_pkts=0x7fcec7ac6f28, nb_pkts=1)
Signed-off-by: yuanlinsi01
Signed-off-by: rongdongsheng
---
drivers/net/bnxt/bnxt_rxtx_vec_sse.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/net/bnxt/bnxt_rxtx_vec_sse.c
b/drivers/net/bnxt/bnxt_rxtx_vec_sse.c
index d0e7910e7..c4adccdbc 100644
--- a/drivers/net/bnxt/bnxt_rxtx_vec_sse.c
+++ b/drivers/net/bnxt/bnxt_rxtx_vec_sse.c
@@ -233,8 +233,13 @@ bnxt_recv_pkts_vec(void *rx_queue, struct rte_mbuf
**rx_pkts,
/* Return no more than RTE_BNXT_MAX_RX_BURST per call. */
nb_pkts = RTE_MIN(nb_pkts, RTE_BNXT_MAX_RX_BURST);
- /* Make nb_pkts an integer multiple of RTE_BNXT_DESCS_PER_LOOP */
+ /*
+* Make nb_pkts an integer multiple of RTE_BNXT_DESCS_PER_LOOP
+* nb_pkts < RTE_BNXT_DESCS_PER_LOOP, just return no packet
+*/
nb_pkts = RTE_ALIGN_FLOOR(nb_pkts, RTE_BNXT_DESCS_PER_LOOP);
+ if (!nb_pkts)
+ return 0;
/* Handle RX burst request */
while (1) {
--
2.11.0
Re: [dpdk-dev] [dpdk-stable] [PATCH v4 2/3] doc: input set requirement of each pctype for FDIR
On 4/30/2020 1:52 AM, Zhao1, Wei wrote:
> Hi,
>
>
>> -Original Message-
>> From: Yigit, Ferruh
>> Sent: Wednesday, April 29, 2020 6:35 PM
>> To: Zhao1, Wei ; dev@dpdk.org
>> Cc: sta...@dpdk.org; Xing, Beilei ;
>> maxime.le...@6wind.com
>> Subject: Re: [dpdk-stable] [PATCH v4 2/3] doc: input set requirement of each
>> pctype for FDIR
>>
>> On 4/29/2020 3:03 AM, Wei Zhao wrote:
>>> Add input set requirement info to i40e doc.
>>>
>>> Bugzilla ID: 403
>>
>> Should this document update backported to the LTS?
>> If so which LTS versions are in the scope, it is better if you can add a
>> fixes tag to
>> help us to figure out that.
>
> Maybe we can use this, it is the latest update for i40 doc.
> Btw, this is not a bug although it is report in bug list.
>
> Fixes: 3d91e097a352 ("doc: add feature support matrix link in i40e guide ")
Hi Wei,
I agree this is not bug, but this documents a limitation for users. And if this
limitation is valid for the stable trees, it make sense to update documentation
for those releases too, so that they can have correct/complete documentation.
I will add the "sta...@dpdk.org" tag to request the backport.
But next question is for which stable trees is this limitation valid, it would
be wrong to document a limitation that doesn't have the feature, how a stable
tree maintainer can know if this issue is valid for a specific stable tree or
not.
For that we need the commit that introduces the mentioned feature (and the
limitation), I don't think the commit above really is that commit, that is
unrelated doc commit, but we need the commit for code.
If you can provide correct fixes line, I will update it in the next-net.
Thanks,
ferruh
>
>>
>>> Signed-off-by: Wei Zhao
>>> ---
>>> doc/guides/nics/i40e.rst | 7 +++
>>> 1 file changed, 7 insertions(+)
>>>
>>> diff --git a/doc/guides/nics/i40e.rst b/doc/guides/nics/i40e.rst index
>>> 416b3904e..f085a357c 100644
>>> --- a/doc/guides/nics/i40e.rst
>>> +++ b/doc/guides/nics/i40e.rst
>>> @@ -747,6 +747,13 @@ Use 16 Bytes RX Descriptor Size As i40e PMD
>>> supports both 16 and 32 bytes RX descriptor sizes, and 16 bytes size can
>> provide helps to high performance of small packets.
>>> Configuration of ``CONFIG_RTE_LIBRTE_I40E_16BYTE_RX_DESC`` in config
>> files can be changed to use 16 bytes size RX descriptors.
>>>
>>> +input set requirement of each pctype for FDIR
>>> +
>>> +
>>> +Each PCTYPE can only have one specific FDIR input set at one time.
>>> +For example, if creating 2 rte_flow rules with different input set
>>> +for one PCTYPE, it is will fail and return the info "Conflict with the
>>> first rule's
>> input set", which means the current rule's input set is conflict with the
>> first
>> rule's. Remove the first rule if want to change the input set of the PCTYPE.
>>> +
>>> Example of getting best performance with l3fwd example
>>> --
>>>
>>>
>
Re: [dpdk-dev] [PATCH v11 6/9] net/virtio: add vectorized packed ring Rx path
On Thu, Apr 30, 2020 at 10:48:35AM +0100, Ferruh Yigit wrote:
> On 4/28/2020 9:32 AM, Marvin Liu wrote:
> > Optimize packed ring Rx path with SIMD instructions. Solution of
> > optimization is pretty like vhost, is that split path into batch and
> > single functions. Batch function is further optimized by AVX512
> > instructions. Also pad desc extra structure to 16 bytes aligned, thus
> > four elements will be saved in one batch.
> >
> > Signed-off-by: Marvin Liu
> > Reviewed-by: Maxime Coquelin
>
> <...>
>
> > @@ -9,6 +9,20 @@ sources += files('virtio_ethdev.c',
> > deps += ['kvargs', 'bus_pci']
> >
> > if arch_subdir == 'x86'
> > + if '-mno-avx512f' not in machine_args
> > + if cc.has_argument('-mavx512f') and
> > cc.has_argument('-mavx512vl') and cc.has_argument('-mavx512bw')
> > + cflags += ['-mavx512f', '-mavx512bw', '-mavx512vl']
> > + cflags += ['-DCC_AVX512_SUPPORT']
> > + if (toolchain == 'gcc' and
> > cc.version().version_compare('>=8.3.0'))
> > + cflags += '-DVHOST_GCC_UNROLL_PRAGMA'
> > + elif (toolchain == 'clang' and
> > cc.version().version_compare('>=3.7.0'))
> > + cflags += '-DVHOST_CLANG_UNROLL_PRAGMA'
> > + elif (toolchain == 'icc' and
> > cc.version().version_compare('>=16.0.0'))
> > + cflags += '-DVHOST_ICC_UNROLL_PRAGMA'
> > + endif
> > + sources += files('virtio_rxtx_packed_avx.c')
> > + endif
> > + endif
>
> This is giving following error in Travis build [1], it is seems this usage is
> supported since meson 0.49 [2] and Travis has 0.47 [3], also DPDK supports
> version 0.47.1+ [4].
>
> Can you please check for meson v0.47 version way of doing same thing?
>
>
.contains() is probably what you want.
/Bruce
Re: [dpdk-dev] [PATCH] test/ring: fix long compilation time
30/04/2020 03:56, Honnappa Nagarahalli: > test_ring.c takes lot of time to compile with clang. It is > reproducable with compiler version 8.0 on Ubuntu 18.04. > Amount of testing is reduced, but attempt is made to keep > the same coverage. > > Reported-by: Aaron Conole > Reported-by: Thomas Monjalon > Signed-off-by: Honnappa Nagarahalli > Reviewed-by: Ruifeng Wang > --- > app/test/test_ring.c | 588 +-- > 1 file changed, 283 insertions(+), 305 deletions(-) That's a lot better! Please could you explain (in the commit log) what was taking so long to compile in the previous code? nit: reproducable -> reproducible
Re: [dpdk-dev] [PATCH] net/mlx5: fix indexed pool bitmap initialization
Hi,
> -Original Message-
> From: Suanming Mou
> Sent: Tuesday, April 28, 2020 12:14 PM
> To: Matan Azrad ; Shahaf Shuler
> ; Slava Ovsiienko
> Cc: dev@dpdk.org; Raslan Darawsheh ;
> lijian.zh...@arm.com
> Subject: [PATCH] net/mlx5: fix indexed pool bitmap initialization
>
> Currently, the indexed memory pool bitmap start address is not aligned
> to cacheline size explicitly. The bitmap initialization requires the
> address should be cacheline aligned. In that case, the initialization
> maybe failed if the address is not cacheline aligned.
>
> Add RTE_CACHE_LINE_ROUNDUP() to the trunk size calculation to make sure
> the bitmap offset address will start with cacheline aligned.
>
> Fixes: a3cf59f56c47 ("net/mlx5: add indexed memory pool")
>
> Signed-off-by: Suanming Mou
> Tested-by: Lijian Zhang
> Acked-by: Viacheslav Ovsiienko
> ---
> drivers/net/mlx5/mlx5_utils.c | 10 +++---
> drivers/net/mlx5/mlx5_utils.h | 2 +-
> 2 files changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/mlx5/mlx5_utils.c b/drivers/net/mlx5/mlx5_utils.c
> index 2146ffd..d29fbcb 100644
> --- a/drivers/net/mlx5/mlx5_utils.c
> +++ b/drivers/net/mlx5/mlx5_utils.c
> @@ -265,7 +265,9 @@ struct mlx5_indexed_pool *
> trunk_size += sizeof(*trunk);
> data_size = mlx5_trunk_size_get(pool, idx);
> bmp_size = rte_bitmap_get_memory_footprint(data_size);
> - trunk_size += data_size * pool->cfg.size + bmp_size;
> + /* rte_bitmap requires memory cacheline aligned. */
> + trunk_size += RTE_CACHE_LINE_ROUNDUP(data_size * pool-
> >cfg.size);
> + trunk_size += bmp_size;
> trunk = pool->cfg.malloc(pool->cfg.type, trunk_size,
>RTE_CACHE_LINE_SIZE, rte_socket_id());
> if (!trunk)
> @@ -278,8 +280,10 @@ struct mlx5_indexed_pool *
> MLX5_ASSERT(pool->free_list == TRUNK_INVALID);
> pool->free_list = idx;
> /* Mark all entries as available. */
> - trunk->bmp = rte_bitmap_init_with_all_set(data_size,
> - &trunk->data[data_size * pool->cfg.size], bmp_size);
> + trunk->bmp = rte_bitmap_init_with_all_set(data_size, &trunk->data
> + [RTE_CACHE_LINE_ROUNDUP(data_size * pool-
> >cfg.size)],
> + bmp_size);
> + MLX5_ASSERT(trunk->bmp);
> pool->n_trunk_valid++;
> #ifdef POOL_DEBUG
> pool->trunk_new++;
> diff --git a/drivers/net/mlx5/mlx5_utils.h b/drivers/net/mlx5/mlx5_utils.h
> index d81ace3..1248caa 100644
> --- a/drivers/net/mlx5/mlx5_utils.h
> +++ b/drivers/net/mlx5/mlx5_utils.h
> @@ -115,7 +115,7 @@ struct mlx5_indexed_trunk {
> uint32_t next; /* Next free trunk in free list. */
> uint32_t free; /* Free entries available */
> struct rte_bitmap *bmp;
> - uint8_t data[] __rte_cache_min_aligned; /* Entry data start. */
> + uint8_t data[] __rte_cache_aligned; /* Entry data start. */
> };
>
> struct mlx5_indexed_pool {
> --
> 1.8.3.1
Patch applied to next-net-mlx,
Kindest regards,
Raslan Darawsheh
[dpdk-dev] [PATCH v4 1/5] app/test-flow-perf: add flow performance skeleton
Add flow performance application skeleton.
Signed-off-by: Wisam Jaddo
---
MAINTAINERS | 5 +
app/Makefile | 1 +
app/meson.build | 1 +
app/test-flow-perf/Makefile | 26 +++
app/test-flow-perf/main.c| 246 +++
app/test-flow-perf/meson.build | 11 ++
app/test-flow-perf/user_parameters.h | 16 ++
config/common_base | 5 +
doc/guides/tools/flow-perf.rst | 69
doc/guides/tools/index.rst | 1 +
10 files changed, 381 insertions(+)
create mode 100644 app/test-flow-perf/Makefile
create mode 100644 app/test-flow-perf/main.c
create mode 100644 app/test-flow-perf/meson.build
create mode 100644 app/test-flow-perf/user_parameters.h
create mode 100644 doc/guides/tools/flow-perf.rst
diff --git a/MAINTAINERS b/MAINTAINERS
index d31a809292..b5632c1bf5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1504,6 +1504,11 @@ T: git://dpdk.org/next/dpdk-next-net
F: app/test-pmd/
F: doc/guides/testpmd_app_ug/
+Flow performance tool
+M: Wisam Jaddo
+F: app/test-flow-perf
+F: doc/guides/flow-perf.rst
+
Compression performance test application
T: git://dpdk.org/next/dpdk-next-crypto
F: app/test-compress-perf/
diff --git a/app/Makefile b/app/Makefile
index 823771c5fc..bd823f3db7 100644
--- a/app/Makefile
+++ b/app/Makefile
@@ -9,6 +9,7 @@ DIRS-$(CONFIG_RTE_PROC_INFO) += proc-info
DIRS-$(CONFIG_RTE_LIBRTE_PDUMP) += pdump
DIRS-$(CONFIG_RTE_LIBRTE_ACL) += test-acl
DIRS-$(CONFIG_RTE_LIBRTE_CMDLINE) += test-cmdline
+DIRS-$(CONFIG_RTE_TEST_FLOW_PERF) += test-flow-perf
DIRS-$(CONFIG_RTE_LIBRTE_FIB) += test-fib
DIRS-$(CONFIG_RTE_LIBRTE_PIPELINE) += test-pipeline
DIRS-$(CONFIG_RTE_LIBRTE_IPSEC) += test-sad
diff --git a/app/meson.build b/app/meson.build
index 0f7fe94649..e26f5b72f5 100644
--- a/app/meson.build
+++ b/app/meson.build
@@ -14,6 +14,7 @@ apps = [
'test-compress-perf',
'test-crypto-perf',
'test-eventdev',
+ 'test-flow-perf',
'test-fib',
'test-pipeline',
'test-pmd',
diff --git a/app/test-flow-perf/Makefile b/app/test-flow-perf/Makefile
new file mode 100644
index 00..45b1fb1464
--- /dev/null
+++ b/app/test-flow-perf/Makefile
@@ -0,0 +1,26 @@
+# SPDX-License-Identifier: BSD-3-Clause
+# Copyright 2020 Mellanox Technologies, Ltd
+
+include $(RTE_SDK)/mk/rte.vars.mk
+
+ifeq ($(CONFIG_RTE_TEST_FLOW_PERF),y)
+
+#
+# library name
+#
+APP = flow_perf
+
+CFLAGS += -DALLOW_EXPERIMENTAL_API
+CFLAGS += -O3
+CFLAGS += $(WERROR_FLAGS)
+CFLAGS += -Wno-deprecated-declarations
+CFLAGS += -Wno-unused-function
+
+#
+# all source are stored in SRCS-y
+#
+SRCS-y += main.c
+
+include $(RTE_SDK)/mk/rte.app.mk
+
+endif
diff --git a/app/test-flow-perf/main.c b/app/test-flow-perf/main.c
new file mode 100644
index 00..156b9ef553
--- /dev/null
+++ b/app/test-flow-perf/main.c
@@ -0,0 +1,246 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ *
+ * This file contain the application main file
+ * This application provides the user the ability to test the
+ * insertion rate for specific rte_flow rule under stress state ~4M rule/
+ *
+ * Then it will also provide packet per second measurement after installing
+ * all rules, the user may send traffic to test the PPS that match the rules
+ * after all rules are installed, to check performance or functionality after
+ * the stress.
+ *
+ * The flows insertion will go for all ports first, then it will print the
+ * results, after that the application will go into forwarding packets mode
+ * it will start receiving traffic if any and then forwarding it back and
+ * gives packet per second measurement.
+ *
+ * Copyright 2020 Mellanox Technologies, Ltd
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "user_parameters.h"
+
+static uint32_t nb_lcores;
+static struct rte_mempool *mbuf_mp;
+
+static void usage(char *progname)
+{
+ printf("\nusage: %s", progname);
+}
+
+static void
+args_parse(int argc, char **argv)
+{
+ char **argvopt;
+ int opt;
+ int opt_idx;
+ static struct option lgopts[] = {
+ /* Control */
+ { "help", 0, 0, 0 },
+ };
+
+ argvopt = argv;
+
+ while ((opt = getopt_long(argc, argvopt, "",
+ lgopts, &opt_idx)) != EOF) {
+ switch (opt) {
+ case 0:
+ if (!strcmp(lgopts[opt_idx].name, "help")) {
+ usage(argv[0]);
+ rte_exit(EXIT_SUCCESS, "Displayed help\n");
+ }
+ break;
+
[dpdk-dev] [PATCH v4 3/5] app/test-flow-perf: add deletion rate calculation
Add the ability to test deletion rate for flow performance
application.
This feature is disabled by default, and can be enabled by
add "--deletion-rate" in the application command line options.
Signed-off-by: Wisam Jaddo
---
app/test-flow-perf/main.c | 86 ++
doc/guides/tools/flow-perf.rst | 4 ++
2 files changed, 90 insertions(+)
diff --git a/app/test-flow-perf/main.c b/app/test-flow-perf/main.c
index 115af4f302..7c11c0b577 100644
--- a/app/test-flow-perf/main.c
+++ b/app/test-flow-perf/main.c
@@ -62,6 +62,7 @@ static uint16_t flow_actions;
static uint8_t flow_attrs;
static volatile bool force_quit;
static volatile bool dump_iterations;
+static volatile bool delete_flag;
static struct rte_mempool *mbuf_mp;
static uint32_t nb_lcores;
static uint32_t flows_count;
@@ -75,6 +76,8 @@ static void usage(char *progname)
" flows to insert, default is 4,000,000\n");
printf(" --dump-iterations: To print rates for each"
" iteration\n");
+ printf(" --deletion-rate: Enable deletion rate"
+ " calculations\n");
printf("To set flow attributes:\n");
printf(" --ingress: set ingress attribute in flows\n");
@@ -123,6 +126,7 @@ args_parse(int argc, char **argv)
{ "help", 0, 0, 0 },
{ "flows-count",1, 0, 0 },
{ "dump-iterations",0, 0, 0 },
+ { "deletion-rate", 0, 0, 0 },
/* Attributes */
{ "ingress",0, 0, 0 },
{ "egress", 0, 0, 0 },
@@ -304,6 +308,8 @@ args_parse(int argc, char **argv)
}
if (!strcmp(lgopts[opt_idx].name, "dump-iterations"))
dump_iterations = true;
+ if (!strcmp(lgopts[opt_idx].name, "deletion-rate"))
+ delete_flag = true;
break;
default:
usage(argv[0]);
@@ -323,9 +329,75 @@ print_flow_error(struct rte_flow_error error)
error.message ? error.message : "(no stated reason)");
}
+static inline void
+destroy_flows(int port_id, struct rte_flow **flow_list)
+{
+ struct rte_flow_error error;
+ clock_t start_iter, end_iter;
+ double cpu_time_used = 0;
+ double flows_rate;
+ double cpu_time_per_iter[MAX_ITERATIONS];
+ double delta;
+ uint32_t i;
+ int iter_id;
+
+ for (i = 0; i < MAX_ITERATIONS; i++)
+ cpu_time_per_iter[i] = -1;
+
+ if (iterations_number > flows_count)
+ iterations_number = flows_count;
+
+ /* Deletion Rate */
+ printf("Flows Deletion on port = %d\n", port_id);
+ start_iter = clock();
+ for (i = 0; i < flows_count; i++) {
+ if (!flow_list[i])
+ break;
+
+ memset(&error, 0x33, sizeof(error));
+ if (rte_flow_destroy(port_id, flow_list[i], &error)) {
+ print_flow_error(error);
+ rte_exit(EXIT_FAILURE, "Error in deleting flow");
+ }
+
+ if (i && !((i + 1) % iterations_number)) {
+ /* Save the deletion rate of each iter */
+ end_iter = clock();
+ delta = (double) (end_iter - start_iter);
+ iter_id = ((i + 1) / iterations_number) - 1;
+ cpu_time_per_iter[iter_id] =
+ delta / CLOCKS_PER_SEC;
+ cpu_time_used += cpu_time_per_iter[iter_id];
+ start_iter = clock();
+ }
+ }
+
+ /* Deletion rate per iteration */
+ if (dump_iterations)
+ for (i = 0; i < MAX_ITERATIONS; i++) {
+ if (cpu_time_per_iter[i] == -1)
+ continue;
+ delta = (double)(iterations_number /
+ cpu_time_per_iter[i]);
+ flows_rate = delta / 1000;
+ printf(":: Iteration #%d: %d flows "
+ "in %f sec[ Rate = %f K/Sec ]\n",
+ i, iterations_number,
+ cpu_time_per_iter[i], flows_rate);
+ }
+
+ /* Deletion rate for all flows */
+ flows_rate = ((double) (flows_count / cpu_time_used) / 1000);
+ printf("\n:: Total flow deletion rate -> %f K/Sec\n",
+ flows_rate);
+ printf(":: The time for deleting %d in flows %f seconds\n",
+ flows_count, cpu_time_used);
+}
+
static inline void
flows_handler(void)
{
+ struct rte_flow **flow_list;
struct rte_flow_error error;
clock_t start_iter, end_iter;
double cpu_time_used;
@@ -33
[dpdk-dev] [PATCH v4 0/5] Introduce flow perf application
Add new application to test rte flow performance from: - Insertion rate. - Deletion rate. - Memory consumption. - PPS forward measurement. --- v4: * Fix compilation error due to variable set but not used. v3: * Fix passing hairpin queues to hairpin rss action. v2: * reset cpu_time_used every port. * generate different RSS action every flow with different RETA. * Fix in commit log message Wisam Jaddo (5): app/test-flow-perf: add flow performance skeleton app/test-flow-perf: add insertion rate calculation app/test-flow-perf: add deletion rate calculation app/test-flow-perf: add memory dump to app app/test-flow-perf: add packet forwarding support MAINTAINERS |5 + app/Makefile |1 + app/meson.build |1 + app/test-flow-perf/Makefile | 29 + app/test-flow-perf/actions_gen.c | 86 +++ app/test-flow-perf/actions_gen.h | 48 ++ app/test-flow-perf/flow_gen.c| 176 + app/test-flow-perf/flow_gen.h| 61 ++ app/test-flow-perf/items_gen.c | 265 +++ app/test-flow-perf/items_gen.h | 68 ++ app/test-flow-perf/main.c| 1071 ++ app/test-flow-perf/meson.build | 19 + app/test-flow-perf/user_parameters.h | 31 + config/common_base |5 + doc/guides/tools/flow-perf.rst | 265 +++ doc/guides/tools/index.rst |1 + 16 files changed, 2132 insertions(+) create mode 100644 app/test-flow-perf/Makefile create mode 100644 app/test-flow-perf/actions_gen.c create mode 100644 app/test-flow-perf/actions_gen.h create mode 100644 app/test-flow-perf/flow_gen.c create mode 100644 app/test-flow-perf/flow_gen.h create mode 100644 app/test-flow-perf/items_gen.c create mode 100644 app/test-flow-perf/items_gen.h create mode 100644 app/test-flow-perf/main.c create mode 100644 app/test-flow-perf/meson.build create mode 100644 app/test-flow-perf/user_parameters.h create mode 100644 doc/guides/tools/flow-perf.rst -- 2.17.1
[dpdk-dev] [PATCH v4 4/5] app/test-flow-perf: add memory dump to app
Introduce new feature to dump memory statistics of each socket
and a total for all before and after the creation.
This will give two main advantage:
1- Check the memory consumption for large number of flows
"insertion rate scenario alone"
2- Check that no memory leackage after doing insertion then
deletion.
Signed-off-by: Suanming Mou
Signed-off-by: Wisam Jaddo
---
app/test-flow-perf/main.c | 69 ++
doc/guides/tools/flow-perf.rst | 6 ++-
2 files changed, 74 insertions(+), 1 deletion(-)
diff --git a/app/test-flow-perf/main.c b/app/test-flow-perf/main.c
index 7c11c0b577..95435910de 100644
--- a/app/test-flow-perf/main.c
+++ b/app/test-flow-perf/main.c
@@ -62,6 +62,7 @@ static uint16_t flow_actions;
static uint8_t flow_attrs;
static volatile bool force_quit;
static volatile bool dump_iterations;
+static volatile bool dump_socket_mem_flag;
static volatile bool delete_flag;
static struct rte_mempool *mbuf_mp;
static uint32_t nb_lcores;
@@ -78,6 +79,7 @@ static void usage(char *progname)
" iteration\n");
printf(" --deletion-rate: Enable deletion rate"
" calculations\n");
+ printf(" --dump-socket-mem: to dump all socket memory\n");
printf("To set flow attributes:\n");
printf(" --ingress: set ingress attribute in flows\n");
@@ -127,6 +129,7 @@ args_parse(int argc, char **argv)
{ "flows-count",1, 0, 0 },
{ "dump-iterations",0, 0, 0 },
{ "deletion-rate", 0, 0, 0 },
+ { "dump-socket-mem",0, 0, 0 },
/* Attributes */
{ "ingress",0, 0, 0 },
{ "egress", 0, 0, 0 },
@@ -310,6 +313,8 @@ args_parse(int argc, char **argv)
dump_iterations = true;
if (!strcmp(lgopts[opt_idx].name, "deletion-rate"))
delete_flag = true;
+ if (!strcmp(lgopts[opt_idx].name, "dump-socket-mem"))
+ dump_socket_mem_flag = true;
break;
default:
usage(argv[0]);
@@ -321,6 +326,62 @@ args_parse(int argc, char **argv)
printf("end_flow\n");
}
+/* Dump the socket memory statistics on console */
+static size_t
+dump_socket_mem(FILE *f)
+{
+ struct rte_malloc_socket_stats socket_stats;
+ unsigned int i = 0;
+ size_t total = 0;
+ size_t alloc = 0;
+ size_t free = 0;
+ unsigned int n_alloc = 0;
+ unsigned int n_free = 0;
+ bool active_nodes = false;
+
+
+ for (i = 0; i < RTE_MAX_NUMA_NODES; i++) {
+ if (rte_malloc_get_socket_stats(i, &socket_stats) ||
+ !socket_stats.heap_totalsz_bytes)
+ continue;
+ active_nodes = true;
+ total += socket_stats.heap_totalsz_bytes;
+ alloc += socket_stats.heap_allocsz_bytes;
+ free += socket_stats.heap_freesz_bytes;
+ n_alloc += socket_stats.alloc_count;
+ n_free += socket_stats.free_count;
+ if (dump_socket_mem_flag) {
+ fprintf(f, "");
+ fprintf(f,
+ "\nSocket %u:\nsize(M) total: %.6lf\nalloc:"
+ " %.6lf(%.3lf%%)\nfree: %.6lf"
+ "\nmax: %.6lf"
+ "\ncount alloc: %u\nfree: %u\n",
+ i,
+ socket_stats.heap_totalsz_bytes / 1.0e6,
+ socket_stats.heap_allocsz_bytes / 1.0e6,
+ (double)socket_stats.heap_allocsz_bytes * 100 /
+ (double)socket_stats.heap_totalsz_bytes,
+ socket_stats.heap_freesz_bytes / 1.0e6,
+ socket_stats.greatest_free_size / 1.0e6,
+ socket_stats.alloc_count,
+ socket_stats.free_count);
+ fprintf(f,
"");
+ }
+ }
+ if (dump_socket_mem_flag && active_nodes) {
+ fprintf(f,
+ "\nTotal: size(M)\ntotal: %.6lf"
+ "\nalloc: %.6lf(%.3lf%%)\nfree: %.6lf"
+ "\ncount alloc: %u\nfree: %u\n",
+ total / 1.0e6, alloc / 1.0e6,
+ (double)alloc * 100 / (double)total, free / 1.0e6,
+ n_alloc, n_free);
+ fprintf(f, "\n");
+ }
+ return alloc;
+}
+
static void
print_flow_error(struct rte_flow_error error)
{
@@ -657,6 +718,7 @@ main(int argc,
[dpdk-dev] [PATCH v4 5/5] app/test-flow-perf: add packet forwarding support
Introduce packet forwarding support to the app to do
some performance measurements.
The measurements are reported in term of packet per
second unit. The forwarding will start after the end
of insertion/deletion operations.
The support has single and multi core performance measurements.
Signed-off-by: Wisam Jaddo
---
app/test-flow-perf/main.c | 300 +
doc/guides/tools/flow-perf.rst | 6 +
2 files changed, 306 insertions(+)
diff --git a/app/test-flow-perf/main.c b/app/test-flow-perf/main.c
index 95435910de..2596d05dc2 100644
--- a/app/test-flow-perf/main.c
+++ b/app/test-flow-perf/main.c
@@ -60,14 +60,45 @@ static uint8_t flow_group;
static uint16_t flow_items;
static uint16_t flow_actions;
static uint8_t flow_attrs;
+
static volatile bool force_quit;
static volatile bool dump_iterations;
static volatile bool dump_socket_mem_flag;
static volatile bool delete_flag;
+static volatile bool enable_fwd;
+
static struct rte_mempool *mbuf_mp;
static uint32_t nb_lcores;
static uint32_t flows_count;
static uint32_t iterations_number;
+static uint32_t nb_lcores;
+
+#define MAX_PKT_BURST 32
+#define LCORE_MODE_PKT 1
+#define LCORE_MODE_STATS 2
+#define MAX_STREAMS 64
+#define MAX_LCORES 64
+
+struct stream {
+ int tx_port;
+ int tx_queue;
+ int rx_port;
+ int rx_queue;
+};
+
+struct lcore_info {
+ int mode;
+ int streams_nb;
+ struct stream streams[MAX_STREAMS];
+ /* stats */
+ uint64_t tx_pkts;
+ uint64_t tx_drops;
+ uint64_t rx_pkts;
+ struct rte_mbuf *pkts[MAX_PKT_BURST];
+} __attribute__((__aligned__(64))); /* let it be cacheline aligned */
+
+
+static struct lcore_info lcore_infos[MAX_LCORES];
static void usage(char *progname)
{
@@ -80,6 +111,8 @@ static void usage(char *progname)
printf(" --deletion-rate: Enable deletion rate"
" calculations\n");
printf(" --dump-socket-mem: to dump all socket memory\n");
+ printf(" --enable-fwd: to enable packets forwarding"
+ " after insertion\n");
printf("To set flow attributes:\n");
printf(" --ingress: set ingress attribute in flows\n");
@@ -130,6 +163,7 @@ args_parse(int argc, char **argv)
{ "dump-iterations",0, 0, 0 },
{ "deletion-rate", 0, 0, 0 },
{ "dump-socket-mem",0, 0, 0 },
+ { "enable-fwd", 0, 0, 0 },
/* Attributes */
{ "ingress",0, 0, 0 },
{ "egress", 0, 0, 0 },
@@ -315,6 +349,8 @@ args_parse(int argc, char **argv)
delete_flag = true;
if (!strcmp(lgopts[opt_idx].name, "dump-socket-mem"))
dump_socket_mem_flag = true;
+ if (!strcmp(lgopts[opt_idx].name, "enable-fwd"))
+ enable_fwd = true;
break;
default:
usage(argv[0]);
@@ -582,6 +618,265 @@ signal_handler(int signum)
}
}
+static inline uint16_t
+do_rx(struct lcore_info *li, uint16_t rx_port, uint16_t rx_queue)
+{
+ uint16_t cnt = 0;
+ cnt = rte_eth_rx_burst(rx_port, rx_queue, li->pkts, MAX_PKT_BURST);
+ li->rx_pkts += cnt;
+ return cnt;
+}
+
+static inline void
+do_tx(struct lcore_info *li, uint16_t cnt, uint16_t tx_port,
+ uint16_t tx_queue)
+{
+ uint16_t nr_tx = 0;
+ uint16_t i;
+
+ nr_tx = rte_eth_tx_burst(tx_port, tx_queue, li->pkts, cnt);
+ li->tx_pkts += nr_tx;
+ li->tx_drops += cnt - nr_tx;
+
+ for (i = nr_tx; i < cnt; i++)
+ rte_pktmbuf_free(li->pkts[i]);
+}
+
+/*
+ * Method to convert numbers into pretty numbers that easy
+ * to read. The design here is to add comma after each three
+ * digits and set all of this inside buffer.
+ *
+ * For example if n = 1799321, the output will be
+ * 1,799,321 after this method which is easier to read.
+ */
+static char *
+pretty_number(uint64_t n, char *buf)
+{
+ char p[6][4];
+ int i = 0;
+ int off = 0;
+
+ while (n > 1000) {
+ sprintf(p[i], "%03d", (int)(n % 1000));
+ n /= 1000;
+ i += 1;
+ }
+
+ sprintf(p[i++], "%d", (int)n);
+
+ while (i--)
+ off += sprintf(buf + off, "%s,", p[i]);
+ buf[strlen(buf) - 1] = '\0';
+
+ return buf;
+}
+
+static void
+packet_per_second_stats(void)
+{
+ struct lcore_info *old;
+ struct lcore_info *li, *oli;
+ int nr_lines = 0;
+ int i;
+
+ old = rte_zmalloc("old",
+ sizeof(struct lcore_info) * MAX_LCORES, 0);
+ if (old == NULL)
+ rte_exit(EXIT_FAILURE, "No Memory available!");
+
+ memcpy(old, lcore_infos,
+ sizeof(struct lcore_info) * MAX_LCORES)
[dpdk-dev] [PATCH v4 2/5] app/test-flow-perf: add insertion rate calculation
Add insertion rate calculation feature into flow
performance application.
The application now provide the ability to test
insertion rate of specific rte_flow rule, by
stressing it to the NIC, and calculate the
insertion rate.
The application offers some options in the command
line, to configure which rule to apply.
After that the application will start producing
rules with same pattern but increasing the outer IP
source address by 1 each time, thus it will give
different flow each time, and all other items will
have open masks.
The current design have single core insertion rate.
In the future we may have a multi core insertion
rate measurement support in the app.
Signed-off-by: Wisam Jaddo
---
app/test-flow-perf/Makefile | 3 +
app/test-flow-perf/actions_gen.c | 86 ++
app/test-flow-perf/actions_gen.h | 48
app/test-flow-perf/flow_gen.c| 176
app/test-flow-perf/flow_gen.h| 61
app/test-flow-perf/items_gen.c | 265 +
app/test-flow-perf/items_gen.h | 68 +
app/test-flow-perf/main.c| 416 +--
app/test-flow-perf/meson.build | 8 +
app/test-flow-perf/user_parameters.h | 15 +
doc/guides/tools/flow-perf.rst | 186 +++-
11 files changed, 1307 insertions(+), 25 deletions(-)
create mode 100644 app/test-flow-perf/actions_gen.c
create mode 100644 app/test-flow-perf/actions_gen.h
create mode 100644 app/test-flow-perf/flow_gen.c
create mode 100644 app/test-flow-perf/flow_gen.h
create mode 100644 app/test-flow-perf/items_gen.c
create mode 100644 app/test-flow-perf/items_gen.h
diff --git a/app/test-flow-perf/Makefile b/app/test-flow-perf/Makefile
index 45b1fb1464..968c7c60dd 100644
--- a/app/test-flow-perf/Makefile
+++ b/app/test-flow-perf/Makefile
@@ -19,6 +19,9 @@ CFLAGS += -Wno-unused-function
#
# all source are stored in SRCS-y
#
+SRCS-y += actions_gen.c
+SRCS-y += flow_gen.c
+SRCS-y += items_gen.c
SRCS-y += main.c
include $(RTE_SDK)/mk/rte.app.mk
diff --git a/app/test-flow-perf/actions_gen.c b/app/test-flow-perf/actions_gen.c
new file mode 100644
index 00..564ed820e4
--- /dev/null
+++ b/app/test-flow-perf/actions_gen.c
@@ -0,0 +1,86 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ *
+ * The file contains the implementations of actions generators.
+ * Each generator is responsible for preparing it's action instance
+ * and initializing it with needed data.
+ *
+ * Copyright 2020 Mellanox Technologies, Ltd
+ **/
+
+#include
+#include
+#include
+#include
+
+#include "actions_gen.h"
+#include "user_parameters.h"
+
+void
+gen_mark(void)
+{
+ mark_action.id = MARK_ID;
+}
+
+void
+gen_queue(uint16_t queue)
+{
+ queue_action.index = queue;
+}
+
+void
+gen_jump(uint16_t next_table)
+{
+ jump_action.group = next_table;
+}
+
+void
+gen_rss(uint16_t *queues, uint16_t queues_number)
+{
+ uint16_t queue;
+ struct action_rss_data *rss_data;
+ rss_data = rte_malloc("rss_data",
+ sizeof(struct action_rss_data), 0);
+
+ if (rss_data == NULL)
+ rte_exit(EXIT_FAILURE, "No Memory available!");
+
+ *rss_data = (struct action_rss_data){
+ .conf = (struct rte_flow_action_rss){
+ .func = RTE_ETH_HASH_FUNCTION_DEFAULT,
+ .level = 0,
+ .types = ETH_RSS_IP,
+ .key_len = 0,
+ .queue_num = queues_number,
+ .key = 0,
+ .queue = rss_data->queue,
+ },
+ .key = { 0 },
+ .queue = { 0 },
+ };
+
+ for (queue = 0; queue < queues_number; queue++)
+ rss_data->queue[queue] = queues[queue];
+
+ rss_action = &rss_data->conf;
+}
+
+void
+gen_set_meta(void)
+{
+ meta_action.data = RTE_BE32(META_DATA);
+ meta_action.mask = RTE_BE32(0x);
+}
+
+void
+gen_set_tag(void)
+{
+ tag_action.data = RTE_BE32(META_DATA);
+ tag_action.mask = RTE_BE32(0x);
+ tag_action.index = TAG_INDEX;
+}
+
+void
+gen_port_id(void)
+{
+ port_id.id = PORT_ID_DST;
+}
diff --git a/app/test-flow-perf/actions_gen.h b/app/test-flow-perf/actions_gen.h
new file mode 100644
index 00..556d48b871
--- /dev/null
+++ b/app/test-flow-perf/actions_gen.h
@@ -0,0 +1,48 @@
+/** SPDX-License-Identifier: BSD-3-Clause
+ *
+ * This file contains the functions definitions to
+ * generate each supported action.
+ *
+ * Copyright 2020 Mellanox Technologies, Ltd
+ **/
+
+#ifndef _ACTION_GEN_
+#define _ACTION_GEN_
+
+struct rte_flow_action_mark mark_action;
+struct rte_flow_action_queue queue_action;
+struct rte_flow_action_jump jump_action;
+struct rte_flow_action_rss *rss_action;
+struct rte_flow_action_set_meta meta_action;
+struct rte_flow_action_set_tag tag_action;
+struct rte_flow_action_port_id port_id;
+
+/* Storage for struct rte_flow_action_rss includi
[dpdk-dev] [PATCH v2] l3fwd-power: add Rx interrupt timeout
Currently, thread waiting on an interrupt does not have a timeout, so
it will not ever wake up until traffic arrives. This means that, when
time comes to exit the application, it will not quit unless there
happens to be traffic coming in and waking up the thread from sleep.
Fix it so that the interrupt thread sleeps for 10ms before waking up
and attempting to poll again. Additionally, remove the log message
to avoid spamming about entering interrupt mode.
Fixes: 613ce6691c0d ("examples/l3fwd-power: implement proper shutdown")
Cc: sta...@dpdk.org
Signed-off-by: Anatoly Burakov
---
examples/l3fwd-power/main.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/examples/l3fwd-power/main.c b/examples/l3fwd-power/main.c
index 293b3da4ae..21fb15e1a2 100644
--- a/examples/l3fwd-power/main.c
+++ b/examples/l3fwd-power/main.c
@@ -829,11 +829,7 @@ sleep_until_rx_interrupt(int num)
uint8_t queue_id;
void *data;
- RTE_LOG(INFO, L3FWD_POWER,
- "lcore %u sleeps until interrupt triggers\n",
- rte_lcore_id());
-
- n = rte_epoll_wait(RTE_EPOLL_PER_THREAD, event, num, -1);
+ n = rte_epoll_wait(RTE_EPOLL_PER_THREAD, event, num, 10);
for (i = 0; i < n; i++) {
data = event[i].epdata.data;
port_id = ((uintptr_t)data) >> CHAR_BIT;
@@ -1306,7 +1302,8 @@ main_loop(__rte_unused void *dummy)
/**
* start receiving packets immediately
*/
- goto start_rx;
+ if (likely(!is_done()))
+ goto start_rx;
}
}
stats[lcore_id].sleep_time += lcore_idle_hint;
--
2.17.1
[dpdk-dev] [PATCH v5] abi: change references to abi 20.0.1 to abi v21
Change references to abi 20.0.1 to use abi v21, see
https://doc.dpdk.org/guides/contributing/abi_policy.html#general-guidelines
"Major ABI versions are declared no more frequently than yearly.
Compatibility with the major ABI version is mandatory in subsequent
releases until a new major ABI version is declared."
Combined abi policy and versioning in maintainers, add map files to the
filter to more closely monitor future abi changes.
Signed-off-by: Ray Kinsella
---
MAINTAINERS| 10 +-
devtools/libabigail.abignore | 5 +
drivers/common/iavf/rte_common_iavf_version.map| 2 +-
drivers/common/mlx5/rte_common_mlx5_version.map| 2 +-
.../common/octeontx2/rte_common_octeontx2_version.map | 2 +-
drivers/net/ionic/rte_pmd_ionic_version.map| 2 +-
.../octeontx2_ep/rte_rawdev_octeontx2_ep_version.map | 2 +-
drivers/vdpa/mlx5/rte_pmd_mlx5_vdpa_version.map| 2 +-
lib/librte_meter/rte_meter_version.map | 2 +-
9 files changed, 17 insertions(+), 12 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index e05c80504..9756cb752 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -83,10 +83,6 @@ M: Marko Kovacevic
F: README
F: doc/
-ABI Policy
-M: Ray Kinsella
-F: doc/guides/contributing/abi_*.rst
-
Developers and Maintainers Tools
M: Thomas Monjalon
F: MAINTAINERS
@@ -140,10 +136,12 @@ M: Michael Santana
F: .travis.yml
F: .ci/
-ABI versioning
+ABI policy & versioning
+M: Ray Kinsella
M: Neil Horman
F: lib/librte_eal/include/rte_compat.h
F: lib/librte_eal/include/rte_function_versioning.h
+F: doc/guides/contributing/abi_*.rst
F: doc/guides/rel_notes/deprecation.rst
F: devtools/check-abi.sh
F: devtools/check-abi-version.sh
@@ -155,6 +153,8 @@ F: devtools/update_version_map_abi.py
F: devtools/validate-abi.sh
F: buildtools/check-symbols.sh
F: buildtools/map-list-symbol.sh
+F: drivers/*/*/*.map
+F: lib/*/*.map
Driver information
M: Neil Horman
diff --git a/devtools/libabigail.abignore b/devtools/libabigail.abignore
index 986a52771..b0147fde6 100644
--- a/devtools/libabigail.abignore
+++ b/devtools/libabigail.abignore
@@ -29,3 +29,8 @@
type_kind = enum
name = rte_eth_event_type
changed_enumerators = RTE_ETH_EVENT_MAX
+; Explicit ignore ABI 20.0.1
+[suppress_function]
+symbol_version = DPDK_20.0.1
+[suppress_variable]
+symbol_version = DPDK_20.0.1
diff --git a/drivers/common/iavf/rte_common_iavf_version.map
b/drivers/common/iavf/rte_common_iavf_version.map
index 2f11d67c0..92ceac108 100644
--- a/drivers/common/iavf/rte_common_iavf_version.map
+++ b/drivers/common/iavf/rte_common_iavf_version.map
@@ -1,4 +1,4 @@
-DPDK_20.0.1 {
+DPDK_21 {
global:
iavf_init_adminq;
diff --git a/drivers/common/mlx5/rte_common_mlx5_version.map
b/drivers/common/mlx5/rte_common_mlx5_version.map
index b58a37827..564a9a7fb 100644
--- a/drivers/common/mlx5/rte_common_mlx5_version.map
+++ b/drivers/common/mlx5/rte_common_mlx5_version.map
@@ -1,4 +1,4 @@
-DPDK_20.0.1 {
+DPDK_21 {
global:
mlx5_class_get;
diff --git a/drivers/common/octeontx2/rte_common_octeontx2_version.map
b/drivers/common/octeontx2/rte_common_octeontx2_version.map
index 8f2404bd9..01279c339 100644
--- a/drivers/common/octeontx2/rte_common_octeontx2_version.map
+++ b/drivers/common/octeontx2/rte_common_octeontx2_version.map
@@ -34,7 +34,7 @@ DPDK_20.0 {
local: *;
};
-DPDK_20.0.1 {
+DPDK_21 {
global:
otx2_eth_dev_is_sec_capable;
diff --git a/drivers/net/ionic/rte_pmd_ionic_version.map
b/drivers/net/ionic/rte_pmd_ionic_version.map
index bc8fd6d4d..acdaf587d 100644
--- a/drivers/net/ionic/rte_pmd_ionic_version.map
+++ b/drivers/net/ionic/rte_pmd_ionic_version.map
@@ -1,4 +1,4 @@
-DPDK_20.0.1 {
+DPDK_21 {
local: *;
};
diff --git a/drivers/raw/octeontx2_ep/rte_rawdev_octeontx2_ep_version.map
b/drivers/raw/octeontx2_ep/rte_rawdev_octeontx2_ep_version.map
index bc8fd6d4d..acdaf587d 100644
--- a/drivers/raw/octeontx2_ep/rte_rawdev_octeontx2_ep_version.map
+++ b/drivers/raw/octeontx2_ep/rte_rawdev_octeontx2_ep_version.map
@@ -1,4 +1,4 @@
-DPDK_20.0.1 {
+DPDK_21 {
local: *;
};
diff --git a/drivers/vdpa/mlx5/rte_pmd_mlx5_vdpa_version.map
b/drivers/vdpa/mlx5/rte_pmd_mlx5_vdpa_version.map
index 179f7f1ae..4a76d1d52 100644
--- a/drivers/vdpa/mlx5/rte_pmd_mlx5_vdpa_version.map
+++ b/drivers/vdpa/mlx5/rte_pmd_mlx5_vdpa_version.map
@@ -1,3 +1,3 @@
-DPDK_20.0.1 {
+DPDK_21 {
local: *;
};
diff --git a/lib/librte_meter/rte_meter_version.map
b/lib/librte_meter/rte_meter_version.map
index fc12cc0bf..2c7dadbca 100644
--- a/lib/librte_meter/rte_meter_version.map
+++ b/lib/librte_meter/rte_meter_version.map
@@ -13,7 +13,7 @@ DPDK_20.0 {
local: *;
};
-DPDK_20.0.1 {
+DPDK_21 {
global:
rte_meter_trtcm_rfc4115_color_aware_check;
--
2.23.0
[dpdk-dev] [PATCH v6 1/1] abi: change references to abi 20.0.1 to abi v21
Sending again, as I missed the cover letter last time. v6: * combined policy and versioning in the maintainers file. Ray Kinsella (1): abi: change references to abi 20.0.1 to abi v21 MAINTAINERS| 10 +- devtools/libabigail.abignore | 5 + drivers/common/iavf/rte_common_iavf_version.map| 2 +- drivers/common/mlx5/rte_common_mlx5_version.map| 2 +- .../common/octeontx2/rte_common_octeontx2_version.map | 2 +- drivers/net/ionic/rte_pmd_ionic_version.map| 2 +- .../octeontx2_ep/rte_rawdev_octeontx2_ep_version.map | 2 +- drivers/vdpa/mlx5/rte_pmd_mlx5_vdpa_version.map| 2 +- lib/librte_meter/rte_meter_version.map | 2 +- 9 files changed, 17 insertions(+), 12 deletions(-) -- 2.23.0
[dpdk-dev] [PATCH v6 1/1] abi: change references to abi 20.0.1 to abi v21
Change references to abi 20.0.1 to use abi v21, see
https://doc.dpdk.org/guides/contributing/abi_policy.html#general-guidelines
"Major ABI versions are declared no more frequently than yearly.
Compatibility with the major ABI version is mandatory in subsequent
releases until a new major ABI version is declared."
Combined abi policy and versioning in maintainers, add map files to the
filter to more closely monitor future abi changes.
Signed-off-by: Ray Kinsella
---
MAINTAINERS| 10 +-
devtools/libabigail.abignore | 5 +
drivers/common/iavf/rte_common_iavf_version.map| 2 +-
drivers/common/mlx5/rte_common_mlx5_version.map| 2 +-
.../common/octeontx2/rte_common_octeontx2_version.map | 2 +-
drivers/net/ionic/rte_pmd_ionic_version.map| 2 +-
.../octeontx2_ep/rte_rawdev_octeontx2_ep_version.map | 2 +-
drivers/vdpa/mlx5/rte_pmd_mlx5_vdpa_version.map| 2 +-
lib/librte_meter/rte_meter_version.map | 2 +-
9 files changed, 17 insertions(+), 12 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index e05c80504..9756cb752 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -83,10 +83,6 @@ M: Marko Kovacevic
F: README
F: doc/
-ABI Policy
-M: Ray Kinsella
-F: doc/guides/contributing/abi_*.rst
-
Developers and Maintainers Tools
M: Thomas Monjalon
F: MAINTAINERS
@@ -140,10 +136,12 @@ M: Michael Santana
F: .travis.yml
F: .ci/
-ABI versioning
+ABI policy & versioning
+M: Ray Kinsella
M: Neil Horman
F: lib/librte_eal/include/rte_compat.h
F: lib/librte_eal/include/rte_function_versioning.h
+F: doc/guides/contributing/abi_*.rst
F: doc/guides/rel_notes/deprecation.rst
F: devtools/check-abi.sh
F: devtools/check-abi-version.sh
@@ -155,6 +153,8 @@ F: devtools/update_version_map_abi.py
F: devtools/validate-abi.sh
F: buildtools/check-symbols.sh
F: buildtools/map-list-symbol.sh
+F: drivers/*/*/*.map
+F: lib/*/*.map
Driver information
M: Neil Horman
diff --git a/devtools/libabigail.abignore b/devtools/libabigail.abignore
index 986a52771..b0147fde6 100644
--- a/devtools/libabigail.abignore
+++ b/devtools/libabigail.abignore
@@ -29,3 +29,8 @@
type_kind = enum
name = rte_eth_event_type
changed_enumerators = RTE_ETH_EVENT_MAX
+; Explicit ignore ABI 20.0.1
+[suppress_function]
+symbol_version = DPDK_20.0.1
+[suppress_variable]
+symbol_version = DPDK_20.0.1
diff --git a/drivers/common/iavf/rte_common_iavf_version.map
b/drivers/common/iavf/rte_common_iavf_version.map
index 2f11d67c0..92ceac108 100644
--- a/drivers/common/iavf/rte_common_iavf_version.map
+++ b/drivers/common/iavf/rte_common_iavf_version.map
@@ -1,4 +1,4 @@
-DPDK_20.0.1 {
+DPDK_21 {
global:
iavf_init_adminq;
diff --git a/drivers/common/mlx5/rte_common_mlx5_version.map
b/drivers/common/mlx5/rte_common_mlx5_version.map
index b58a37827..564a9a7fb 100644
--- a/drivers/common/mlx5/rte_common_mlx5_version.map
+++ b/drivers/common/mlx5/rte_common_mlx5_version.map
@@ -1,4 +1,4 @@
-DPDK_20.0.1 {
+DPDK_21 {
global:
mlx5_class_get;
diff --git a/drivers/common/octeontx2/rte_common_octeontx2_version.map
b/drivers/common/octeontx2/rte_common_octeontx2_version.map
index 8f2404bd9..01279c339 100644
--- a/drivers/common/octeontx2/rte_common_octeontx2_version.map
+++ b/drivers/common/octeontx2/rte_common_octeontx2_version.map
@@ -34,7 +34,7 @@ DPDK_20.0 {
local: *;
};
-DPDK_20.0.1 {
+DPDK_21 {
global:
otx2_eth_dev_is_sec_capable;
diff --git a/drivers/net/ionic/rte_pmd_ionic_version.map
b/drivers/net/ionic/rte_pmd_ionic_version.map
index bc8fd6d4d..acdaf587d 100644
--- a/drivers/net/ionic/rte_pmd_ionic_version.map
+++ b/drivers/net/ionic/rte_pmd_ionic_version.map
@@ -1,4 +1,4 @@
-DPDK_20.0.1 {
+DPDK_21 {
local: *;
};
diff --git a/drivers/raw/octeontx2_ep/rte_rawdev_octeontx2_ep_version.map
b/drivers/raw/octeontx2_ep/rte_rawdev_octeontx2_ep_version.map
index bc8fd6d4d..acdaf587d 100644
--- a/drivers/raw/octeontx2_ep/rte_rawdev_octeontx2_ep_version.map
+++ b/drivers/raw/octeontx2_ep/rte_rawdev_octeontx2_ep_version.map
@@ -1,4 +1,4 @@
-DPDK_20.0.1 {
+DPDK_21 {
local: *;
};
diff --git a/drivers/vdpa/mlx5/rte_pmd_mlx5_vdpa_version.map
b/drivers/vdpa/mlx5/rte_pmd_mlx5_vdpa_version.map
index 179f7f1ae..4a76d1d52 100644
--- a/drivers/vdpa/mlx5/rte_pmd_mlx5_vdpa_version.map
+++ b/drivers/vdpa/mlx5/rte_pmd_mlx5_vdpa_version.map
@@ -1,3 +1,3 @@
-DPDK_20.0.1 {
+DPDK_21 {
local: *;
};
diff --git a/lib/librte_meter/rte_meter_version.map
b/lib/librte_meter/rte_meter_version.map
index fc12cc0bf..2c7dadbca 100644
--- a/lib/librte_meter/rte_meter_version.map
+++ b/lib/librte_meter/rte_meter_version.map
@@ -13,7 +13,7 @@ DPDK_20.0 {
local: *;
};
-DPDK_20.0.1 {
+DPDK_21 {
global:
rte_meter_trtcm_rfc4115_color_aware_check;
--
2.23.0
Re: [dpdk-dev] [PATCH 1/2] vfio: use ifdef's for ppc64 spapr code
On 30-Apr-20 12:29 AM, David Christensen wrote: Enclose ppc64 specific SPAPR VFIO support with ifdef's. Signed-off-by: David Christensen --- Why is this needed? -- Thanks, Anatoly
Re: [dpdk-dev] [PATCH 2/2] vfio: modify spapr iommu support to use static window sizing
On 30-Apr-20 12:29 AM, David Christensen wrote:
Current SPAPR IOMMU support code dynamically modifies the DMA window
size in response to every new memory allocation. This is potentially
dangerous because all existing mappings need to be unmapped/remapped in
order to resize the DMA window, leaving hardware holding IOVA addresses
that are not properly prepared for DMA. The new SPAPR code statically
assigns the DMA window size on first use, using the largest physical
memory address when IOVA=PA and the base_virtaddr + physical memory size
when IOVA=VA. As a result, memory will only be unmapped when
specifically requested.
Signed-off-by: David Christensen
---
Hi David,
I haven't yet looked at the code in detail (will do so later), but some
general comments and questions below.
+ /* only create DMA window once */
+ if (spapr_dma_win_len > 0)
+ return 0;
+
+ if (rte_eal_iova_mode() == RTE_IOVA_PA) {
+ /* Set the DMA window to cover the max physical address */
+ const char proc_iomem[] = "/proc/iomem";
+ const char str_sysram[] = "System RAM";
+ uint64_t start, end, max = 0;
+ char *line = NULL;
+ char *dash, *space;
+ size_t line_len;
+
+ /*
+* Read "System RAM" in /proc/iomem:
+* -1f : System RAM
+* 2000-201f : System RAM
+*/
+ FILE *fd = fopen(proc_iomem, "r");
+ if (fd == NULL) {
+ RTE_LOG(ERR, EAL, "Cannot open %s\n", proc_iomem);
+ return -1;
+ }
+ /* Scan /proc/iomem for the highest PA in the system */
+ while (getline(&line, &line_len, fd) != -1) {
+ if (strstr(line, str_sysram) == NULL)
+ continue;
+
+ space = strstr(line, " ");
+ dash = strstr(line, "-");
+
+ /* Validate the format of the memory string */
+ if (space == NULL || dash == NULL || space < dash) {
+ RTE_LOG(ERR, EAL, "Can't parse line \"%s\" in file
%s\n",
+ line, proc_iomem);
+ continue;
+ }
+
+ start = strtoull(line, NULL, 16);
+ end = strtoull(dash + 1, NULL, 16);
+ RTE_LOG(DEBUG, EAL, "Found system RAM from 0x%"
+ PRIx64 " to 0x%" PRIx64 "\n", start, end);
+ if (end > max)
+ max = end;
+ }
+ free(line);
+ fclose(fd);
+
+ if (max == 0) {
+ RTE_LOG(ERR, EAL, "Failed to find valid \"System RAM\" entry
"
+ "in file %s\n", proc_iomem);
+ return -1;
+ }
+
+ spapr_dma_win_len = rte_align64pow2(max + 1);
+ rte_mem_set_dma_mask(__builtin_ctzll(spapr_dma_win_len));
A quick check on my machines shows that when cat'ing /proc/iomem as
non-root, you get zeroes everywhere, which leads me to believe that you
have to be root to get anything useful out of /proc/iomem. Since one of
the major selling points of VFIO is the ability to run as non-root,
depending on iomem kind of defeats the purpose a bit.
+ return 0;
+
+ } else if (rte_eal_iova_mode() == RTE_IOVA_VA) {
+ /* Set the DMA window to base_virtaddr + system memory size */
+ const char proc_meminfo[] = "/proc/meminfo";
+ const char str_memtotal[] = "MemTotal:";
+ int memtotal_len = sizeof(str_memtotal) - 1;
+ char buffer[256];
+ uint64_t size = 0;
+
+ FILE *fd = fopen(proc_meminfo, "r");
+ if (fd == NULL) {
+ RTE_LOG(ERR, EAL, "Cannot open %s\n", proc_meminfo);
+ return -1;
+ }
+ while (fgets(buffer, sizeof(buffer), fd)) {
+ if (strncmp(buffer, str_memtotal, memtotal_len) == 0) {
+ size = rte_str_to_size(&buffer[memtotal_len]);
+ break;
+ }
+ }
+ fclose(fd);
+
+ if (size == 0) {
+ RTE_LOG(ERR, EAL, "Failed to find valid \"MemTotal\" entry
"
+ "in file %s\n", proc_meminfo);
+ return -1;
+ }
+
+ RTE_LOG(DEBUG, EAL, "MemTotal is 0x%" PRIx64 "\n", size);
+ /* if no base virtual address is configured use 4GB */
+ spapr_dma_win_len = rte_align64pow2(size +
+ (internal_con
Re: [dpdk-dev] [PATCH] net/mlx5: fix default rule do RSS regardless rxmode
From: Slava Ovsiienko
> > -Original Message-
> > From: Slava Ovsiienko
> > Sent: Thursday, April 30, 2020 11:52
> > To: Xiaoyu Min ; Matan Azrad
> > ; Shahaf Shuler
> > Cc: dev@dpdk.org; sta...@dpdk.org
> > Subject: RE: [PATCH] net/mlx5: fix default rule do RSS regardless
> > rxmode
> >
> > > -Original Message-
> > > From: Xiaoyu Min
> > > Sent: Wednesday, April 29, 2020 16:01
> > > To: Matan Azrad ; Shahaf Shuler
> > > ; Slava Ovsiienko
>
> > > Cc: dev@dpdk.org; sta...@dpdk.org
> > > Subject: [PATCH] net/mlx5: fix default rule do RSS regardless rxmode
> > >
> > > PMD create some default control rules with RSS action if it's not
> > > isolated mode.
> > >
> > > However whether default control rules need to do RSS or not should
> > > be controlled by device configuration, the mq_mode of rxmode
> > > configuration in specific.
> > >
> > > In another word, only when mq_mode is configured with
> > > ETH_MQ_RX_RSS_FLAG set, then RSS is needed for default rules.
> > >
> > > Fixes: c64ccc0eca2f ("mlx5: fix overwritten RSS configuration")
> > > Cc: sta...@dpdk.org
> > >
> > > Signed-off-by: Xiaoyu Min
> Acked-by: Viacheslav Ovsiienko
Acked-by: Matan Azrad
Re: [dpdk-dev] [PATCH v4 1/5] app/test-flow-perf: add flow performance skeleton
On Thu, 20-04-30, 10:33, Wisam Jaddo wrote: > Add flow performance application skeleton. > > Signed-off-by: Wisam Jaddo Acked-by: Xiaoyu Min
Re: [dpdk-dev] [PATCH v4 2/5] app/test-flow-perf: add insertion rate calculation
On Thu, 20-04-30, 10:33, Wisam Jaddo wrote: > Add insertion rate calculation feature into flow > performance application. > > The application now provide the ability to test > insertion rate of specific rte_flow rule, by > stressing it to the NIC, and calculate the > insertion rate. > > The application offers some options in the command > line, to configure which rule to apply. > > After that the application will start producing > rules with same pattern but increasing the outer IP > source address by 1 each time, thus it will give > different flow each time, and all other items will > have open masks. > > The current design have single core insertion rate. > In the future we may have a multi core insertion > rate measurement support in the app. > > Signed-off-by: Wisam Jaddo Acked-by: Xiaoyu Min
Re: [dpdk-dev] [PATCH v4 3/5] app/test-flow-perf: add deletion rate calculation
On Thu, 20-04-30, 10:33, Wisam Jaddo wrote: > Add the ability to test deletion rate for flow performance > application. > > This feature is disabled by default, and can be enabled by > add "--deletion-rate" in the application command line options. > > Signed-off-by: Wisam Jaddo Acked-by: Xiaoyu Min
Re: [dpdk-dev] [PATCH v4 4/5] app/test-flow-perf: add memory dump to app
On Thu, 20-04-30, 10:33, Wisam Jaddo wrote: > Introduce new feature to dump memory statistics of each socket > and a total for all before and after the creation. > > This will give two main advantage: > 1- Check the memory consumption for large number of flows > "insertion rate scenario alone" > > 2- Check that no memory leackage after doing insertion then > deletion. > > Signed-off-by: Suanming Mou > Signed-off-by: Wisam Jaddo Acked-by: Xiaoyu Min
[dpdk-dev] [PATCH] net/bnxt: fix a possible stack smashing
We see a stack smashing as a result of defensive code missing. Once the
nb_pkts is less than RTE_BNXT_DESCS_PER_LOOP, it will be modified to
zero after doing a floor align, and we can not exit the following
receiving packets loop. And the buffers will be overwrite, then the
stack frame was ruined.
Fix the problem by adding defensive code, once the nb_pkts is zero, just
directly return with no packets.
Signed-off-by: yuanlinsi01
Signed-off-by: rongdongsheng
---
drivers/net/bnxt/bnxt_rxtx_vec_sse.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/net/bnxt/bnxt_rxtx_vec_sse.c
b/drivers/net/bnxt/bnxt_rxtx_vec_sse.c
index d0e7910e7..c4adccdbc 100644
--- a/drivers/net/bnxt/bnxt_rxtx_vec_sse.c
+++ b/drivers/net/bnxt/bnxt_rxtx_vec_sse.c
@@ -233,8 +233,13 @@ bnxt_recv_pkts_vec(void *rx_queue, struct rte_mbuf
**rx_pkts,
/* Return no more than RTE_BNXT_MAX_RX_BURST per call. */
nb_pkts = RTE_MIN(nb_pkts, RTE_BNXT_MAX_RX_BURST);
- /* Make nb_pkts an integer multiple of RTE_BNXT_DESCS_PER_LOOP */
+ /*
+* Make nb_pkts an integer multiple of RTE_BNXT_DESCS_PER_LOOP
+* nb_pkts < RTE_BNXT_DESCS_PER_LOOP, just return no packet
+*/
nb_pkts = RTE_ALIGN_FLOOR(nb_pkts, RTE_BNXT_DESCS_PER_LOOP);
+ if (!nb_pkts)
+ return 0;
/* Handle RX burst request */
while (1) {
--
2.11.0
Re: [dpdk-dev] [PATCH v4 5/5] app/test-flow-perf: add packet forwarding support
On Thu, 20-04-30, 10:33, Wisam Jaddo wrote: > Introduce packet forwarding support to the app to do > some performance measurements. > > The measurements are reported in term of packet per > second unit. The forwarding will start after the end > of insertion/deletion operations. > > The support has single and multi core performance measurements. > > Signed-off-by: Wisam Jaddo Acked-by: Xiaoyu Min
Re: [dpdk-dev] [PATCH] app/testpmd: add cmdline option to set Rx mq mode
On Thu, 20-04-30, 09:16, Iremonger, Bernard wrote:
> Hi Xiaoyu,
Hey Bernard,
>
> > -Original Message-
> > From: Xiaoyu Min
> > Sent: Wednesday, April 29, 2020 2:04 PM
> > To: Lu, Wenzhuo ; Wu, Jingjing
> > ; Iremonger, Bernard
> > ; Mcnamara, John
> > ; Kovacevic, Marko
> >
> > Cc: dev@dpdk.org
> > Subject: [PATCH] app/testpmd: add cmdline option to set Rx mq mode
> >
> > One new cmdline option `--rx-mq-mode` is added in order to have the
> > possibility to check whether PMD handle the mq mode correctly or not.
> >
> > The reason is some NICs need to do different settings based on different RX
> > mq mode, i.e RSS or not.
> >
> > With this support in testpmd, the above scenario can be tested easily.
> >
> > Signed-off-by: Xiaoyu Min
> > ---
> > app/test-pmd/parameters.c | 12
> > app/test-pmd/testpmd.c| 17 ++---
> > app/test-pmd/testpmd.h| 3 +++
> > doc/guides/testpmd_app_ug/run_app.rst | 7 +++
> > 4 files changed, 36 insertions(+), 3 deletions(-)
> >
> > diff --git a/app/test-pmd/parameters.c b/app/test-pmd/parameters.c index
> > 30c1753c32..a9dd58e96b 100644
> > --- a/app/test-pmd/parameters.c
> > +++ b/app/test-pmd/parameters.c
> > @@ -212,6 +212,7 @@ usage(char* progname)
> > printf(" --noisy-lkup-num-writes=N: do N random reads and writes
> > per packet\n");
> > printf(" --no-iova-contig: mempool memory can be IOVA non
> > contiguous. "
> >"valid only with --mp-alloc=anon\n");
> > + printf(" --rx-mq-mode=0xX: hexadecimal bitmask of RX mq
> > mode\n");
> > }
> >
> > #ifdef RTE_LIBRTE_CMDLINE
> > @@ -670,6 +671,7 @@ launch_args_parse(int argc, char** argv)
> > { "noisy-lkup-num-reads", 1, 0, 0 },
> > { "noisy-lkup-num-reads-writes", 1, 0, 0 },
> > { "no-iova-contig", 0, 0, 0 },
> > + { "rx-mq-mode", 1, 0, 0 },
> > { 0, 0, 0, 0 },
> > };
> >
> > @@ -1363,6 +1365,16 @@ launch_args_parse(int argc, char** argv)
> > }
> > if (!strcmp(lgopts[opt_idx].name, "no-iova-contig"))
> > mempool_flags =
> > MEMPOOL_F_NO_IOVA_CONTIG;
> > +
> > + if (!strcmp(lgopts[opt_idx].name, "rx-mq-mode")) {
> > + char *end = NULL;
> > + n = strtoul(optarg, &end, 16);
> > + if (n >= 0)
> > + rx_mq_mode = (enum
> > rte_eth_rx_mq_mode)n;
> > + else
> > + rte_exit(EXIT_FAILURE,
> > +"rx-mq-mode must be >=
> > 0\n");
> > + }
> > break;
> > case 'h':
> > usage(argv[0]);
> > diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c index
> > 99bacddbfd..9536d6ee27 100644
> > --- a/app/test-pmd/testpmd.c
> > +++ b/app/test-pmd/testpmd.c
> > @@ -482,6 +482,11 @@ uint8_t bitrate_enabled; struct gro_status
> > gro_ports[RTE_MAX_ETHPORTS]; uint8_t gro_flush_cycles =
> > GRO_DEFAULT_FLUSH_CYCLES;
> >
> > +/*
> > + * RX mq mode value set in the commandline */ enum
> > rte_eth_rx_mq_mode
> > +rx_mq_mode = ETH_MQ_RX_VMDQ_DCB_RSS;
> > +
> > /* Forward function declarations */
> > static void setup_attached_port(portid_t pi); static void
> > map_port_queue_stats_mapping_registers(portid_t pi, @@ -3337,7 +3342,9
> > @@ init_port_config(void)
> >
> > if (port->dcb_flag == 0) {
> > if( port->dev_conf.rx_adv_conf.rss_conf.rss_hf != 0)
> > - port->dev_conf.rxmode.mq_mode =
> > ETH_MQ_RX_RSS;
> > + port->dev_conf.rxmode.mq_mode =
> > + (enum rte_eth_rx_mq_mode)
> > + (rx_mq_mode &
> > ETH_MQ_RX_RSS);
> > else
> > port->dev_conf.rxmode.mq_mode =
> > ETH_MQ_RX_NONE;
> > }
> > @@ -3438,7 +3445,9 @@ get_eth_dcb_conf(portid_t pid, struct
> > rte_eth_conf *eth_conf,
> > }
> >
> > /* set DCB mode of RX and TX of multiple queues */
> > - eth_conf->rxmode.mq_mode = ETH_MQ_RX_VMDQ_DCB;
> > + eth_conf->rxmode.mq_mode =
> > + (enum rte_eth_rx_mq_mode)
> > + (rx_mq_mode &
> > ETH_MQ_RX_VMDQ_DCB);
> > eth_conf->txmode.mq_mode = ETH_MQ_TX_VMDQ_DCB;
> > } else {
> > struct rte_eth_dcb_rx_conf *rx_conf = @@ -3458,7 +3467,9
> > @@ get_eth_dcb_conf(portid_t pid, struct rte_eth_conf *eth_conf,
> > tx_conf->dcb_tc[i] = i % num_tcs;
> > }
> >
> > - eth_conf->rxmode.mq_mode = ETH_MQ_RX_DCB_RSS;
> > + eth_conf->rxmode.mq_mode =
> > + (enum rte_eth_rx_mq_mode)
>
Re: [dpdk-dev] [PATCH] net/mlx5: fix actions validation on root table
Hi,
> -Original Message-
> From: Bing Zhao
> Sent: Wednesday, April 29, 2020 3:54 PM
> To: Slava Ovsiienko ; Raslan Darawsheh
>
> Cc: Ori Kam ; Matan Azrad ;
> dev@dpdk.org; sta...@dpdk.org
> Subject: [PATCH] net/mlx5: fix actions validation on root table
>
> The maximal supported header modifications number of a single modify
> context on the root table cannot be queried from firmware directly.
> It is a fixed value of 16 in the latest releases. In the validation
> stage, PMD driver should ensure that no more than 16 header modify
> actions exist in a single context.
> In some old firmware releases, the supported value is 8. PMD driver
> should try its best to create the flow. Firmware will return error
> and refuse to create the flow if the actions number exceeds the
> maximal value.
>
> Fixes: 72a944dba163 ("net/mlx5: fix header modify action validation")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Bing Zhao
> Acked-by: Viacheslav Ovsiienko
> ---
> drivers/net/mlx5/mlx5_flow.h| 12 +++-
> drivers/net/mlx5/mlx5_flow_dv.c | 17 +++--
> 2 files changed, 14 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/net/mlx5/mlx5_flow.h b/drivers/net/mlx5/mlx5_flow.h
> index 2a1f596..75b8288 100644
> --- a/drivers/net/mlx5/mlx5_flow.h
> +++ b/drivers/net/mlx5/mlx5_flow.h
> @@ -415,14 +415,16 @@ struct mlx5_flow_dv_tag_resource {
>
> /*
> * Number of modification commands.
> - * If extensive metadata registers are supported, the maximal actions
> amount is
> - * 16 and 8 otherwise on root table. The validation could also be done in the
> - * lower driver layer.
> - * On non-root table, there is no limitation, but 32 is enough right now.
> + * The maximal actions amount in FW is some constant, and it is 16 in the
> + * latest releases. In some old releases, it will be limited to 8.
> + * Since there is no interface to query the capacity, the maximal value
> should
> + * be used to allow PMD to create the flow. The validation will be done in
> the
> + * lower driver layer or FW. A failure will be returned if exceeds the
> maximal
> + * supported actions number on the root table.
> + * On non-root tables, there is no limitation, but 32 is enough right now.
> */
> #define MLX5_MAX_MODIFY_NUM 32
> #define MLX5_ROOT_TBL_MODIFY_NUM 16
> -#define MLX5_ROOT_TBL_MODIFY_NUM_NO_MREG 8
>
> /* Modify resource structure */
> struct mlx5_flow_dv_modify_hdr_resource {
> diff --git a/drivers/net/mlx5/mlx5_flow_dv.c
> b/drivers/net/mlx5/mlx5_flow_dv.c
> index 6263ecc..ba2febf 100644
> --- a/drivers/net/mlx5/mlx5_flow_dv.c
> +++ b/drivers/net/mlx5/mlx5_flow_dv.c
> @@ -3640,21 +3640,18 @@ struct field_modify_info modify_tcp[] = {
> * @return
> * Max number of modify header actions device can support.
> */
> -static unsigned int
> -flow_dv_modify_hdr_action_max(struct rte_eth_dev *dev, uint64_t flags)
> +static inline unsigned int
> +flow_dv_modify_hdr_action_max(struct rte_eth_dev *dev __rte_unused,
> + uint64_t flags)
> {
> /*
> - * There's no way to directly query the max cap. Although it has to be
> - * acquried by iterative trial, it is a safe assumption that more
> - * actions are supported by FW if extensive metadata register is
> - * supported. (Only in the root table)
> + * There's no way to directly query the max capacity from FW.
> + * The maximal value on root table should be assumed to be
> supported.
>*/
> if (!(flags & MLX5DV_DR_ACTION_FLAGS_ROOT_LEVEL))
> return MLX5_MAX_MODIFY_NUM;
> else
> - return mlx5_flow_ext_mreg_supported(dev) ?
> - MLX5_ROOT_TBL_MODIFY_NUM :
> -
> MLX5_ROOT_TBL_MODIFY_NUM_NO_MREG;
> + return MLX5_ROOT_TBL_MODIFY_NUM;
> }
>
> /**
> @@ -5347,7 +5344,7 @@ struct field_modify_info modify_tcp[] = {
> dev_conf->dv_xmeta_en != MLX5_XMETA_MODE_LEGACY &&
> mlx5_flow_ext_mreg_supported(dev))
> rw_act_num += MLX5_ACT_NUM_SET_TAG;
> - if ((uint32_t)rw_act_num >=
> + if ((uint32_t)rw_act_num >
> flow_dv_modify_hdr_action_max(dev, is_root)) {
> return rte_flow_error_set(error, ENOTSUP,
> RTE_FLOW_ERROR_TYPE_ACTION,
> --
> 1.8.3.1
Patch applied on next-net-mlx,
Kindest regards,
Raslan Darawsheh
Re: [dpdk-dev] [PATCH] test/ring: fix long compilation time
Honnappa Nagarahalli writes: > test_ring.c takes lot of time to compile with clang. It is > reproducable with compiler version 8.0 on Ubuntu 18.04. > Amount of testing is reduced, but attempt is made to keep > the same coverage. > > Reported-by: Aaron Conole > Reported-by: Thomas Monjalon > Signed-off-by: Honnappa Nagarahalli > Reviewed-by: Ruifeng Wang > --- Thanks, Honnappa! One thing to note, I don't see this with just clang - it occurs with gcc as well. I'm going to test this patch today.
Re: [dpdk-dev] [PATCH v11 6/9] net/virtio: add vectorized packed ring Rx path
On 4/30/2020 11:23 AM, Bruce Richardson wrote:
> On Thu, Apr 30, 2020 at 10:48:35AM +0100, Ferruh Yigit wrote:
>> On 4/28/2020 9:32 AM, Marvin Liu wrote:
>>> Optimize packed ring Rx path with SIMD instructions. Solution of
>>> optimization is pretty like vhost, is that split path into batch and
>>> single functions. Batch function is further optimized by AVX512
>>> instructions. Also pad desc extra structure to 16 bytes aligned, thus
>>> four elements will be saved in one batch.
>>>
>>> Signed-off-by: Marvin Liu
>>> Reviewed-by: Maxime Coquelin
>>
>> <...>
>>
>>> @@ -9,6 +9,20 @@ sources += files('virtio_ethdev.c',
>>> deps += ['kvargs', 'bus_pci']
>>>
>>> if arch_subdir == 'x86'
>>> + if '-mno-avx512f' not in machine_args
>>> + if cc.has_argument('-mavx512f') and
>>> cc.has_argument('-mavx512vl') and cc.has_argument('-mavx512bw')
>>> + cflags += ['-mavx512f', '-mavx512bw', '-mavx512vl']
>>> + cflags += ['-DCC_AVX512_SUPPORT']
>>> + if (toolchain == 'gcc' and
>>> cc.version().version_compare('>=8.3.0'))
>>> + cflags += '-DVHOST_GCC_UNROLL_PRAGMA'
>>> + elif (toolchain == 'clang' and
>>> cc.version().version_compare('>=3.7.0'))
>>> + cflags += '-DVHOST_CLANG_UNROLL_PRAGMA'
>>> + elif (toolchain == 'icc' and
>>> cc.version().version_compare('>=16.0.0'))
>>> + cflags += '-DVHOST_ICC_UNROLL_PRAGMA'
>>> + endif
>>> + sources += files('virtio_rxtx_packed_avx.c')
>>> + endif
>>> + endif
>>
>> This is giving following error in Travis build [1], it is seems this usage is
>> supported since meson 0.49 [2] and Travis has 0.47 [3], also DPDK supports
>> version 0.47.1+ [4].
>>
>> Can you please check for meson v0.47 version way of doing same thing?
>>
>>
> .contains() is probably what you want.
>
Thanks Bruce,
I will update in the next-net as following [1].
@Marvin can you please double check it on the next-net?
[1]
- if '-mno-avx512f' not in machine_args
+ if not machine_args.contains('-mno-avx512f')
[dpdk-dev] [PATCH v2] app/testpmd: add cmdline option to set Rx mq mode
One new cmdline option `--rx-mq-mode` is added in order to have the
possibility to check whether PMD handle the mq mode correctly or not.
The reason is some NICs need to do different settings based on different
RX mq mode, i.e RSS or not.
With this support in testpmd, the above scenario can be tested easily.
Signed-off-by: Xiaoyu Min
---
app/test-pmd/parameters.c | 12
app/test-pmd/testpmd.c | 17 ++---
app/test-pmd/testpmd.h | 3 +++
doc/guides/rel_notes/release_20_05.rst | 4
doc/guides/testpmd_app_ug/run_app.rst | 7 +++
5 files changed, 40 insertions(+), 3 deletions(-)
diff --git a/app/test-pmd/parameters.c b/app/test-pmd/parameters.c
index 30c1753c32..a9dd58e96b 100644
--- a/app/test-pmd/parameters.c
+++ b/app/test-pmd/parameters.c
@@ -212,6 +212,7 @@ usage(char* progname)
printf(" --noisy-lkup-num-writes=N: do N random reads and writes per
packet\n");
printf(" --no-iova-contig: mempool memory can be IOVA non contiguous. "
"valid only with --mp-alloc=anon\n");
+ printf(" --rx-mq-mode=0xX: hexadecimal bitmask of RX mq mode\n");
}
#ifdef RTE_LIBRTE_CMDLINE
@@ -670,6 +671,7 @@ launch_args_parse(int argc, char** argv)
{ "noisy-lkup-num-reads", 1, 0, 0 },
{ "noisy-lkup-num-reads-writes", 1, 0, 0 },
{ "no-iova-contig", 0, 0, 0 },
+ { "rx-mq-mode", 1, 0, 0 },
{ 0, 0, 0, 0 },
};
@@ -1363,6 +1365,16 @@ launch_args_parse(int argc, char** argv)
}
if (!strcmp(lgopts[opt_idx].name, "no-iova-contig"))
mempool_flags = MEMPOOL_F_NO_IOVA_CONTIG;
+
+ if (!strcmp(lgopts[opt_idx].name, "rx-mq-mode")) {
+ char *end = NULL;
+ n = strtoul(optarg, &end, 16);
+ if (n >= 0)
+ rx_mq_mode = (enum rte_eth_rx_mq_mode)n;
+ else
+ rte_exit(EXIT_FAILURE,
+"rx-mq-mode must be >= 0\n");
+ }
break;
case 'h':
usage(argv[0]);
diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
index 99bacddbfd..9536d6ee27 100644
--- a/app/test-pmd/testpmd.c
+++ b/app/test-pmd/testpmd.c
@@ -482,6 +482,11 @@ uint8_t bitrate_enabled;
struct gro_status gro_ports[RTE_MAX_ETHPORTS];
uint8_t gro_flush_cycles = GRO_DEFAULT_FLUSH_CYCLES;
+/*
+ * RX mq mode value set in the commandline
+ */
+enum rte_eth_rx_mq_mode rx_mq_mode = ETH_MQ_RX_VMDQ_DCB_RSS;
+
/* Forward function declarations */
static void setup_attached_port(portid_t pi);
static void map_port_queue_stats_mapping_registers(portid_t pi,
@@ -3337,7 +3342,9 @@ init_port_config(void)
if (port->dcb_flag == 0) {
if( port->dev_conf.rx_adv_conf.rss_conf.rss_hf != 0)
- port->dev_conf.rxmode.mq_mode = ETH_MQ_RX_RSS;
+ port->dev_conf.rxmode.mq_mode =
+ (enum rte_eth_rx_mq_mode)
+ (rx_mq_mode & ETH_MQ_RX_RSS);
else
port->dev_conf.rxmode.mq_mode = ETH_MQ_RX_NONE;
}
@@ -3438,7 +3445,9 @@ get_eth_dcb_conf(portid_t pid, struct rte_eth_conf
*eth_conf,
}
/* set DCB mode of RX and TX of multiple queues */
- eth_conf->rxmode.mq_mode = ETH_MQ_RX_VMDQ_DCB;
+ eth_conf->rxmode.mq_mode =
+ (enum rte_eth_rx_mq_mode)
+ (rx_mq_mode & ETH_MQ_RX_VMDQ_DCB);
eth_conf->txmode.mq_mode = ETH_MQ_TX_VMDQ_DCB;
} else {
struct rte_eth_dcb_rx_conf *rx_conf =
@@ -3458,7 +3467,9 @@ get_eth_dcb_conf(portid_t pid, struct rte_eth_conf
*eth_conf,
tx_conf->dcb_tc[i] = i % num_tcs;
}
- eth_conf->rxmode.mq_mode = ETH_MQ_RX_DCB_RSS;
+ eth_conf->rxmode.mq_mode =
+ (enum rte_eth_rx_mq_mode)
+ (rx_mq_mode & ETH_MQ_RX_DCB_RSS);
eth_conf->rx_adv_conf.rss_conf = rss_conf;
eth_conf->txmode.mq_mode = ETH_MQ_TX_DCB;
}
diff --git a/app/test-pmd/testpmd.h b/app/test-pmd/testpmd.h
index 7ff4c5dba3..32bb324c94 100644
--- a/app/test-pmd/testpmd.h
+++ b/app/test-pmd/testpmd.h
@@ -602,6 +602,9 @@ struct mplsoudp_decap_conf {
};
extern struct mplsoudp_decap_conf mplsoudp_decap_conf;
+/* RX mq mode parameter. */
+extern enum rte_eth_rx_mq_mode rx_mq_mode;
+
static inline unsigned
Re: [dpdk-dev] [PATCH v2] l3fwd-power: add Rx interrupt timeout
On 30/4/2020 11:49 AM, Anatoly Burakov wrote:
Currently, thread waiting on an interrupt does not have a timeout, so
it will not ever wake up until traffic arrives. This means that, when
time comes to exit the application, it will not quit unless there
happens to be traffic coming in and waking up the thread from sleep.
Fix it so that the interrupt thread sleeps for 10ms before waking up
and attempting to poll again. Additionally, remove the log message
to avoid spamming about entering interrupt mode.
Fixes: 613ce6691c0d ("examples/l3fwd-power: implement proper shutdown")
Cc: sta...@dpdk.org
Signed-off-by: Anatoly Burakov
---
Acked-by: David Hunt
Re: [dpdk-dev] [PATCH] net/bnxt: fix a possible stack smashing
+Lance Richardson
Thanks for the patch, could you please add the 'Fixes' tag as well ?
On Thu, Apr 30, 2020 at 5:35 PM yuanlinsi01 wrote:
>
> We see a stack smashing as a result of defensive code missing. Once the
> nb_pkts is less than RTE_BNXT_DESCS_PER_LOOP, it will be modified to
> zero after doing a floor align, and we can not exit the following
> receiving packets loop. And the buffers will be overwrite, then the
> stack frame was ruined.
>
> Fix the problem by adding defensive code, once the nb_pkts is zero, just
> directly return with no packets.
>
> Signed-off-by: yuanlinsi01
> Signed-off-by: rongdongsheng
> ---
> drivers/net/bnxt/bnxt_rxtx_vec_sse.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/bnxt/bnxt_rxtx_vec_sse.c
> b/drivers/net/bnxt/bnxt_rxtx_vec_sse.c
> index d0e7910e7..c4adccdbc 100644
> --- a/drivers/net/bnxt/bnxt_rxtx_vec_sse.c
> +++ b/drivers/net/bnxt/bnxt_rxtx_vec_sse.c
> @@ -233,8 +233,13 @@ bnxt_recv_pkts_vec(void *rx_queue, struct rte_mbuf
> **rx_pkts,
> /* Return no more than RTE_BNXT_MAX_RX_BURST per call. */
> nb_pkts = RTE_MIN(nb_pkts, RTE_BNXT_MAX_RX_BURST);
>
> - /* Make nb_pkts an integer multiple of RTE_BNXT_DESCS_PER_LOOP */
> + /*
> +* Make nb_pkts an integer multiple of RTE_BNXT_DESCS_PER_LOOP
> +* nb_pkts < RTE_BNXT_DESCS_PER_LOOP, just return no packet
> +*/
> nb_pkts = RTE_ALIGN_FLOOR(nb_pkts, RTE_BNXT_DESCS_PER_LOOP);
> + if (!nb_pkts)
> + return 0;
>
> /* Handle RX burst request */
> while (1) {
> --
> 2.11.0
>
Re: [dpdk-dev] [PATCH v2] app/testpmd: add cmdline option to set Rx mq mode
> -Original Message- > From: Xiaoyu Min > Sent: Thursday, April 30, 2020 2:08 PM > To: Lu, Wenzhuo ; Wu, Jingjing > ; Iremonger, Bernard > ; Mcnamara, John > ; Kovacevic, Marko > > Cc: dev@dpdk.org > Subject: [PATCH v2] app/testpmd: add cmdline option to set Rx mq mode > > One new cmdline option `--rx-mq-mode` is added in order to have the > possibility to check whether PMD handle the mq mode correctly or not. > > The reason is some NICs need to do different settings based on different RX > mq mode, i.e RSS or not. > > With this support in testpmd, the above scenario can be tested easily. > > Signed-off-by: Xiaoyu Min Acked-by: Bernard Iremonger
[dpdk-dev] 答复: [PATCH] net/bnxt: fix a possible stack smashing
Sure, I'll add it.
Thanks,
Yuan Linsi
发件人: Somnath Kotur
发送时间: 2020年4月30日 20:55
收件人: Yuan,Linsi; Lance Richardson
抄送: Ajit Kumar Khaparde; dev
主题: Re: [PATCH] net/bnxt: fix a possible stack smashing
+Lance Richardson
Thanks for the patch, could you please add the 'Fixes' tag as well ?
On Thu, Apr 30, 2020 at 5:35 PM yuanlinsi01 wrote:
>
> We see a stack smashing as a result of defensive code missing. Once the
> nb_pkts is less than RTE_BNXT_DESCS_PER_LOOP, it will be modified to
> zero after doing a floor align, and we can not exit the following
> receiving packets loop. And the buffers will be overwrite, then the
> stack frame was ruined.
>
> Fix the problem by adding defensive code, once the nb_pkts is zero, just
> directly return with no packets.
>
> Signed-off-by: yuanlinsi01
> Signed-off-by: rongdongsheng
> ---
> drivers/net/bnxt/bnxt_rxtx_vec_sse.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/bnxt/bnxt_rxtx_vec_sse.c
> b/drivers/net/bnxt/bnxt_rxtx_vec_sse.c
> index d0e7910e7..c4adccdbc 100644
> --- a/drivers/net/bnxt/bnxt_rxtx_vec_sse.c
> +++ b/drivers/net/bnxt/bnxt_rxtx_vec_sse.c
> @@ -233,8 +233,13 @@ bnxt_recv_pkts_vec(void *rx_queue, struct rte_mbuf
> **rx_pkts,
> /* Return no more than RTE_BNXT_MAX_RX_BURST per call. */
> nb_pkts = RTE_MIN(nb_pkts, RTE_BNXT_MAX_RX_BURST);
>
> - /* Make nb_pkts an integer multiple of RTE_BNXT_DESCS_PER_LOOP */
> + /*
> +* Make nb_pkts an integer multiple of RTE_BNXT_DESCS_PER_LOOP
> +* nb_pkts < RTE_BNXT_DESCS_PER_LOOP, just return no packet
> +*/
> nb_pkts = RTE_ALIGN_FLOOR(nb_pkts, RTE_BNXT_DESCS_PER_LOOP);
> + if (!nb_pkts)
> + return 0;
>
> /* Handle RX burst request */
> while (1) {
> --
> 2.11.0
>
[dpdk-dev] [PATCH] net/bnxt: fix a possible stack smashing
From: yuanlinsi01
We see a stack smashing as a result of defensive code missing. Once the
nb_pkts is less than RTE_BNXT_DESCS_PER_LOOP, it will be modified to
zero after doing a floor align, and we can not exit the following
receiving packets loop. And the buffers will be overwrite, then the
stack frame was ruined.
Fix the problem by adding defensive code, once the nb_pkts is zero, just
directly return with no packets.
Fixes: bc4a000f2 ("net/bnxt: implement SSE vector mode")
Cc: sta...@dpdk.org
Signed-off-by: yuanlinsi01
Signed-off-by: rongdongsheng
---
drivers/net/bnxt/bnxt_rxtx_vec_sse.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/net/bnxt/bnxt_rxtx_vec_sse.c
b/drivers/net/bnxt/bnxt_rxtx_vec_sse.c
index d0e7910e7..8f73add9b 100644
--- a/drivers/net/bnxt/bnxt_rxtx_vec_sse.c
+++ b/drivers/net/bnxt/bnxt_rxtx_vec_sse.c
@@ -233,8 +233,13 @@ bnxt_recv_pkts_vec(void *rx_queue, struct rte_mbuf
**rx_pkts,
/* Return no more than RTE_BNXT_MAX_RX_BURST per call. */
nb_pkts = RTE_MIN(nb_pkts, RTE_BNXT_MAX_RX_BURST);
- /* Make nb_pkts an integer multiple of RTE_BNXT_DESCS_PER_LOOP */
+ /*
+* Make nb_pkts an integer multiple of RTE_BNXT_DESCS_PER_LOOP.
+* nb_pkts < RTE_BNXT_DESCS_PER_LOOP, just return no packet
+*/
nb_pkts = RTE_ALIGN_FLOOR(nb_pkts, RTE_BNXT_DESCS_PER_LOOP);
+ if (!nb_pkts)
+ return 0;
/* Handle RX burst request */
while (1) {
--
2.11.0
Re: [dpdk-dev] [EXT] [PATCH v2] trace: fix build with gcc 10
Looks good to me.
Regards
Sunil Kumar Kori
>-Original Message-
>From: Phil Yang
>Sent: Tuesday, April 28, 2020 8:07 PM
>To: Sunil Kumar Kori ; dev@dpdk.org
>Cc: david.march...@redhat.com; Jerin Jacob Kollanukkaran
>; lijian.zh...@arm.com; ruifeng.w...@arm.com;
>n...@arm.com
>Subject: [EXT] [PATCH v2] trace: fix build with gcc 10
>
>External Email
>
>--
>Prevent from writing beyond the allocated memory.
>
>GCC 10 compiling output:
>eal_common_trace_utils.c: In function 'eal_trace_dir_args_save':
>eal_common_trace_utils.c:290:24: error: '__builtin___sprintf_chk' \
> may write a terminating nul past the end of the destination \
> [-Werror=format-overflow=]
> 290 | sprintf(dir_path, "%s/", optarg);
> |^
>
>Fixes: 8af866df8d8c ("trace: add trace directory configuration parameter")
>
>Signed-off-by: Phil Yang
>Reviewed-by: Lijian Zhang
>Tested-by: Lijian Zhang
Acked-by: Sunil Kumar Kori
>---
>v2:
>use asprintf instead of sprintf.
>
> lib/librte_eal/common/eal_common_trace_utils.c | 14 --
> 1 file changed, 8 insertions(+), 6 deletions(-)
>
>diff --git a/lib/librte_eal/common/eal_common_trace_utils.c
>b/lib/librte_eal/common/eal_common_trace_utils.c
>index fce8892..2ffb8af 100644
>--- a/lib/librte_eal/common/eal_common_trace_utils.c
>+++ b/lib/librte_eal/common/eal_common_trace_utils.c
>@@ -268,7 +268,7 @@ eal_trace_dir_args_save(char const *optarg) {
> struct trace *trace = trace_obj_get();
> uint32_t size = sizeof(trace->dir);
>- char *dir_path = NULL;
>+ char *dir_path;
> int rc;
>
> if (optarg == NULL) {
>@@ -276,18 +276,20 @@ eal_trace_dir_args_save(char const *optarg)
> return -EINVAL;
> }
>
>- if (strlen(optarg) >= size) {
>+ /* the specified trace directory name cannot
>+ * exceed PATH_MAX-1.
>+ */
>+ if (strlen(optarg) >= (size - 1)) {
> trace_err("input string is too big");
> return -ENAMETOOLONG;
> }
>
>- dir_path = (char *)calloc(1, size);
>- if (dir_path == NULL) {
>- trace_err("fail to allocate memory");
>+ rc = asprintf(&dir_path, "%s/", optarg);
>+ if (rc == -1) {
>+ trace_err("failed to copy directory: %s", strerror(errno));
> return -ENOMEM;
> }
>
>- sprintf(dir_path, "%s/", optarg);
> rc = trace_dir_update(dir_path);
>
> free(dir_path);
>--
>2.7.4
[dpdk-dev] DPDK Release Status Meeting 30/04/2020
Minutes 30 April 2020 - Agenda: * Release Dates * -rc1 status * Subtrees * OvS * Opens Participants: * Arm * Debian/Microsoft * Intel * Marvell * Mellanox * Red Hat Release Dates - * v20.05 dates: * -rc1 is released on Monday, 27 April * http://inbox.dpdk.org/dev/2138318.D4D8VRik6i@thomas/ * -rc2Friday 8 May 2020 * Release:Wednesday 20 May 2020 * v20.08 proposal dates, please comment: * Proposal/V1:Tuesday, 16 June 2020 * Integration/Merge/RC1: Tuesday, 14 July 2020 * Release:Friday, 7 August 2020 * Please send roadmap for the release -rc1 status --- * Intel completed majority of tests, no major issue found so far * Test report will be sent when ready * Marvel test report also doesn't show any major issue Subtrees * main * Mainly fixes at this moment * gcc10 fixes * still not all fixed, should be fixed for -rc2 * eal and ABI patches * __rte_internal * working on merging rte_graph and rte_telemetry for -rc2 * bitops is cleanup patch, would be good to have it in -rc1 at this stage it may not make this release * meson patches from Bruce to fix static linking May be postponed to next release * Rawdev for compress+crc multi function, short-term solution needs to be decided in mail list * next-net * Started to merge patches, no big patchset for -rc2 * ethdev patch not accepted because of ABI break, it will need to wait 20.11 * http://inbox.dpdk.org/dev/1923738.gORTcIGjah@thomas/ * ~60 patches in backlog for -rc2 * next-crypto * no update * next-eventdev * Only a few patches for -rc2 to be reviewed * next-virtio * Good progress this week, some patches already merged for -rc2 * mlx5 vdpa, packet ring vector path, zero copy optimizations, etc... * Only a few remaining, PR almost ready * next-net-intel * Some fixes for -rc2 has been merged and pulled to next-net * next-net-mrvl * ~10 patches to be reviewed for -rc2 OvS --- * Finished validating stable trees * OvS 2.11 & 2.12 validated with DPDK 18.11.7 * OvS 2.13 & master branch validated with DPDK 19.11.1 Opens - * Latest coverity scan showed 120 new defects, some of them from old code base, this may be related to the coverity backend changes * Need more support to resolve all new issues DPDK Release Status Meetings The DPDK Release Status Meeting is intended for DPDK Committers to discuss the status of the master tree and sub-trees, and for project managers to track progress or milestone dates. The meeting occurs on Thursdays at 8:30 UTC. If you wish to attend just send an email to "John McNamara " for the invite.
Re: [dpdk-dev] [PATCH v4 3/8] eal: introduce memory management wrappers
On 29-Apr-20 6:13 PM, Burakov, Anatoly wrote:
@@ -547,10 +531,10 @@ rte_eal_memdevice_init(void)
int
rte_mem_lock_page(const void *virt)
{
- unsigned long virtual = (unsigned long)virt;
- int page_size = getpagesize();
- unsigned long aligned = (virtual & ~(page_size - 1));
- return mlock((void *)aligned, page_size);
+ uintptr_t virtual = (uintptr_t)virt;
+ int page_size = rte_get_page_size();
+ uintptr_t aligned = (virtual & ~(page_size - 1));
Might as well fix to use macros? e.g.
size_t pagesz = rte_get_page_size();
return rte_mem_lock(RTE_PTR_ALIGN(virt, pagesz), pagesz);
(also, note that rte_get_page_size() returns size_t, not int)
Apologies, this should've been RTE_PTR_ALIGN_FLOOR(virt, pagesz)
--
Thanks,
Anatoly
Re: [dpdk-dev] [EXT] Re: [PATCH] eal/trace: fix coverity issues
Hello David,
Mentioned patch (http://patches.dpdk.org/patch/69467/ ) takes care of your
input to resolve GCC 10 build.
Now I think, this patch is good to go. Please take care of this.
Regards
Sunil Kumar Kori
>-Original Message-
>From: David Marchand
>Sent: Monday, April 27, 2020 7:22 PM
>To: Sunil Kumar Kori
>Cc: Jerin Jacob Kollanukkaran ; dev
>Subject: Re: [EXT] Re: [dpdk-dev] [PATCH] eal/trace: fix coverity issues
>
>On Mon, Apr 27, 2020 at 3:46 PM Sunil Kumar Kori
>wrote:
>>
>> >-Original Message-
>> >From: David Marchand
>> >Sent: Monday, April 27, 2020 5:56 PM
>> >To: Sunil Kumar Kori
>> >Cc: Jerin Jacob Kollanukkaran ; dev
>> >
>> >Subject: [EXT] Re: [dpdk-dev] [PATCH] eal/trace: fix coverity issues
>> >
>> >External Email
>> >
>> >-
>> >- On Mon, Apr 27, 2020 at 2:04 PM Sunil Kumar Kori
>> >
>> >wrote:
>> >>
>> >> Pointer was being dereferenced without NULL checking.
>> >>
>> >> Coverity issue: 357768
>> >>
>> >> Fixes: 8c8066ea6a7b ("trace: add trace mode configuration
>> >> parameter")
>> >>
>> >> Signed-off-by: Sunil Kumar Kori
>> >> ---
>> >> lib/librte_eal/common/eal_common_trace_utils.c | 3 ++-
>> >> 1 file changed, 2 insertions(+), 1 deletion(-)
>> >>
>> >> diff --git a/lib/librte_eal/common/eal_common_trace_utils.c
>> >> b/lib/librte_eal/common/eal_common_trace_utils.c
>> >> index fce8892c3..119e97119 100644
>> >> --- a/lib/librte_eal/common/eal_common_trace_utils.c
>> >> +++ b/lib/librte_eal/common/eal_common_trace_utils.c
>> >> @@ -227,15 +227,16 @@ int
>> >> eal_trace_mode_args_save(const char *optarg) {
>> >> struct trace *trace = trace_obj_get();
>> >> - size_t len = strlen(optarg);
>> >> unsigned long tmp;
>> >> char *pattern;
>> >> + size_t len;
>> >>
>> >> if (optarg == NULL) {
>> >> trace_err("no optarg is passed");
>> >> return -EINVAL;
>> >> }
>> >>
>> >> + len = strlen(optarg);
>> >> if (len == 0) {
>> >> trace_err("value is not provided with option");
>> >> return -EINVAL;
>> >
>> >I was looking at some gcc 10 complaints on string manipulation later
>> >in eal_trace_dir_args_save().
>> >
>> >https://urldefense.proofpoint.com/v2/url?u=https-
>> >3A__build.opensuse.org_package_live-5Fbuild-5Flog_home-3Admarchan-
>> >3Abranches-3Ahome-3Abluca-3Adpdk_dpdk_Fedora-5FRawhide_x86-
>>
>>5F64&d=DwIFaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=dXeXaAMkP5COgn1zxHM
>y
>>
>>aF1_d9IIuq6vHQO6NrIPjaE&m=NZ72Sr2OMEYZD7PIY59lshlAxZJJJepF5oxbHv0
>j
>> >5Zg&s=yOCA3PfhZojqJv0iVKlzeqM7tYGVv0jjrnVcajUx_qA&e=
>> >
>> >[ 126s] CC rte_malloc.o
>> >[ 127s] /home/abuild/rpmbuild/BUILD/dpdk-
>> >1587835122.b13ace300/lib/librte_eal/common/eal_common_trace_utils.c:
>> >In function 'eal_trace_dir_args_save':
>> >[ 127s] /home/abuild/rpmbuild/BUILD/dpdk-
>>
>>1587835122.b13ace300/lib/librte_eal/common/eal_common_trace_utils.c:2
>> >9
>> >0:24:
>> >error: 'sprintf' may write a terminating nul past the end of the
>> >destination [-Werror=format-overflow=]
>> >[ 127s] 290 | sprintf(dir_path, "%s/", optarg);
>> >[ 127s] |^
>> >[ 127s] /home/abuild/rpmbuild/BUILD/dpdk-
>>
>>1587835122.b13ace300/lib/librte_eal/common/eal_common_trace_utils.c:2
>> >9
>> >0:2:
>> >note: 'sprintf' output between 2 and 4097 bytes into a destination of
>> >size 4096
>> >[ 127s] 290 | sprintf(dir_path, "%s/", optarg);
>> >[ 127s] | ^~~~
>> >[ 127s] cc1: all warnings being treated as errors
>> >
>> >
>> >Could we use asprintf in all this code and avoid malloc + sprintf ?
>> >
>> As I understood from above warnings/errors, real problem is writing beyond
>destination i.e. dir_path.
>> If this is the case then it can be simply handled using snprintf(); with
>> correct
>"size" information.
>> Suggested code changes are correct. I am just trying to achieve this with
>lesser code changes.
>>
>> Also I think, fix for this should be a separate patch.
>> Suggestions please ?
>
>If the code was not combining this malloc + sprintf + wrong checks (caught by
>coverity), we would avoid both issues and it would be more consistent.
>No more suggestion from me.
>
>
>--
>David Marchand
Re: [dpdk-dev] [PATCH] net/bnxt: fix a possible stack smashing
On Thu, Apr 30, 2020 at 9:37 AM Yuan Linsi wrote:
>
> From: yuanlinsi01
>
> We see a stack smashing as a result of defensive code missing. Once the
> nb_pkts is less than RTE_BNXT_DESCS_PER_LOOP, it will be modified to
> zero after doing a floor align, and we can not exit the following
> receiving packets loop. And the buffers will be overwrite, then the
> stack frame was ruined.
>
> Fix the problem by adding defensive code, once the nb_pkts is zero, just
> directly return with no packets.
>
> Fixes: bc4a000f2 ("net/bnxt: implement SSE vector mode")
> Cc: sta...@dpdk.org
>
> Signed-off-by: yuanlinsi01
> Signed-off-by: rongdongsheng
> ---
> drivers/net/bnxt/bnxt_rxtx_vec_sse.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/bnxt/bnxt_rxtx_vec_sse.c
> b/drivers/net/bnxt/bnxt_rxtx_vec_sse.c
> index d0e7910e7..8f73add9b 100644
> --- a/drivers/net/bnxt/bnxt_rxtx_vec_sse.c
> +++ b/drivers/net/bnxt/bnxt_rxtx_vec_sse.c
> @@ -233,8 +233,13 @@ bnxt_recv_pkts_vec(void *rx_queue, struct rte_mbuf
> **rx_pkts,
> /* Return no more than RTE_BNXT_MAX_RX_BURST per call. */
> nb_pkts = RTE_MIN(nb_pkts, RTE_BNXT_MAX_RX_BURST);
>
> - /* Make nb_pkts an integer multiple of RTE_BNXT_DESCS_PER_LOOP */
> + /*
> +* Make nb_pkts an integer multiple of RTE_BNXT_DESCS_PER_LOOP.
> +* nb_pkts < RTE_BNXT_DESCS_PER_LOOP, just return no packet
> +*/
> nb_pkts = RTE_ALIGN_FLOOR(nb_pkts, RTE_BNXT_DESCS_PER_LOOP);
> + if (!nb_pkts)
> + return 0;
>
> /* Handle RX burst request */
> while (1) {
> --
> 2.11.0
>
Thanks for the fix!
Acked-by: Lance Richardson
[dpdk-dev] [PATCH v2] eal/ppc: fix redefine bool type
The AltiVec header file breaks boolean type. [1] [2]
Currently the workaround was located only in mlx5 device.
Adding the trace module caused this issue to appear again, due to
order of includes, it keeps overriding the local fix.
This patch solves this issue by resetting the bool type, immediately
after it is being changed.
[1] https://mails.dpdk.org/archives/dev/2018-August/110281.html
[2]
In file included from
dpdk/ppc_64-power8-linux-gcc/include/rte_mempool_trace_fp.h:18:0,
from
dpdk/ppc_64-power8-linux-gcc/include/rte_mempool.h:54,
from
dpdk/drivers/common/mlx5/mlx5_common_mr.c:7:
dpdk/ppc_64-power8-linux-gcc/include/rte_trace_point.h: In
function '__rte_trace_point_fp_is_enabled':
dpdk/ppc_64-power8-linux-gcc/include/rte_trace_point.h:226:2:
error: incompatible types when returning type 'int' but '__vector __bool
int' was expected
return false;
^
In file included from
dpdk/ppc_64-power8-linux-gcc/include/rte_trace_point.h:281:0,
from
dpdk/ppc_64-power8-linux-gcc/include/rte_mempool_trace_fp.h:18,
from
dpdk/ppc_64-power8-linux-gcc/include/rte_mempool.h:54,
from
dpdk/drivers/common/mlx5/mlx5_common_mr.c:7:
dpdk/ppc_64-power8-linux-gcc/include/rte_mempool_trace_fp.h:
In function 'rte_mempool_trace_ops_dequeue_bulk':
dpdk/ppc_64-power8-linux-gcc/include/rte_trace_point_provider.h:104:6:
error: wrong type argument to unary exclamation mark
if (!__rte_trace_point_fp_is_enabled()) \
^
dpdk/ppc_64-power8-linux-gcc/include/rte_trace_point.h:49:2:
note: in expansion of macro '__rte_trace_point_emit_header_fp'
__rte_trace_point_emit_header_##_mode(&__##_tp); \
^
dpdk/ppc_64-power8-linux-gcc/include/rte_trace_point.h:99:2:
note: in expansion of macro '__RTE_TRACE_POINT'
__RTE_TRACE_POINT(fp, tp, args, __VA_ARGS__)
^
dpdk/ppc_64-power8-linux-gcc/include/rte_mempool_trace_fp.h:20:1:
note: in expansion of macro 'RTE_TRACE_POINT_FP'
RTE_TRACE_POINT_FP(
^
dpdk/ppc_64-power8-linux-gcc/include/rte_mempool_trace_fp.h:
In function 'rte_mempool_trace_ops_dequeue_contig_blocks':
dpdk/ppc_64-power8-linux-gcc/include/rte_trace_point_provider.h:104:6:
error: wrong type argument to unary exclamation mark
if (!__rte_trace_point_fp_is_enabled()) \
^
dpdk/ppc_64-power8-linux-gcc/include/rte_trace_point.h:49:2:
note: in expansion of macro '__rte_trace_point_emit_header_fp'
__rte_trace_point_emit_header_##_mode(&__##_tp); \
^
dpdk/ppc_64-power8-linux-gcc/include/rte_trace_point.h:99:2:
note: in expansion of macro '__RTE_TRACE_POINT'
__RTE_TRACE_POINT(fp, tp, args, __VA_ARGS__)
^
dpdk/ppc_64-power8-linux-gcc/include/rte_mempool_trace_fp.h:29:1:
note: in expansion of macro 'RTE_TRACE_POINT_FP'
RTE_TRACE_POINT_FP(
^
dpdk/ppc_64-power8-linux-gcc/include/rte_mempool_trace_fp.h:
In function 'rte_mempool_trace_ops_enqueue_bulk':
dpdk/ppc_64-power8-linux-gcc/include/rte_trace_point_provider.h:104:6:
error: wrong type argument to unary exclamation mark
if (!__rte_trace_point_fp_is_enabled()) \
Fixes: 725f5dd0bfb5 ("net/mlx5: fix build on PPC64")
Signed-off-by: Ori Kam
Signed-off-by: David Christensen
---
v2:
* Replace alitvec include in all files.
* Address ML comments.
---
drivers/common/mlx5/mlx5_common.h | 10 --
drivers/net/i40e/i40e_rxtx_vec_altivec.c| 2 +-
drivers/net/mlx5/mlx5_rxtx_vec_altivec.h| 2 +-
drivers/net/mlx5/mlx5_utils.h | 10 --
drivers/net/virtio/virtio_rxtx_simple_altivec.c | 2 +-
lib/librte_eal/ppc/include/meson.build | 1 +
lib/librte_eal/ppc/include/rte_altivec.h| 22 ++
lib/librte_eal/ppc/include/rte_memcpy.h | 3 +--
lib/librte_eal/ppc/include/rte_vect.h | 2 +-
9 files changed, 28 insertions(+), 26 deletions(-)
create mode 100644 lib/librte_eal/ppc/include/rte_altivec.h
diff --git a/drivers/common/mlx5/mlx5_common.h
b/drivers/common/mlx5/mlx5_common.h
index 16de1b3..c2d688a 100644
--- a/drivers/common/mlx5/mlx5_common.h
+++ b/drivers/common/mlx5/mlx5_common.h
@@ -17,16 +17,6 @@
#include "mlx5_prm.h"
-/*
- * Compilation workaround for PPC64 when AltiVec is fully enabled, e.g.
std=c11.
- * Otherwise there would be a type conflict between stdbool and altivec.
- */
-#if defined(__PPC64__) && !defined(__APPLE_ALTIVEC__)
-#undef bool
-/* redefine as in stdbool.h */
-#define bool _Bool
-#endif
-
/* Bit-field manipulation. */
#define BITFIELD_DECLARE(bf, type, size) \
type bf[(((size_t)(size) / (sizeof(type) * CHAR_BIT)) + \
diff --git a/drivers/net/i40e/i40e_rxtx_vec_altivec.c
b/drivers/net/i40e/i40e_rxtx_vec_altivec.c
index 5fa92bf..72bd410 100644
--- a/drivers/net/i40e/i40e_rxtx_vec_altivec.c
+++ b/drivers/net/i40e/i40e_rxtx_vec_altivec.c
@@ -13,7 +13,7 @@
#include "i40e_rxtx.h"
#include "i40e_rxtx_vec_common.h"
-#include
+#include "rte_altivec.h"
#pragma GCC diagnostic ignored "-Wcast-qual"
diff --git a/drivers/net/mlx5/mlx5_rx
Re: [dpdk-dev] [PATCH] test/ring: code rework to reduce compilation time
Hi Honnappa,
> Hi Konstantin,
> I like the way the tests are organized and it looks good.
>
> I am just wondering about the way it is being tested here. The intent to
> write the test cases the way they are currently is to mimic how the
> APIs would be used mostly. IMO, the APIs would be used with a constant value
> for element size so that the compiler will throw away the
> unwanted code (in the functions where the actual copy is being done).
>
> With your method here, it looks to me like all the branches in the copy
> functions are kept and the branch decisions are done at run time.
> Is my understanding correct?
You mean branching on esize[] values?
Actually from what I've seen that happens for both cases:
before and after the patch (gcc 7.3 -O3).
Main intention in my changes was to avoid using
test_ring_enqueue/test_ring_dequeue,
as it seems too many branches here and it takes compiler a lot of effort to
resolve all
of them at compile time.
So I replaced it with array of function pointers (test_enqdeq_impl[]) and
iterating over it.
That way compiler knows straightway which function to use.
> Can you please check this? https://patches.dpdk.org/patch/69567/
As I can see your approach reduces number of test-cases by factor of 5:
now each of test_ring_burst_bulk_tests[1-4] is executed only with just
one esize value, correct?
In term of compilation speed - it helps.
On my box with (gcc 7.3 -O3) compiling test_ring.c takes:
orig code: ~100s
with 69567 (your patch): < 20s
with 69559 (my patch):< 10s
Konstantin
>
> > -Original Message-
> > From: Konstantin Ananyev
> > Sent: Wednesday, April 29, 2020 12:57 PM
> > To: dev@dpdk.org
> > Cc: acon...@redhat.com; Honnappa Nagarahalli
> > ; Konstantin Ananyev
> >
> > Subject: [PATCH] test/ring: code rework to reduce compilation time
> >
> > Rework test code to reduce code complexity for the compiler and bring down
> > compilation time and memory consumption.
> >
> > Signed-off-by: Konstantin Ananyev
> > ---
> > app/test/test_ring.c | 373 +--
> > 1 file changed, 249 insertions(+), 124 deletions(-)
> >
> > diff --git a/app/test/test_ring.c b/app/test/test_ring.c index
> > e21557cd9..0ae97d341 100644
> > --- a/app/test/test_ring.c
> > +++ b/app/test/test_ring.c
> > @@ -58,6 +58,181 @@
> >
> > static const int esize[] = {-1, 4, 8, 16, 20};
> >
> > +static const struct {
> > + const char *desc;
> > + uint32_t api_type;
> > + uint32_t create_flags;
> > + struct {
> > + unsigned int (*flegacy)(struct rte_ring *r,
> > + void * const *obj_table, unsigned int n,
> > + unsigned int *free_space);
> > + unsigned int (*felem)(struct rte_ring *r, const void *obj_table,
> > + unsigned int esize, unsigned int n,
> > + unsigned int *free_space);
> > + } enq;
> > + struct {
> > + unsigned int (*flegacy)(struct rte_ring *r,
> > + void **obj_table, unsigned int n,
> > + unsigned int *available);
> > + unsigned int (*felem)(struct rte_ring *r, void *obj_table,
> > + unsigned int esize, unsigned int n,
> > + unsigned int *available);
> > + } deq;
> > +} test_enqdeq_impl[] = {
> > + {
> > + .desc = "MP/MC sync mode",
> Details about the tests are already printed by the function
> 'test_ring_print_test_string'. This string should be 'Test standard ring'.
>
> > + .api_type = TEST_RING_ELEM_BULK |
> > TEST_RING_THREAD_DEF,
> > + .create_flags = 0,
> > + .enq = {
> > + .flegacy = rte_ring_enqueue_bulk,
> > + .felem = rte_ring_enqueue_bulk_elem,
> > + },
> > + .deq = {
> > + .flegacy = rte_ring_dequeue_bulk,
> > + .felem = rte_ring_dequeue_bulk_elem,
> > + },
> > + },
> > + {
> > + .desc = "SP/SC sync mode",
> > + .api_type = TEST_RING_ELEM_BULK |
> > TEST_RING_THREAD_SPSC,
> > + .create_flags = RING_F_SP_ENQ | RING_F_SC_DEQ,
> > + .enq = {
> > + .flegacy = rte_ring_sp_enqueue_bulk,
> > + .felem = rte_ring_sp_enqueue_bulk_elem,
> > + },
> > + .deq = {
> > + .flegacy = rte_ring_sc_dequeue_bulk,
> > + .felem = rte_ring_sc_dequeue_bulk_elem,
> > + },
> > + },
> > + {
> > + .desc = "MP/MC sync mode",
> > + .api_type = TEST_RING_ELEM_BULK |
> > TEST_RING_THREAD_MPMC,
> > + .create_flags = 0,
> > + .enq = {
> > + .flegacy = rte_ring_mp_enqueue_bulk,
> > + .felem = rte_ring_mp_enqueue_bulk_elem,
> > + },
> > + .deq = {
> > + .flegacy = rte_ring_mc_dequeue_bulk,
> > + .felem
Re: [dpdk-dev] [RFC] ring: count and empty optimizations
>
> > From: Honnappa Nagarahalli [mailto:honnappa.nagaraha...@arm.com]
> > Sent: Thursday, April 30, 2020 3:12 AM
> >
> >
> >
> > >
> > > Hi Morten,
> > >
> > > On Tue, Apr 28, 2020 at 03:53:15PM +0200, Morten Brørup wrote:
> > > > Olivier (maintainer of the Ring),
> > >
> > > I'm not anymore, CC'ing Konstantin and Honnappa.
> > >
> > > > I would like to suggest a couple of minor optimizations to the ring
> > library.
> > > >
> > > >
> > > > 1. Testing if the ring is empty is as simple as comparing the
> > producer and
> > > consumer pointers:
> > > >
> > > > static inline int
> > > > rte_ring_empty(const struct rte_ring *r) {
> > > > - return rte_ring_count(r) == 0;
> > > > + uint32_t prod_tail = r->prod.tail;
> > > > + uint32_t cons_tail = r->cons.tail;
> > > > + return cons_tail == prod_tail;
> > > > }
> > > >
> > > > In theory, this optimization reduces the number of potential cache
> > misses
> > > from 3 to 2 by not having to read r->mask in rte_ring_count().
> > >
> > > This one looks correct to me.
> > >
> > >
> > > > 2. It is not possible to enqueue more elements than the capacity of
> > a ring,
> > > so the count function does not need to test if the capacity is
> > exceeded:
> > > >
> > > > static inline unsigned
> > > > rte_ring_count(const struct rte_ring *r) {
> > > > uint32_t prod_tail = r->prod.tail;
> > > > uint32_t cons_tail = r->cons.tail;
> > > > uint32_t count = (prod_tail - cons_tail) & r->mask;
> > > > - return (count > r->capacity) ? r->capacity : count;
> > > > + return count;
> > > > }
> > > >
> > > > I cannot even come up with a race condition in this function where
> > the
> > > count would exceed the capacity. Maybe I missed something?
> > >
> > > Since there is no memory barrier, the order in which prod_tail and
> > cons_tail
> > > are fetched is not guaranteed. Or the thread could be interrupted by
> > the
> > > kernel in between.
> > The '__rte_ring_move_prod_head' function ensures that the distance
> > between prod.head and cons.tail is always within the capacity
> > irrespective of whether the consumers/producers are sleeping.
>
> Yes, this is exactly what I was thinking.
>
> The tails are the pointers after any updates, which is shown very nicely in
> the documentation.
> And certainly prod.tail will not move further ahead than prod.head.
>
> So it makes sense using the tails outside the functions that move the
> pointers.
>
> Olivier found the race I couldn't find:
> 1. The thread calls rte_ring_count(), and since there is no memory barrier it
> reads cons.tail, and has not yet read prod.tail.
> 2. Other threads use the ring simultaneously. A consumer thread moves
> cons.tail ahead and a producer thread then moves prod.tail ahead.
> Note: Without first moving cons.tail ahead, prod.tail cannot move too far
> ahead.
> 3. The thread proceeds to read prod.tail. Now the count is completely
> incorrect, and may even exceed the capacity.
>
> Olivier pointed out that this could happen if the rte_ring_count thread is
> interrupted by the kernel, and I agree. However, intuitively I don't
> think that it can happen in a non-EAL thread, because the consumer thread
> needs to finish moving cons.tail before the producer thread can
> move prod.tail too far ahead. And by then the rte_ring_count thread has had
> plenty of time to read prod.tail. But it could happen in theory.
>
> > > This function may probably return invalid results in MC/MP cases.
> > > We just ensure that the result is between 0 and r->capacity.
>
> So should we update the documentation to say that it might return an
> incorrect count (if there is a race), or should we fix the function to
> always provide a correct value?
As long as you invoke rte_ring_count() while there are other
active producers/consumers for that ring -
it's return value can always be outdated, and not reflect current ring state.
So I think just updating the doc is enough.
>
> Furthermore, the same race condition probably affects rte_ring_empty()
> similarly, even in my improved version.
>
> And do these functions need to support non-EAL threads? I don't think so.
> What do you think?
Not sure why you differ EAL and non EAL threads here.
The only difference between them from scheduler point of view -
EAL threads have cpu affinity set by rte_eal_init().
But nothing prevents user from setting/updating cpu affinity
for any thread in his process in a way he likes.
