* [dpdk-dev] [PATCH v1 01/15] examples/l2fwd: add new header to move common code
2018-06-14 11:48 ` [dpdk-dev] [PATCH v1 00/15] preparing l2fwd for eventmode additions Anoob Joseph
@ 2018-06-14 11:48 ` Anoob Joseph
2018-06-14 11:48 ` [dpdk-dev] [PATCH v1 02/15] examples/l2fwd: move macro definitions to common header Anoob Joseph
` (15 subsequent siblings)
16 siblings, 0 replies; 83+ messages in thread
From: Anoob Joseph @ 2018-06-14 11:48 UTC (permalink / raw)
To: Bruce Richardson, Pablo de Lara
Cc: Anoob Joseph, Jerin Jacob, Narayana Prasad, dev
Signed-off-by: Anoob Joseph <anoob.joseph@caviumnetworks.com>
---
v1:
* No change
examples/l2fwd/l2fwd_common.h | 6 ++++++
1 file changed, 6 insertions(+)
create mode 100644 examples/l2fwd/l2fwd_common.h
diff --git a/examples/l2fwd/l2fwd_common.h b/examples/l2fwd/l2fwd_common.h
new file mode 100644
index 0000000..15059f4
--- /dev/null
+++ b/examples/l2fwd/l2fwd_common.h
@@ -0,0 +1,6 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2018 Cavium, Inc
+ */
+#ifndef _L2FWD_COMMON_H_
+#define _L2FWD_COMMON_H_
+#endif /* _L2FWD_COMMON_H_ */
--
2.7.4
^ permalink raw reply [flat|nested] 83+ messages in thread
* [dpdk-dev] [PATCH v1 02/15] examples/l2fwd: move macro definitions to common header
2018-06-14 11:48 ` [dpdk-dev] [PATCH v1 00/15] preparing l2fwd for eventmode additions Anoob Joseph
2018-06-14 11:48 ` [dpdk-dev] [PATCH v1 01/15] examples/l2fwd: add new header to move common code Anoob Joseph
@ 2018-06-14 11:48 ` Anoob Joseph
2018-06-14 11:48 ` [dpdk-dev] [PATCH v1 03/15] examples/l2fwd: move structure " Anoob Joseph
` (14 subsequent siblings)
16 siblings, 0 replies; 83+ messages in thread
From: Anoob Joseph @ 2018-06-14 11:48 UTC (permalink / raw)
To: Bruce Richardson, Pablo de Lara
Cc: Anoob Joseph, Jerin Jacob, Narayana Prasad, dev
Signed-off-by: Anoob Joseph <anoob.joseph@caviumnetworks.com>
---
v1:
* Retaining Intel license with copied code
examples/l2fwd/l2fwd_common.h | 19 +++++++++++++++++++
examples/l2fwd/main.c | 16 ++--------------
2 files changed, 21 insertions(+), 14 deletions(-)
diff --git a/examples/l2fwd/l2fwd_common.h b/examples/l2fwd/l2fwd_common.h
index 15059f4..fceb0c3 100644
--- a/examples/l2fwd/l2fwd_common.h
+++ b/examples/l2fwd/l2fwd_common.h
@@ -1,6 +1,25 @@
/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2010-2016 Intel Corporation
* Copyright(c) 2018 Cavium, Inc
*/
#ifndef _L2FWD_COMMON_H_
#define _L2FWD_COMMON_H_
+
+#define RTE_LOGTYPE_L2FWD RTE_LOGTYPE_USER1
+
+#define MAX_PKT_BURST 32
+#define BURST_TX_DRAIN_US 100 /* TX drain every ~100us */
+#define MEMPOOL_CACHE_SIZE 256
+
+/*
+ * Configurable number of RX/TX ring descriptors
+ */
+#define RTE_TEST_RX_DESC_DEFAULT 1024
+#define RTE_TEST_TX_DESC_DEFAULT 1024
+
+#define MAX_RX_QUEUE_PER_LCORE 16
+#define MAX_TX_QUEUE_PER_PORT 16
+
+#define MAX_TIMER_PERIOD 86400 /* 1 day max */
+
#endif /* _L2FWD_COMMON_H_ */
diff --git a/examples/l2fwd/main.c b/examples/l2fwd/main.c
index 6908435..9f873c7 100644
--- a/examples/l2fwd/main.c
+++ b/examples/l2fwd/main.c
@@ -39,22 +39,13 @@
#include <rte_mempool.h>
#include <rte_mbuf.h>
+#include "l2fwd_common.h"
+
static volatile bool force_quit;
/* MAC updating enabled by default */
static int mac_updating = 1;
-#define RTE_LOGTYPE_L2FWD RTE_LOGTYPE_USER1
-
-#define MAX_PKT_BURST 32
-#define BURST_TX_DRAIN_US 100 /* TX drain every ~100us */
-#define MEMPOOL_CACHE_SIZE 256
-
-/*
- * Configurable number of RX/TX ring descriptors
- */
-#define RTE_TEST_RX_DESC_DEFAULT 1024
-#define RTE_TEST_TX_DESC_DEFAULT 1024
static uint16_t nb_rxd = RTE_TEST_RX_DESC_DEFAULT;
static uint16_t nb_txd = RTE_TEST_TX_DESC_DEFAULT;
@@ -69,8 +60,6 @@ static uint32_t l2fwd_dst_ports[RTE_MAX_ETHPORTS];
static unsigned int l2fwd_rx_queue_per_lcore = 1;
-#define MAX_RX_QUEUE_PER_LCORE 16
-#define MAX_TX_QUEUE_PER_PORT 16
struct lcore_queue_conf {
unsigned n_rx_port;
unsigned rx_port_list[MAX_RX_QUEUE_PER_LCORE];
@@ -100,7 +89,6 @@ struct l2fwd_port_statistics {
} __rte_cache_aligned;
struct l2fwd_port_statistics port_statistics[RTE_MAX_ETHPORTS];
-#define MAX_TIMER_PERIOD 86400 /* 1 day max */
/* A tsc-based timer responsible for triggering statistics printout */
static uint64_t timer_period = 10; /* default period is 10 seconds */
--
2.7.4
^ permalink raw reply [flat|nested] 83+ messages in thread
* [dpdk-dev] [PATCH v1 03/15] examples/l2fwd: move structure definitions to common header
2018-06-14 11:48 ` [dpdk-dev] [PATCH v1 00/15] preparing l2fwd for eventmode additions Anoob Joseph
2018-06-14 11:48 ` [dpdk-dev] [PATCH v1 01/15] examples/l2fwd: add new header to move common code Anoob Joseph
2018-06-14 11:48 ` [dpdk-dev] [PATCH v1 02/15] examples/l2fwd: move macro definitions to common header Anoob Joseph
@ 2018-06-14 11:48 ` Anoob Joseph
2018-06-14 11:48 ` [dpdk-dev] [PATCH v1 04/15] examples/l2fwd: move globally accessed vars " Anoob Joseph
` (13 subsequent siblings)
16 siblings, 0 replies; 83+ messages in thread
From: Anoob Joseph @ 2018-06-14 11:48 UTC (permalink / raw)
To: Bruce Richardson, Pablo de Lara
Cc: Anoob Joseph, Jerin Jacob, Narayana Prasad, dev
Signed-off-by: Anoob Joseph <anoob.joseph@caviumnetworks.com>
---
v1:
* Replaced 'unsigned' with 'unsigned int'
examples/l2fwd/l2fwd_common.h | 12 ++++++++++++
examples/l2fwd/main.c | 10 ----------
2 files changed, 12 insertions(+), 10 deletions(-)
diff --git a/examples/l2fwd/l2fwd_common.h b/examples/l2fwd/l2fwd_common.h
index fceb0c3..ca82e29 100644
--- a/examples/l2fwd/l2fwd_common.h
+++ b/examples/l2fwd/l2fwd_common.h
@@ -22,4 +22,16 @@
#define MAX_TIMER_PERIOD 86400 /* 1 day max */
+struct lcore_queue_conf {
+ unsigned int n_rx_port;
+ unsigned int rx_port_list[MAX_RX_QUEUE_PER_LCORE];
+} __rte_cache_aligned;
+
+/* Per-port statistics struct */
+struct l2fwd_port_statistics {
+ uint64_t tx;
+ uint64_t rx;
+ uint64_t dropped;
+} __rte_cache_aligned;
+
#endif /* _L2FWD_COMMON_H_ */
diff --git a/examples/l2fwd/main.c b/examples/l2fwd/main.c
index 9f873c7..11ca170 100644
--- a/examples/l2fwd/main.c
+++ b/examples/l2fwd/main.c
@@ -60,10 +60,6 @@ static uint32_t l2fwd_dst_ports[RTE_MAX_ETHPORTS];
static unsigned int l2fwd_rx_queue_per_lcore = 1;
-struct lcore_queue_conf {
- unsigned n_rx_port;
- unsigned rx_port_list[MAX_RX_QUEUE_PER_LCORE];
-} __rte_cache_aligned;
struct lcore_queue_conf lcore_queue_conf[RTE_MAX_LCORE];
static struct rte_eth_dev_tx_buffer *tx_buffer[RTE_MAX_ETHPORTS];
@@ -81,12 +77,6 @@ static struct rte_eth_conf port_conf = {
struct rte_mempool * l2fwd_pktmbuf_pool = NULL;
-/* Per-port statistics struct */
-struct l2fwd_port_statistics {
- uint64_t tx;
- uint64_t rx;
- uint64_t dropped;
-} __rte_cache_aligned;
struct l2fwd_port_statistics port_statistics[RTE_MAX_ETHPORTS];
/* A tsc-based timer responsible for triggering statistics printout */
--
2.7.4
^ permalink raw reply [flat|nested] 83+ messages in thread
* [dpdk-dev] [PATCH v1 04/15] examples/l2fwd: move globally accessed vars to common header
2018-06-14 11:48 ` [dpdk-dev] [PATCH v1 00/15] preparing l2fwd for eventmode additions Anoob Joseph
` (2 preceding siblings ...)
2018-06-14 11:48 ` [dpdk-dev] [PATCH v1 03/15] examples/l2fwd: move structure " Anoob Joseph
@ 2018-06-14 11:48 ` Anoob Joseph
2018-06-14 11:48 ` [dpdk-dev] [PATCH v1 05/15] examples/l2fwd: add missing space Anoob Joseph
` (12 subsequent siblings)
16 siblings, 0 replies; 83+ messages in thread
From: Anoob Joseph @ 2018-06-14 11:48 UTC (permalink / raw)
To: Bruce Richardson, Pablo de Lara
Cc: Anoob Joseph, Jerin Jacob, Narayana Prasad, dev
Signed-off-by: Anoob Joseph <anoob.joseph@caviumnetworks.com>
---
v1:
* No change
examples/l2fwd/l2fwd_common.h | 26 ++++++++++++++++++++++++++
examples/l2fwd/main.c | 41 +++++++++++++++++------------------------
2 files changed, 43 insertions(+), 24 deletions(-)
diff --git a/examples/l2fwd/l2fwd_common.h b/examples/l2fwd/l2fwd_common.h
index ca82e29..dd9f268 100644
--- a/examples/l2fwd/l2fwd_common.h
+++ b/examples/l2fwd/l2fwd_common.h
@@ -5,6 +5,10 @@
#ifndef _L2FWD_COMMON_H_
#define _L2FWD_COMMON_H_
+#include <stdbool.h>
+
+#include <rte_common.h>
+
#define RTE_LOGTYPE_L2FWD RTE_LOGTYPE_USER1
#define MAX_PKT_BURST 32
@@ -34,4 +38,26 @@ struct l2fwd_port_statistics {
uint64_t dropped;
} __rte_cache_aligned;
+volatile bool force_quit;
+
+int mac_updating;
+
+/* ethernet addresses of ports */
+struct ether_addr l2fwd_ports_eth_addr[RTE_MAX_ETHPORTS];
+
+/* mask of enabled ports */
+uint32_t l2fwd_enabled_port_mask;
+
+/* list of enabled ports */
+uint32_t l2fwd_dst_ports[RTE_MAX_ETHPORTS];
+
+struct lcore_queue_conf lcore_queue_conf[RTE_MAX_LCORE];
+
+struct rte_eth_dev_tx_buffer *tx_buffer[RTE_MAX_ETHPORTS];
+
+struct l2fwd_port_statistics port_statistics[RTE_MAX_ETHPORTS];
+
+/* A tsc-based timer responsible for triggering statistics printout */
+uint64_t timer_period;
+
#endif /* _L2FWD_COMMON_H_ */
diff --git a/examples/l2fwd/main.c b/examples/l2fwd/main.c
index 11ca170..a6089a1 100644
--- a/examples/l2fwd/main.c
+++ b/examples/l2fwd/main.c
@@ -41,29 +41,11 @@
#include "l2fwd_common.h"
-static volatile bool force_quit;
-
-/* MAC updating enabled by default */
-static int mac_updating = 1;
-
static uint16_t nb_rxd = RTE_TEST_RX_DESC_DEFAULT;
static uint16_t nb_txd = RTE_TEST_TX_DESC_DEFAULT;
-/* ethernet addresses of ports */
-static struct ether_addr l2fwd_ports_eth_addr[RTE_MAX_ETHPORTS];
-
-/* mask of enabled ports */
-static uint32_t l2fwd_enabled_port_mask = 0;
-
-/* list of enabled ports */
-static uint32_t l2fwd_dst_ports[RTE_MAX_ETHPORTS];
-
static unsigned int l2fwd_rx_queue_per_lcore = 1;
-struct lcore_queue_conf lcore_queue_conf[RTE_MAX_LCORE];
-
-static struct rte_eth_dev_tx_buffer *tx_buffer[RTE_MAX_ETHPORTS];
-
static struct rte_eth_conf port_conf = {
.rxmode = {
.split_hdr_size = 0,
@@ -77,11 +59,6 @@ static struct rte_eth_conf port_conf = {
struct rte_mempool * l2fwd_pktmbuf_pool = NULL;
-struct l2fwd_port_statistics port_statistics[RTE_MAX_ETHPORTS];
-
-/* A tsc-based timer responsible for triggering statistics printout */
-static uint64_t timer_period = 10; /* default period is 10 seconds */
-
/* Print out statistics on packets dropped */
static void
print_stats(void)
@@ -489,6 +466,20 @@ signal_handler(int signum)
}
}
+static void
+l2fwd_init_global_vars(void)
+{
+ force_quit = false;
+
+ /* MAC updating enabled by default */
+ mac_updating = 1;
+
+ /* Default period is 10 seconds */
+ timer_period = 10;
+
+ l2fwd_enabled_port_mask = 0;
+}
+
int
main(int argc, char **argv)
{
@@ -502,6 +493,9 @@ main(int argc, char **argv)
unsigned int nb_lcores = 0;
unsigned int nb_mbufs;
+ /* Set default values for global vars */
+ l2fwd_init_global_vars();
+
/* init EAL */
ret = rte_eal_init(argc, argv);
if (ret < 0)
@@ -509,7 +503,6 @@ main(int argc, char **argv)
argc -= ret;
argv += ret;
- force_quit = false;
signal(SIGINT, signal_handler);
signal(SIGTERM, signal_handler);
--
2.7.4
^ permalink raw reply [flat|nested] 83+ messages in thread
* [dpdk-dev] [PATCH v1 05/15] examples/l2fwd: add missing space
2018-06-14 11:48 ` [dpdk-dev] [PATCH v1 00/15] preparing l2fwd for eventmode additions Anoob Joseph
` (3 preceding siblings ...)
2018-06-14 11:48 ` [dpdk-dev] [PATCH v1 04/15] examples/l2fwd: move globally accessed vars " Anoob Joseph
@ 2018-06-14 11:48 ` Anoob Joseph
2018-07-09 22:51 ` De Lara Guarch, Pablo
2018-06-14 11:48 ` [dpdk-dev] [PATCH v1 06/15] examples/l2fwd: fix lines exceeding 80 char limit Anoob Joseph
` (11 subsequent siblings)
16 siblings, 1 reply; 83+ messages in thread
From: Anoob Joseph @ 2018-06-14 11:48 UTC (permalink / raw)
To: Bruce Richardson, Pablo de Lara
Cc: Anoob Joseph, Jerin Jacob, Narayana Prasad, dev
Signed-off-by: Anoob Joseph <anoob.joseph@caviumnetworks.com>
---
v1:
* No change
examples/l2fwd/main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/examples/l2fwd/main.c b/examples/l2fwd/main.c
index a6089a1..6229a20 100644
--- a/examples/l2fwd/main.c
+++ b/examples/l2fwd/main.c
@@ -71,7 +71,7 @@ print_stats(void)
total_packets_rx = 0;
const char clr[] = { 27, '[', '2', 'J', '\0' };
- const char topLeft[] = { 27, '[', '1', ';', '1', 'H','\0' };
+ const char topLeft[] = { 27, '[', '1', ';', '1', 'H', '\0' };
/* Clear screen and move to top left */
printf("%s%s", clr, topLeft);
--
2.7.4
^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: [dpdk-dev] [PATCH v1 05/15] examples/l2fwd: add missing space
2018-06-14 11:48 ` [dpdk-dev] [PATCH v1 05/15] examples/l2fwd: add missing space Anoob Joseph
@ 2018-07-09 22:51 ` De Lara Guarch, Pablo
2018-07-10 3:23 ` Anoob Joseph
0 siblings, 1 reply; 83+ messages in thread
From: De Lara Guarch, Pablo @ 2018-07-09 22:51 UTC (permalink / raw)
To: Anoob Joseph, Richardson, Bruce; +Cc: Jerin Jacob, Narayana Prasad, dev
> -----Original Message-----
> From: Anoob Joseph [mailto:anoob.joseph@caviumnetworks.com]
> Sent: Thursday, June 14, 2018 12:49 PM
> To: Richardson, Bruce <bruce.richardson@intel.com>; De Lara Guarch, Pablo
> <pablo.de.lara.guarch@intel.com>
> Cc: Anoob Joseph <anoob.joseph@caviumnetworks.com>; Jerin Jacob
> <jerin.jacob@caviumnetworks.com>; Narayana Prasad
> <narayanaprasad.athreya@caviumnetworks.com>; dev@dpdk.org
> Subject: [PATCH v1 05/15] examples/l2fwd: add missing space
>
> Signed-off-by: Anoob Joseph <anoob.joseph@caviumnetworks.com>
> ---
> v1:
> * No change
About changelog. This is a v1, so I don't see the point of having a changelog (this patchset is the baseline).
^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: [dpdk-dev] [PATCH v1 05/15] examples/l2fwd: add missing space
2018-07-09 22:51 ` De Lara Guarch, Pablo
@ 2018-07-10 3:23 ` Anoob Joseph
0 siblings, 0 replies; 83+ messages in thread
From: Anoob Joseph @ 2018-07-10 3:23 UTC (permalink / raw)
To: De Lara Guarch, Pablo, Richardson, Bruce
Cc: Jerin Jacob, Narayana Prasad, dev
Hi Pablo,
On 10-07-2018 04:21, De Lara Guarch, Pablo wrote:
> External Email
>
>> -----Original Message-----
>> From: Anoob Joseph [mailto:anoob.joseph@caviumnetworks.com]
>> Sent: Thursday, June 14, 2018 12:49 PM
>> To: Richardson, Bruce <bruce.richardson@intel.com>; De Lara Guarch, Pablo
>> <pablo.de.lara.guarch@intel.com>
>> Cc: Anoob Joseph <anoob.joseph@caviumnetworks.com>; Jerin Jacob
>> <jerin.jacob@caviumnetworks.com>; Narayana Prasad
>> <narayanaprasad.athreya@caviumnetworks.com>; dev@dpdk.org
>> Subject: [PATCH v1 05/15] examples/l2fwd: add missing space
>>
>> Signed-off-by: Anoob Joseph <anoob.joseph@caviumnetworks.com>
>> ---
>> v1:
>> * No change
> About changelog. This is a v1, so I don't see the point of having a changelog (this patchset is the baseline).
The patch series raised some checkpatch issues when I submitted the
code. All warnings were raised on the usage of "unsigned" instead of
"unsigned int", which was coming from the latest checkpatch. v1 of the
patch series was fixing that. In other patches which had the issue, I
have updated the changelog to reflect that. This one didn't have any
"unsigned" usage, and so "No change". Hope I'm following the right
convention.
Thanks,
Anoob
^ permalink raw reply [flat|nested] 83+ messages in thread
* [dpdk-dev] [PATCH v1 06/15] examples/l2fwd: fix lines exceeding 80 char limit
2018-06-14 11:48 ` [dpdk-dev] [PATCH v1 00/15] preparing l2fwd for eventmode additions Anoob Joseph
` (4 preceding siblings ...)
2018-06-14 11:48 ` [dpdk-dev] [PATCH v1 05/15] examples/l2fwd: add missing space Anoob Joseph
@ 2018-06-14 11:48 ` Anoob Joseph
2018-06-14 11:48 ` [dpdk-dev] [PATCH v1 07/15] examples/l2fwd: move dataplane code to new file Anoob Joseph
` (10 subsequent siblings)
16 siblings, 0 replies; 83+ messages in thread
From: Anoob Joseph @ 2018-06-14 11:48 UTC (permalink / raw)
To: Bruce Richardson, Pablo de Lara
Cc: Anoob Joseph, Jerin Jacob, Narayana Prasad, dev
Fixes: e2366e74e029 ("examples: use buffered Tx")
Fixes: af75078fece3 ("first public release")
Signed-off-by: Anoob Joseph <anoob.joseph@caviumnetworks.com>
---
v1:
* Replaced 'unsigned' with 'unsigned int'
examples/l2fwd/main.c | 15 ++++++++++-----
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/examples/l2fwd/main.c b/examples/l2fwd/main.c
index 6229a20..3e0269e 100644
--- a/examples/l2fwd/main.c
+++ b/examples/l2fwd/main.c
@@ -147,11 +147,12 @@ l2fwd_main_loop(void)
struct rte_mbuf *m;
int sent;
unsigned lcore_id;
+ unsigned int master_core_id;
uint64_t prev_tsc, diff_tsc, cur_tsc, timer_tsc;
unsigned i, j, portid, nb_rx;
struct lcore_queue_conf *qconf;
- const uint64_t drain_tsc = (rte_get_tsc_hz() + US_PER_S - 1) / US_PER_S *
- BURST_TX_DRAIN_US;
+ const uint64_t drain_tsc = (rte_get_tsc_hz() + US_PER_S - 1)
+ / US_PER_S * BURST_TX_DRAIN_US;
struct rte_eth_dev_tx_buffer *buffer;
prev_tsc = 0;
@@ -175,6 +176,8 @@ l2fwd_main_loop(void)
}
+ master_core_id = rte_get_master_lcore();
+
while (!force_quit) {
cur_tsc = rte_rdtsc();
@@ -187,10 +190,12 @@ l2fwd_main_loop(void)
for (i = 0; i < qconf->n_rx_port; i++) {
- portid = l2fwd_dst_ports[qconf->rx_port_list[i]];
+ portid =
+ l2fwd_dst_ports[qconf->rx_port_list[i]];
buffer = tx_buffer[portid];
- sent = rte_eth_tx_buffer_flush(portid, 0, buffer);
+ sent = rte_eth_tx_buffer_flush(portid, 0,
+ buffer);
if (sent)
port_statistics[portid].tx += sent;
@@ -206,7 +211,7 @@ l2fwd_main_loop(void)
if (unlikely(timer_tsc >= timer_period)) {
/* do this only on master core */
- if (lcore_id == rte_get_master_lcore()) {
+ if (lcore_id == master_core_id) {
print_stats();
/* reset the timer */
timer_tsc = 0;
--
2.7.4
^ permalink raw reply [flat|nested] 83+ messages in thread
* [dpdk-dev] [PATCH v1 07/15] examples/l2fwd: move dataplane code to new file
2018-06-14 11:48 ` [dpdk-dev] [PATCH v1 00/15] preparing l2fwd for eventmode additions Anoob Joseph
` (5 preceding siblings ...)
2018-06-14 11:48 ` [dpdk-dev] [PATCH v1 06/15] examples/l2fwd: fix lines exceeding 80 char limit Anoob Joseph
@ 2018-06-14 11:48 ` Anoob Joseph
2018-06-14 11:48 ` [dpdk-dev] [PATCH v1 08/15] examples/l2fwd: remove unused header includes Anoob Joseph
` (9 subsequent siblings)
16 siblings, 0 replies; 83+ messages in thread
From: Anoob Joseph @ 2018-06-14 11:48 UTC (permalink / raw)
To: Bruce Richardson, Pablo de Lara
Cc: Anoob Joseph, Jerin Jacob, Narayana Prasad, dev
Signed-off-by: Anoob Joseph <anoob.joseph@caviumnetworks.com>
---
v1:
* Replaced 'unsigned' with 'unsigned int'
examples/l2fwd/Makefile | 1 +
examples/l2fwd/l2fwd_worker.c | 233 ++++++++++++++++++++++++++++++++++++++++++
examples/l2fwd/l2fwd_worker.h | 10 ++
examples/l2fwd/main.c | 191 +---------------------------------
4 files changed, 245 insertions(+), 190 deletions(-)
create mode 100644 examples/l2fwd/l2fwd_worker.c
create mode 100644 examples/l2fwd/l2fwd_worker.h
diff --git a/examples/l2fwd/Makefile b/examples/l2fwd/Makefile
index a8a47ad..24d1e4e 100644
--- a/examples/l2fwd/Makefile
+++ b/examples/l2fwd/Makefile
@@ -6,6 +6,7 @@ APP = l2fwd
# all source are stored in SRCS-y
SRCS-y := main.c
+SRCS-y += l2fwd_worker.c
# Build using pkg-config variables if possible
$(shell pkg-config --exists libdpdk)
diff --git a/examples/l2fwd/l2fwd_worker.c b/examples/l2fwd/l2fwd_worker.c
new file mode 100644
index 0000000..663c505
--- /dev/null
+++ b/examples/l2fwd/l2fwd_worker.c
@@ -0,0 +1,233 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2010-2016 Intel Corporation
+ * Copyright(c) 2018 Cavium, Inc
+ */
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+#include <stdint.h>
+#include <inttypes.h>
+#include <sys/types.h>
+#include <sys/queue.h>
+#include <netinet/in.h>
+#include <setjmp.h>
+#include <stdarg.h>
+#include <ctype.h>
+#include <errno.h>
+#include <getopt.h>
+#include <signal.h>
+#include <stdbool.h>
+
+#include <rte_common.h>
+#include <rte_log.h>
+#include <rte_malloc.h>
+#include <rte_memory.h>
+#include <rte_memcpy.h>
+#include <rte_eal.h>
+#include <rte_launch.h>
+#include <rte_atomic.h>
+#include <rte_cycles.h>
+#include <rte_prefetch.h>
+#include <rte_lcore.h>
+#include <rte_per_lcore.h>
+#include <rte_branch_prediction.h>
+#include <rte_interrupts.h>
+#include <rte_random.h>
+#include <rte_debug.h>
+#include <rte_ether.h>
+#include <rte_ethdev.h>
+#include <rte_mempool.h>
+#include <rte_mbuf.h>
+
+#include "l2fwd_common.h"
+#include "l2fwd_worker.h"
+
+/* Print out statistics on packets dropped */
+static void
+print_stats(void)
+{
+ uint64_t total_packets_dropped, total_packets_tx, total_packets_rx;
+ unsigned int portid;
+
+ total_packets_dropped = 0;
+ total_packets_tx = 0;
+ total_packets_rx = 0;
+
+ const char clr[] = { 27, '[', '2', 'J', '\0' };
+ const char topLeft[] = { 27, '[', '1', ';', '1', 'H', '\0' };
+
+ /* Clear screen and move to top left */
+ printf("%s%s", clr, topLeft);
+
+ printf("\nPort statistics ====================================");
+
+ for (portid = 0; portid < RTE_MAX_ETHPORTS; portid++) {
+ /* skip disabled ports */
+ if ((l2fwd_enabled_port_mask & (1 << portid)) == 0)
+ continue;
+ printf("\nStatistics for port %u ------------------------------"
+ "\nPackets sent: %24"PRIu64
+ "\nPackets received: %20"PRIu64
+ "\nPackets dropped: %21"PRIu64,
+ portid,
+ port_statistics[portid].tx,
+ port_statistics[portid].rx,
+ port_statistics[portid].dropped);
+
+ total_packets_dropped += port_statistics[portid].dropped;
+ total_packets_tx += port_statistics[portid].tx;
+ total_packets_rx += port_statistics[portid].rx;
+ }
+ printf("\nAggregate statistics ==============================="
+ "\nTotal packets sent: %18"PRIu64
+ "\nTotal packets received: %14"PRIu64
+ "\nTotal packets dropped: %15"PRIu64,
+ total_packets_tx,
+ total_packets_rx,
+ total_packets_dropped);
+ printf("\n====================================================\n");
+}
+
+static void
+l2fwd_mac_updating(struct rte_mbuf *m, unsigned int dest_portid)
+{
+ struct ether_hdr *eth;
+ void *tmp;
+
+ eth = rte_pktmbuf_mtod(m, struct ether_hdr *);
+
+ /* 02:00:00:00:00:xx */
+ tmp = ð->d_addr.addr_bytes[0];
+ *((uint64_t *)tmp) = 0x000000000002 + ((uint64_t)dest_portid << 40);
+
+ /* src addr */
+ ether_addr_copy(&l2fwd_ports_eth_addr[dest_portid], ð->s_addr);
+}
+
+static void
+l2fwd_simple_forward(struct rte_mbuf *m, unsigned int portid)
+{
+ unsigned int dst_port;
+ int sent;
+ struct rte_eth_dev_tx_buffer *buffer;
+
+ dst_port = l2fwd_dst_ports[portid];
+
+ if (mac_updating)
+ l2fwd_mac_updating(m, dst_port);
+
+ buffer = tx_buffer[dst_port];
+ sent = rte_eth_tx_buffer(dst_port, 0, buffer, m);
+ if (sent)
+ port_statistics[dst_port].tx += sent;
+}
+
+/* main processing loop */
+static void
+l2fwd_main_loop(void)
+{
+ struct rte_mbuf *pkts_burst[MAX_PKT_BURST];
+ struct rte_mbuf *m;
+ int sent;
+ unsigned int lcore_id;
+ unsigned int master_core_id;
+ uint64_t prev_tsc, diff_tsc, cur_tsc, timer_tsc;
+ unsigned int i, j, portid, nb_rx;
+ struct lcore_queue_conf *qconf;
+ const uint64_t drain_tsc = (rte_get_tsc_hz() + US_PER_S - 1)
+ / US_PER_S * BURST_TX_DRAIN_US;
+ struct rte_eth_dev_tx_buffer *buffer;
+
+ prev_tsc = 0;
+ timer_tsc = 0;
+
+ lcore_id = rte_lcore_id();
+ qconf = &lcore_queue_conf[lcore_id];
+
+ if (qconf->n_rx_port == 0) {
+ RTE_LOG(INFO, L2FWD, "lcore %u has nothing to do\n", lcore_id);
+ return;
+ }
+
+ RTE_LOG(INFO, L2FWD, "entering main loop on lcore %u\n", lcore_id);
+
+ for (i = 0; i < qconf->n_rx_port; i++) {
+
+ portid = qconf->rx_port_list[i];
+ RTE_LOG(INFO, L2FWD, " -- lcoreid=%u portid=%u\n", lcore_id,
+ portid);
+
+ }
+
+ master_core_id = rte_get_master_lcore();
+
+ while (!force_quit) {
+
+ cur_tsc = rte_rdtsc();
+
+ /*
+ * TX burst queue drain
+ */
+ diff_tsc = cur_tsc - prev_tsc;
+ if (unlikely(diff_tsc > drain_tsc)) {
+
+ for (i = 0; i < qconf->n_rx_port; i++) {
+
+ portid =
+ l2fwd_dst_ports[qconf->rx_port_list[i]];
+ buffer = tx_buffer[portid];
+
+ sent = rte_eth_tx_buffer_flush(portid, 0,
+ buffer);
+ if (sent)
+ port_statistics[portid].tx += sent;
+
+ }
+
+ /* if timer is enabled */
+ if (timer_period > 0) {
+
+ /* advance the timer */
+ timer_tsc += diff_tsc;
+
+ /* if timer has reached its timeout */
+ if (unlikely(timer_tsc >= timer_period)) {
+
+ /* do this only on master core */
+ if (lcore_id == master_core_id) {
+ print_stats();
+ /* reset the timer */
+ timer_tsc = 0;
+ }
+ }
+ }
+
+ prev_tsc = cur_tsc;
+ }
+
+ /*
+ * Read packet from RX queues
+ */
+ for (i = 0; i < qconf->n_rx_port; i++) {
+
+ portid = qconf->rx_port_list[i];
+ nb_rx = rte_eth_rx_burst(portid, 0,
+ pkts_burst, MAX_PKT_BURST);
+
+ port_statistics[portid].rx += nb_rx;
+
+ for (j = 0; j < nb_rx; j++) {
+ m = pkts_burst[j];
+ rte_prefetch0(rte_pktmbuf_mtod(m, void *));
+ l2fwd_simple_forward(m, portid);
+ }
+ }
+ }
+}
+
+int
+l2fwd_launch_one_lcore(__attribute__((unused)) void *dummy)
+{
+ l2fwd_main_loop();
+ return 0;
+}
diff --git a/examples/l2fwd/l2fwd_worker.h b/examples/l2fwd/l2fwd_worker.h
new file mode 100644
index 0000000..8971a6a
--- /dev/null
+++ b/examples/l2fwd/l2fwd_worker.h
@@ -0,0 +1,10 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2018 Cavium, Inc
+ */
+#ifndef _L2FWD_WORKER_H_
+#define _L2FWD_WORKER_H_
+
+int
+l2fwd_launch_one_lcore(__attribute__((unused)) void *dummy);
+
+#endif /* _L2FWD_WORKER_H_ */
diff --git a/examples/l2fwd/main.c b/examples/l2fwd/main.c
index 3e0269e..05f9d28 100644
--- a/examples/l2fwd/main.c
+++ b/examples/l2fwd/main.c
@@ -40,6 +40,7 @@
#include <rte_mbuf.h>
#include "l2fwd_common.h"
+#include "l2fwd_worker.h"
static uint16_t nb_rxd = RTE_TEST_RX_DESC_DEFAULT;
static uint16_t nb_txd = RTE_TEST_TX_DESC_DEFAULT;
@@ -59,196 +60,6 @@ static struct rte_eth_conf port_conf = {
struct rte_mempool * l2fwd_pktmbuf_pool = NULL;
-/* Print out statistics on packets dropped */
-static void
-print_stats(void)
-{
- uint64_t total_packets_dropped, total_packets_tx, total_packets_rx;
- unsigned portid;
-
- total_packets_dropped = 0;
- total_packets_tx = 0;
- total_packets_rx = 0;
-
- const char clr[] = { 27, '[', '2', 'J', '\0' };
- const char topLeft[] = { 27, '[', '1', ';', '1', 'H', '\0' };
-
- /* Clear screen and move to top left */
- printf("%s%s", clr, topLeft);
-
- printf("\nPort statistics ====================================");
-
- for (portid = 0; portid < RTE_MAX_ETHPORTS; portid++) {
- /* skip disabled ports */
- if ((l2fwd_enabled_port_mask & (1 << portid)) == 0)
- continue;
- printf("\nStatistics for port %u ------------------------------"
- "\nPackets sent: %24"PRIu64
- "\nPackets received: %20"PRIu64
- "\nPackets dropped: %21"PRIu64,
- portid,
- port_statistics[portid].tx,
- port_statistics[portid].rx,
- port_statistics[portid].dropped);
-
- total_packets_dropped += port_statistics[portid].dropped;
- total_packets_tx += port_statistics[portid].tx;
- total_packets_rx += port_statistics[portid].rx;
- }
- printf("\nAggregate statistics ==============================="
- "\nTotal packets sent: %18"PRIu64
- "\nTotal packets received: %14"PRIu64
- "\nTotal packets dropped: %15"PRIu64,
- total_packets_tx,
- total_packets_rx,
- total_packets_dropped);
- printf("\n====================================================\n");
-}
-
-static void
-l2fwd_mac_updating(struct rte_mbuf *m, unsigned dest_portid)
-{
- struct ether_hdr *eth;
- void *tmp;
-
- eth = rte_pktmbuf_mtod(m, struct ether_hdr *);
-
- /* 02:00:00:00:00:xx */
- tmp = ð->d_addr.addr_bytes[0];
- *((uint64_t *)tmp) = 0x000000000002 + ((uint64_t)dest_portid << 40);
-
- /* src addr */
- ether_addr_copy(&l2fwd_ports_eth_addr[dest_portid], ð->s_addr);
-}
-
-static void
-l2fwd_simple_forward(struct rte_mbuf *m, unsigned portid)
-{
- unsigned dst_port;
- int sent;
- struct rte_eth_dev_tx_buffer *buffer;
-
- dst_port = l2fwd_dst_ports[portid];
-
- if (mac_updating)
- l2fwd_mac_updating(m, dst_port);
-
- buffer = tx_buffer[dst_port];
- sent = rte_eth_tx_buffer(dst_port, 0, buffer, m);
- if (sent)
- port_statistics[dst_port].tx += sent;
-}
-
-/* main processing loop */
-static void
-l2fwd_main_loop(void)
-{
- struct rte_mbuf *pkts_burst[MAX_PKT_BURST];
- struct rte_mbuf *m;
- int sent;
- unsigned lcore_id;
- unsigned int master_core_id;
- uint64_t prev_tsc, diff_tsc, cur_tsc, timer_tsc;
- unsigned i, j, portid, nb_rx;
- struct lcore_queue_conf *qconf;
- const uint64_t drain_tsc = (rte_get_tsc_hz() + US_PER_S - 1)
- / US_PER_S * BURST_TX_DRAIN_US;
- struct rte_eth_dev_tx_buffer *buffer;
-
- prev_tsc = 0;
- timer_tsc = 0;
-
- lcore_id = rte_lcore_id();
- qconf = &lcore_queue_conf[lcore_id];
-
- if (qconf->n_rx_port == 0) {
- RTE_LOG(INFO, L2FWD, "lcore %u has nothing to do\n", lcore_id);
- return;
- }
-
- RTE_LOG(INFO, L2FWD, "entering main loop on lcore %u\n", lcore_id);
-
- for (i = 0; i < qconf->n_rx_port; i++) {
-
- portid = qconf->rx_port_list[i];
- RTE_LOG(INFO, L2FWD, " -- lcoreid=%u portid=%u\n", lcore_id,
- portid);
-
- }
-
- master_core_id = rte_get_master_lcore();
-
- while (!force_quit) {
-
- cur_tsc = rte_rdtsc();
-
- /*
- * TX burst queue drain
- */
- diff_tsc = cur_tsc - prev_tsc;
- if (unlikely(diff_tsc > drain_tsc)) {
-
- for (i = 0; i < qconf->n_rx_port; i++) {
-
- portid =
- l2fwd_dst_ports[qconf->rx_port_list[i]];
- buffer = tx_buffer[portid];
-
- sent = rte_eth_tx_buffer_flush(portid, 0,
- buffer);
- if (sent)
- port_statistics[portid].tx += sent;
-
- }
-
- /* if timer is enabled */
- if (timer_period > 0) {
-
- /* advance the timer */
- timer_tsc += diff_tsc;
-
- /* if timer has reached its timeout */
- if (unlikely(timer_tsc >= timer_period)) {
-
- /* do this only on master core */
- if (lcore_id == master_core_id) {
- print_stats();
- /* reset the timer */
- timer_tsc = 0;
- }
- }
- }
-
- prev_tsc = cur_tsc;
- }
-
- /*
- * Read packet from RX queues
- */
- for (i = 0; i < qconf->n_rx_port; i++) {
-
- portid = qconf->rx_port_list[i];
- nb_rx = rte_eth_rx_burst(portid, 0,
- pkts_burst, MAX_PKT_BURST);
-
- port_statistics[portid].rx += nb_rx;
-
- for (j = 0; j < nb_rx; j++) {
- m = pkts_burst[j];
- rte_prefetch0(rte_pktmbuf_mtod(m, void *));
- l2fwd_simple_forward(m, portid);
- }
- }
- }
-}
-
-static int
-l2fwd_launch_one_lcore(__attribute__((unused)) void *dummy)
-{
- l2fwd_main_loop();
- return 0;
-}
-
/* display usage */
static void
l2fwd_usage(const char *prgname)
--
2.7.4
^ permalink raw reply [flat|nested] 83+ messages in thread
* [dpdk-dev] [PATCH v1 08/15] examples/l2fwd: remove unused header includes
2018-06-14 11:48 ` [dpdk-dev] [PATCH v1 00/15] preparing l2fwd for eventmode additions Anoob Joseph
` (6 preceding siblings ...)
2018-06-14 11:48 ` [dpdk-dev] [PATCH v1 07/15] examples/l2fwd: move dataplane code to new file Anoob Joseph
@ 2018-06-14 11:48 ` Anoob Joseph
2018-06-14 11:49 ` [dpdk-dev] [PATCH v1 09/15] examples/l2fwd: move drain buffers to new function Anoob Joseph
` (8 subsequent siblings)
16 siblings, 0 replies; 83+ messages in thread
From: Anoob Joseph @ 2018-06-14 11:48 UTC (permalink / raw)
To: Bruce Richardson, Pablo de Lara
Cc: Anoob Joseph, Jerin Jacob, Narayana Prasad, dev
Signed-off-by: Anoob Joseph <anoob.joseph@caviumnetworks.com>
---
v1:
* No change
examples/l2fwd/l2fwd_worker.c | 12 ------------
1 file changed, 12 deletions(-)
diff --git a/examples/l2fwd/l2fwd_worker.c b/examples/l2fwd/l2fwd_worker.c
index 663c505..ad5468a 100644
--- a/examples/l2fwd/l2fwd_worker.c
+++ b/examples/l2fwd/l2fwd_worker.c
@@ -13,30 +13,18 @@
#include <setjmp.h>
#include <stdarg.h>
#include <ctype.h>
-#include <errno.h>
-#include <getopt.h>
-#include <signal.h>
#include <stdbool.h>
#include <rte_common.h>
#include <rte_log.h>
-#include <rte_malloc.h>
-#include <rte_memory.h>
#include <rte_memcpy.h>
-#include <rte_eal.h>
-#include <rte_launch.h>
#include <rte_atomic.h>
#include <rte_cycles.h>
#include <rte_prefetch.h>
#include <rte_lcore.h>
-#include <rte_per_lcore.h>
#include <rte_branch_prediction.h>
-#include <rte_interrupts.h>
-#include <rte_random.h>
-#include <rte_debug.h>
#include <rte_ether.h>
#include <rte_ethdev.h>
-#include <rte_mempool.h>
#include <rte_mbuf.h>
#include "l2fwd_common.h"
--
2.7.4
^ permalink raw reply [flat|nested] 83+ messages in thread
* [dpdk-dev] [PATCH v1 09/15] examples/l2fwd: move drain buffers to new function
2018-06-14 11:48 ` [dpdk-dev] [PATCH v1 00/15] preparing l2fwd for eventmode additions Anoob Joseph
` (7 preceding siblings ...)
2018-06-14 11:48 ` [dpdk-dev] [PATCH v1 08/15] examples/l2fwd: remove unused header includes Anoob Joseph
@ 2018-06-14 11:49 ` Anoob Joseph
2018-06-14 11:49 ` [dpdk-dev] [PATCH v1 10/15] examples/l2fwd: optimize check for master core Anoob Joseph
` (7 subsequent siblings)
16 siblings, 0 replies; 83+ messages in thread
From: Anoob Joseph @ 2018-06-14 11:49 UTC (permalink / raw)
To: Bruce Richardson, Pablo de Lara
Cc: Anoob Joseph, Jerin Jacob, Narayana Prasad, dev
Signed-off-by: Anoob Joseph <anoob.joseph@caviumnetworks.com>
---
v1:
* Replaced 'unsigned' with 'unsigned int'
examples/l2fwd/l2fwd_worker.c | 34 ++++++++++++++++++++--------------
1 file changed, 20 insertions(+), 14 deletions(-)
diff --git a/examples/l2fwd/l2fwd_worker.c b/examples/l2fwd/l2fwd_worker.c
index ad5468a..dfa78ed 100644
--- a/examples/l2fwd/l2fwd_worker.c
+++ b/examples/l2fwd/l2fwd_worker.c
@@ -76,6 +76,24 @@ print_stats(void)
printf("\n====================================================\n");
}
+static inline void
+l2fwd_drain_buffers(struct lcore_queue_conf *qconf)
+{
+ unsigned int i, sent;
+ unsigned int portid;
+ struct rte_eth_dev_tx_buffer *buffer;
+
+ for (i = 0; i < qconf->n_rx_port; i++) {
+
+ portid = l2fwd_dst_ports[qconf->rx_port_list[i]];
+ buffer = tx_buffer[portid];
+
+ sent = rte_eth_tx_buffer_flush(portid, 0, buffer);
+ if (sent)
+ port_statistics[portid].tx += sent;
+ }
+}
+
static void
l2fwd_mac_updating(struct rte_mbuf *m, unsigned int dest_portid)
{
@@ -116,7 +134,6 @@ l2fwd_main_loop(void)
{
struct rte_mbuf *pkts_burst[MAX_PKT_BURST];
struct rte_mbuf *m;
- int sent;
unsigned int lcore_id;
unsigned int master_core_id;
uint64_t prev_tsc, diff_tsc, cur_tsc, timer_tsc;
@@ -124,7 +141,6 @@ l2fwd_main_loop(void)
struct lcore_queue_conf *qconf;
const uint64_t drain_tsc = (rte_get_tsc_hz() + US_PER_S - 1)
/ US_PER_S * BURST_TX_DRAIN_US;
- struct rte_eth_dev_tx_buffer *buffer;
prev_tsc = 0;
timer_tsc = 0;
@@ -159,18 +175,8 @@ l2fwd_main_loop(void)
diff_tsc = cur_tsc - prev_tsc;
if (unlikely(diff_tsc > drain_tsc)) {
- for (i = 0; i < qconf->n_rx_port; i++) {
-
- portid =
- l2fwd_dst_ports[qconf->rx_port_list[i]];
- buffer = tx_buffer[portid];
-
- sent = rte_eth_tx_buffer_flush(portid, 0,
- buffer);
- if (sent)
- port_statistics[portid].tx += sent;
-
- }
+ /* Drain buffers */
+ l2fwd_drain_buffers(qconf);
/* if timer is enabled */
if (timer_period > 0) {
--
2.7.4
^ permalink raw reply [flat|nested] 83+ messages in thread
* [dpdk-dev] [PATCH v1 10/15] examples/l2fwd: optimize check for master core
2018-06-14 11:48 ` [dpdk-dev] [PATCH v1 00/15] preparing l2fwd for eventmode additions Anoob Joseph
` (8 preceding siblings ...)
2018-06-14 11:49 ` [dpdk-dev] [PATCH v1 09/15] examples/l2fwd: move drain buffers to new function Anoob Joseph
@ 2018-06-14 11:49 ` Anoob Joseph
2018-06-14 11:49 ` [dpdk-dev] [PATCH v1 11/15] examples/l2fwd: move periodic tasks to new function Anoob Joseph
` (6 subsequent siblings)
16 siblings, 0 replies; 83+ messages in thread
From: Anoob Joseph @ 2018-06-14 11:49 UTC (permalink / raw)
To: Bruce Richardson, Pablo de Lara
Cc: Anoob Joseph, Jerin Jacob, Narayana Prasad, dev
Replacing the check for lcore_id & mastercore_id with the check for a
flag.
Signed-off-by: Anoob Joseph <anoob.joseph@caviumnetworks.com>
---
v1:
* Replaced 'unsigned' with 'unsigned int'
examples/l2fwd/l2fwd_worker.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/examples/l2fwd/l2fwd_worker.c b/examples/l2fwd/l2fwd_worker.c
index dfa78ed..f847832 100644
--- a/examples/l2fwd/l2fwd_worker.c
+++ b/examples/l2fwd/l2fwd_worker.c
@@ -135,12 +135,12 @@ l2fwd_main_loop(void)
struct rte_mbuf *pkts_burst[MAX_PKT_BURST];
struct rte_mbuf *m;
unsigned int lcore_id;
- unsigned int master_core_id;
uint64_t prev_tsc, diff_tsc, cur_tsc, timer_tsc;
unsigned int i, j, portid, nb_rx;
struct lcore_queue_conf *qconf;
const uint64_t drain_tsc = (rte_get_tsc_hz() + US_PER_S - 1)
/ US_PER_S * BURST_TX_DRAIN_US;
+ int is_master_core;
prev_tsc = 0;
timer_tsc = 0;
@@ -162,8 +162,8 @@ l2fwd_main_loop(void)
portid);
}
-
- master_core_id = rte_get_master_lcore();
+ /* Set the flag if master core */
+ is_master_core = (lcore_id == rte_get_master_lcore()) ? 1 : 0;
while (!force_quit) {
@@ -188,7 +188,7 @@ l2fwd_main_loop(void)
if (unlikely(timer_tsc >= timer_period)) {
/* do this only on master core */
- if (lcore_id == master_core_id) {
+ if (is_master_core) {
print_stats();
/* reset the timer */
timer_tsc = 0;
--
2.7.4
^ permalink raw reply [flat|nested] 83+ messages in thread
* [dpdk-dev] [PATCH v1 11/15] examples/l2fwd: move periodic tasks to new function
2018-06-14 11:48 ` [dpdk-dev] [PATCH v1 00/15] preparing l2fwd for eventmode additions Anoob Joseph
` (9 preceding siblings ...)
2018-06-14 11:49 ` [dpdk-dev] [PATCH v1 10/15] examples/l2fwd: optimize check for master core Anoob Joseph
@ 2018-06-14 11:49 ` Anoob Joseph
2018-06-14 11:49 ` [dpdk-dev] [PATCH v1 12/15] examples/l2fwd: skip timer updates for non master cores Anoob Joseph
` (5 subsequent siblings)
16 siblings, 0 replies; 83+ messages in thread
From: Anoob Joseph @ 2018-06-14 11:49 UTC (permalink / raw)
To: Bruce Richardson, Pablo de Lara
Cc: Anoob Joseph, Jerin Jacob, Narayana Prasad, dev
Move the periodic operations (stats flush and drain buffers) to a new
function.
Signed-off-by: Anoob Joseph <anoob.joseph@caviumnetworks.com>
---
v1:
* Replaced 'unsigned' with 'unsigned int'
examples/l2fwd/l2fwd_worker.c | 83 ++++++++++++++++++++++++-------------------
examples/l2fwd/l2fwd_worker.h | 6 ++++
2 files changed, 52 insertions(+), 37 deletions(-)
diff --git a/examples/l2fwd/l2fwd_worker.c b/examples/l2fwd/l2fwd_worker.c
index f847832..868d0c6 100644
--- a/examples/l2fwd/l2fwd_worker.c
+++ b/examples/l2fwd/l2fwd_worker.c
@@ -94,6 +94,45 @@ l2fwd_drain_buffers(struct lcore_queue_conf *qconf)
}
}
+static inline void
+l2fwd_periodic_drain_stats_monitor(struct lcore_queue_conf *qconf,
+ struct tsc_tracker *t, int is_master_core)
+{
+ uint64_t diff_tsc, cur_tsc;
+
+ cur_tsc = rte_rdtsc();
+
+ /*
+ * TX burst queue drain
+ */
+ diff_tsc = cur_tsc - t->prev_tsc;
+ if (unlikely(diff_tsc > t->drain_tsc)) {
+
+ /* Drain buffers */
+ l2fwd_drain_buffers(qconf);
+
+ /* if timer is enabled */
+ if (timer_period > 0) {
+
+ /* advance the timer */
+ t->timer_tsc += diff_tsc;
+
+ /* if timer has reached its timeout */
+ if (unlikely(t->timer_tsc >= timer_period)) {
+
+ /* do this only on master core */
+ if (is_master_core) {
+ print_stats();
+ /* reset the timer */
+ t->timer_tsc = 0;
+ }
+ }
+ }
+
+ t->prev_tsc = cur_tsc;
+ }
+}
+
static void
l2fwd_mac_updating(struct rte_mbuf *m, unsigned int dest_portid)
{
@@ -135,19 +174,18 @@ l2fwd_main_loop(void)
struct rte_mbuf *pkts_burst[MAX_PKT_BURST];
struct rte_mbuf *m;
unsigned int lcore_id;
- uint64_t prev_tsc, diff_tsc, cur_tsc, timer_tsc;
unsigned int i, j, portid, nb_rx;
struct lcore_queue_conf *qconf;
- const uint64_t drain_tsc = (rte_get_tsc_hz() + US_PER_S - 1)
- / US_PER_S * BURST_TX_DRAIN_US;
int is_master_core;
-
- prev_tsc = 0;
- timer_tsc = 0;
+ struct tsc_tracker tsc = {0};
lcore_id = rte_lcore_id();
qconf = &lcore_queue_conf[lcore_id];
+ /* Set drain tsc */
+ tsc.drain_tsc = (rte_get_tsc_hz() + US_PER_S - 1) /
+ US_PER_S * BURST_TX_DRAIN_US;
+
if (qconf->n_rx_port == 0) {
RTE_LOG(INFO, L2FWD, "lcore %u has nothing to do\n", lcore_id);
return;
@@ -167,37 +205,8 @@ l2fwd_main_loop(void)
while (!force_quit) {
- cur_tsc = rte_rdtsc();
-
- /*
- * TX burst queue drain
- */
- diff_tsc = cur_tsc - prev_tsc;
- if (unlikely(diff_tsc > drain_tsc)) {
-
- /* Drain buffers */
- l2fwd_drain_buffers(qconf);
-
- /* if timer is enabled */
- if (timer_period > 0) {
-
- /* advance the timer */
- timer_tsc += diff_tsc;
-
- /* if timer has reached its timeout */
- if (unlikely(timer_tsc >= timer_period)) {
-
- /* do this only on master core */
- if (is_master_core) {
- print_stats();
- /* reset the timer */
- timer_tsc = 0;
- }
- }
- }
-
- prev_tsc = cur_tsc;
- }
+ /* Do periodic operations (buffer drain & stats monitor) */
+ l2fwd_periodic_drain_stats_monitor(qconf, &tsc, is_master_core);
/*
* Read packet from RX queues
diff --git a/examples/l2fwd/l2fwd_worker.h b/examples/l2fwd/l2fwd_worker.h
index 8971a6a..65650aa 100644
--- a/examples/l2fwd/l2fwd_worker.h
+++ b/examples/l2fwd/l2fwd_worker.h
@@ -4,6 +4,12 @@
#ifndef _L2FWD_WORKER_H_
#define _L2FWD_WORKER_H_
+struct tsc_tracker {
+ uint64_t prev_tsc;
+ uint64_t timer_tsc;
+ uint64_t drain_tsc;
+};
+
int
l2fwd_launch_one_lcore(__attribute__((unused)) void *dummy);
--
2.7.4
^ permalink raw reply [flat|nested] 83+ messages in thread
* [dpdk-dev] [PATCH v1 12/15] examples/l2fwd: skip timer updates for non master cores
2018-06-14 11:48 ` [dpdk-dev] [PATCH v1 00/15] preparing l2fwd for eventmode additions Anoob Joseph
` (10 preceding siblings ...)
2018-06-14 11:49 ` [dpdk-dev] [PATCH v1 11/15] examples/l2fwd: move periodic tasks to new function Anoob Joseph
@ 2018-06-14 11:49 ` Anoob Joseph
2018-06-14 11:49 ` [dpdk-dev] [PATCH v1 13/15] examples/l2fwd: move pkt send code to a new function Anoob Joseph
` (4 subsequent siblings)
16 siblings, 0 replies; 83+ messages in thread
From: Anoob Joseph @ 2018-06-14 11:49 UTC (permalink / raw)
To: Bruce Richardson, Pablo de Lara
Cc: Anoob Joseph, Jerin Jacob, Narayana Prasad, dev
The timer updates and checks are required only for stats printing by the
master core. This can be entirely skipped for other cores.
Signed-off-by: Anoob Joseph <anoob.joseph@caviumnetworks.com>
---
v1:
* No change
examples/l2fwd/l2fwd_worker.c | 21 +++++++++++++--------
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/examples/l2fwd/l2fwd_worker.c b/examples/l2fwd/l2fwd_worker.c
index 868d0c6..d6a5e90 100644
--- a/examples/l2fwd/l2fwd_worker.c
+++ b/examples/l2fwd/l2fwd_worker.c
@@ -111,6 +111,14 @@ l2fwd_periodic_drain_stats_monitor(struct lcore_queue_conf *qconf,
/* Drain buffers */
l2fwd_drain_buffers(qconf);
+ t->prev_tsc = cur_tsc;
+
+ /* Skip the timer based stats prints if not master core */
+ if (!is_master_core)
+ return;
+
+ /* On master core */
+
/* if timer is enabled */
if (timer_period > 0) {
@@ -120,16 +128,13 @@ l2fwd_periodic_drain_stats_monitor(struct lcore_queue_conf *qconf,
/* if timer has reached its timeout */
if (unlikely(t->timer_tsc >= timer_period)) {
- /* do this only on master core */
- if (is_master_core) {
- print_stats();
- /* reset the timer */
- t->timer_tsc = 0;
- }
+ /* Print stats */
+ print_stats();
+
+ /* reset the timer */
+ t->timer_tsc = 0;
}
}
-
- t->prev_tsc = cur_tsc;
}
}
--
2.7.4
^ permalink raw reply [flat|nested] 83+ messages in thread
* [dpdk-dev] [PATCH v1 13/15] examples/l2fwd: move pkt send code to a new function
2018-06-14 11:48 ` [dpdk-dev] [PATCH v1 00/15] preparing l2fwd for eventmode additions Anoob Joseph
` (11 preceding siblings ...)
2018-06-14 11:49 ` [dpdk-dev] [PATCH v1 12/15] examples/l2fwd: skip timer updates for non master cores Anoob Joseph
@ 2018-06-14 11:49 ` Anoob Joseph
2018-06-14 11:49 ` [dpdk-dev] [PATCH v1 14/15] examples/l2fwd: use fprint instead of printf for usage print Anoob Joseph
` (3 subsequent siblings)
16 siblings, 0 replies; 83+ messages in thread
From: Anoob Joseph @ 2018-06-14 11:49 UTC (permalink / raw)
To: Bruce Richardson, Pablo de Lara
Cc: Anoob Joseph, Jerin Jacob, Narayana Prasad, dev
Signed-off-by: Anoob Joseph <anoob.joseph@caviumnetworks.com>
---
v1:
* Replaced 'unsigned' with 'unsigned int'
examples/l2fwd/l2fwd_worker.c | 20 ++++++++++++++------
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/examples/l2fwd/l2fwd_worker.c b/examples/l2fwd/l2fwd_worker.c
index d6a5e90..bac1946 100644
--- a/examples/l2fwd/l2fwd_worker.c
+++ b/examples/l2fwd/l2fwd_worker.c
@@ -154,22 +154,30 @@ l2fwd_mac_updating(struct rte_mbuf *m, unsigned int dest_portid)
ether_addr_copy(&l2fwd_ports_eth_addr[dest_portid], ð->s_addr);
}
+static inline void
+l2fwd_send_pkt(struct rte_mbuf *tx_pkt, unsigned int port_id)
+{
+ int sent;
+ struct rte_eth_dev_tx_buffer *buffer;
+
+ buffer = tx_buffer[port_id];
+ sent = rte_eth_tx_buffer(port_id, 0, buffer, tx_pkt);
+ if (sent)
+ port_statistics[port_id].tx += sent;
+}
+
static void
l2fwd_simple_forward(struct rte_mbuf *m, unsigned int portid)
{
unsigned int dst_port;
- int sent;
- struct rte_eth_dev_tx_buffer *buffer;
dst_port = l2fwd_dst_ports[portid];
if (mac_updating)
l2fwd_mac_updating(m, dst_port);
- buffer = tx_buffer[dst_port];
- sent = rte_eth_tx_buffer(dst_port, 0, buffer, m);
- if (sent)
- port_statistics[dst_port].tx += sent;
+ /* Send packet */
+ l2fwd_send_pkt(m, dst_port);
}
/* main processing loop */
--
2.7.4
^ permalink raw reply [flat|nested] 83+ messages in thread
* [dpdk-dev] [PATCH v1 14/15] examples/l2fwd: use fprint instead of printf for usage print
2018-06-14 11:48 ` [dpdk-dev] [PATCH v1 00/15] preparing l2fwd for eventmode additions Anoob Joseph
` (12 preceding siblings ...)
2018-06-14 11:49 ` [dpdk-dev] [PATCH v1 13/15] examples/l2fwd: move pkt send code to a new function Anoob Joseph
@ 2018-06-14 11:49 ` Anoob Joseph
2018-06-14 11:49 ` [dpdk-dev] [PATCH v1 15/15] examples/l2fwd: improvements to the " Anoob Joseph
` (2 subsequent siblings)
16 siblings, 0 replies; 83+ messages in thread
From: Anoob Joseph @ 2018-06-14 11:49 UTC (permalink / raw)
To: Bruce Richardson, Pablo de Lara
Cc: Anoob Joseph, Jerin Jacob, Narayana Prasad, dev
Following the convention of l3fwd, using fprintf instead of printf for
printing usage.
Signed-off-by: Anoob Joseph <anoob.joseph@caviumnetworks.com>
---
v1:
* No change
examples/l2fwd/main.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/examples/l2fwd/main.c b/examples/l2fwd/main.c
index 05f9d28..3b697d1 100644
--- a/examples/l2fwd/main.c
+++ b/examples/l2fwd/main.c
@@ -64,7 +64,9 @@ struct rte_mempool * l2fwd_pktmbuf_pool = NULL;
static void
l2fwd_usage(const char *prgname)
{
- printf("%s [EAL options] -- -p PORTMASK [-q NQ]\n"
+ fprintf(stderr, "%s [EAL options] --"
+ " -p PORTMASK"
+ " [-q NQ]\n"
" -p PORTMASK: hexadecimal bitmask of ports to configure\n"
" -q NQ: number of queue (=ports) per lcore (default is 1)\n"
" -T PERIOD: statistics will be refreshed each PERIOD seconds (0 to disable, 10 default, 86400 maximum)\n"
--
2.7.4
^ permalink raw reply [flat|nested] 83+ messages in thread
* [dpdk-dev] [PATCH v1 15/15] examples/l2fwd: improvements to the usage print
2018-06-14 11:48 ` [dpdk-dev] [PATCH v1 00/15] preparing l2fwd for eventmode additions Anoob Joseph
` (13 preceding siblings ...)
2018-06-14 11:49 ` [dpdk-dev] [PATCH v1 14/15] examples/l2fwd: use fprint instead of printf for usage print Anoob Joseph
@ 2018-06-14 11:49 ` Anoob Joseph
2018-06-19 10:04 ` [dpdk-dev] [PATCH v1 00/15] preparing l2fwd for eventmode additions Anoob Joseph
2018-07-11 6:07 ` [dpdk-dev] [PATCH v2 00/12] " Anoob Joseph
16 siblings, 0 replies; 83+ messages in thread
From: Anoob Joseph @ 2018-06-14 11:49 UTC (permalink / raw)
To: Bruce Richardson, Pablo de Lara
Cc: Anoob Joseph, Jerin Jacob, Narayana Prasad, dev
Fixed alignment and split the usage print to aid easy addition of
eventmode usage prints.
Signed-off-by: Anoob Joseph <anoob.joseph@caviumnetworks.com>
---
v1:
* No change
examples/l2fwd/main.c | 23 ++++++++++++++---------
1 file changed, 14 insertions(+), 9 deletions(-)
diff --git a/examples/l2fwd/main.c b/examples/l2fwd/main.c
index 3b697d1..ac81beb 100644
--- a/examples/l2fwd/main.c
+++ b/examples/l2fwd/main.c
@@ -66,15 +66,20 @@ l2fwd_usage(const char *prgname)
{
fprintf(stderr, "%s [EAL options] --"
" -p PORTMASK"
- " [-q NQ]\n"
- " -p PORTMASK: hexadecimal bitmask of ports to configure\n"
- " -q NQ: number of queue (=ports) per lcore (default is 1)\n"
- " -T PERIOD: statistics will be refreshed each PERIOD seconds (0 to disable, 10 default, 86400 maximum)\n"
- " --[no-]mac-updating: Enable or disable MAC addresses updating (enabled by default)\n"
- " When enabled:\n"
- " - The source MAC address is replaced by the TX port MAC address\n"
- " - The destination MAC address is replaced by 02:00:00:00:00:TX_PORT_ID\n",
- prgname);
+ " [-q NQ]",
+ prgname);
+
+ fprintf(stderr, "\n\n");
+
+ fprintf(stderr,
+ " -p PORTMASK: hexadecimal bitmask of ports to configure\n"
+ " -q NQ: number of queue (=ports) per lcore (default is 1)\n"
+ " -T PERIOD: statistics will be refreshed each PERIOD seconds (0 to disable, 10 default, 86400 maximum)\n"
+ " --[no-]mac-updating: Enable or disable MAC addresses updating (enabled by default)\n"
+ " When enabled:\n"
+ " - The source MAC address is replaced by the TX port MAC address\n"
+ " - The destination MAC address is replaced by 02:00:00:00:00:TX_PORT_ID\n"
+ "\n");
}
static int
--
2.7.4
^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: [dpdk-dev] [PATCH v1 00/15] preparing l2fwd for eventmode additions
2018-06-14 11:48 ` [dpdk-dev] [PATCH v1 00/15] preparing l2fwd for eventmode additions Anoob Joseph
` (14 preceding siblings ...)
2018-06-14 11:49 ` [dpdk-dev] [PATCH v1 15/15] examples/l2fwd: improvements to the " Anoob Joseph
@ 2018-06-19 10:04 ` Anoob Joseph
2018-06-19 10:09 ` Bruce Richardson
2018-07-11 6:07 ` [dpdk-dev] [PATCH v2 00/12] " Anoob Joseph
16 siblings, 1 reply; 83+ messages in thread
From: Anoob Joseph @ 2018-06-19 10:04 UTC (permalink / raw)
To: Bruce Richardson, Pablo de Lara; +Cc: Jerin Jacob, Narayana Prasad, dev
Hi Bruce, Pablo,
Any comments on this series?
Thanks,
Anoob
On 14/06/18 17:18, Anoob Joseph wrote:
> This patchset modularizes l2fwd application to prepare it for eventmode
> additions. This patchset doesn't change the code flow or logic, except
> for few minor improvements. Some of the newly added functions are used
> in just one place, but is added for efficient usage with eventmode.
>
> v1:
> * Fix all checkpatch reported issues
>
> Anoob Joseph (15):
> examples/l2fwd: add new header to move common code
> examples/l2fwd: move macro definitions to common header
> examples/l2fwd: move structure definitions to common header
> examples/l2fwd: move globally accessed vars to common header
> examples/l2fwd: add missing space
> examples/l2fwd: fix lines exceeding 80 char limit
> examples/l2fwd: move dataplane code to new file
> examples/l2fwd: remove unused header includes
> examples/l2fwd: move drain buffers to new function
> examples/l2fwd: optimize check for master core
> examples/l2fwd: move periodic tasks to new function
> examples/l2fwd: skip timer updates for non master cores
> examples/l2fwd: move pkt send code to a new function
> examples/l2fwd: use fprint instead of printf for usage print
> examples/l2fwd: improvements to the usage print
>
> examples/l2fwd/Makefile | 1 +
> examples/l2fwd/l2fwd_common.h | 63 ++++++++++
> examples/l2fwd/l2fwd_worker.c | 249 +++++++++++++++++++++++++++++++++++++
> examples/l2fwd/l2fwd_worker.h | 16 +++
> examples/l2fwd/main.c | 276 ++++++------------------------------------
> 5 files changed, 364 insertions(+), 241 deletions(-)
> create mode 100644 examples/l2fwd/l2fwd_common.h
> create mode 100644 examples/l2fwd/l2fwd_worker.c
> create mode 100644 examples/l2fwd/l2fwd_worker.h
>
^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: [dpdk-dev] [PATCH v1 00/15] preparing l2fwd for eventmode additions
2018-06-19 10:04 ` [dpdk-dev] [PATCH v1 00/15] preparing l2fwd for eventmode additions Anoob Joseph
@ 2018-06-19 10:09 ` Bruce Richardson
2018-06-19 14:07 ` Anoob Joseph
0 siblings, 1 reply; 83+ messages in thread
From: Bruce Richardson @ 2018-06-19 10:09 UTC (permalink / raw)
To: Anoob Joseph; +Cc: Pablo de Lara, Jerin Jacob, Narayana Prasad, dev
On Tue, Jun 19, 2018 at 03:34:29PM +0530, Anoob Joseph wrote:
> Hi Bruce, Pablo,
>
> Any comments on this series?
>
> Thanks,
> Anoob
>
> On 14/06/18 17:18, Anoob Joseph wrote:
> > This patchset modularizes l2fwd application to prepare it for eventmode
> > additions. This patchset doesn't change the code flow or logic, except
> > for few minor improvements. Some of the newly added functions are used
> > in just one place, but is added for efficient usage with eventmode.
> >
> > v1:
> > * Fix all checkpatch reported issues
> >
My main concern here is how much this eventmode addition is going to
complicate the l2fwd example. l2fwd has always been a pretty basic example
app to get users started on the basics of DPDK use, and I'm not sure how
much we want to move away from that. Is this eventmode-l2fwd better being a
separate app, to allow l2fwd to be kept as simple as it can be?
Looking for more thoughts from others here, since it's a community decision
as to the scope of the examples.
/Bruce
^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: [dpdk-dev] [PATCH v1 00/15] preparing l2fwd for eventmode additions
2018-06-19 10:09 ` Bruce Richardson
@ 2018-06-19 14:07 ` Anoob Joseph
2018-07-03 13:16 ` Joseph, Anoob
0 siblings, 1 reply; 83+ messages in thread
From: Anoob Joseph @ 2018-06-19 14:07 UTC (permalink / raw)
To: Bruce Richardson
Cc: Pablo de Lara, Jacob, Jerin, Athreya, Narayana Prasad, dev,
Hemant Agrawal, Nikhil Rao, Sunil Kumar Kori, gage.eads,
harry.van.haaren, narender.vangati, Bhagavatula, Pavan,
Thomas Monjalon, Akhil Goyal
Hi Bruce,
Thanks for the feedback. Please see inline.
+ Hemant, Nikhil, Sunil, Gage, Harry, Narender, Pavan, Thomas, Akhil
On 19/06/18 15:39, Bruce Richardson wrote:
> On Tue, Jun 19, 2018 at 03:34:29PM +0530, Anoob Joseph wrote:
>> Hi Bruce, Pablo,
>>
>> Any comments on this series?
>>
>> Thanks,
>> Anoob
>>
>> On 14/06/18 17:18, Anoob Joseph wrote:
>>> This patchset modularizes l2fwd application to prepare it for eventmode
>>> additions. This patchset doesn't change the code flow or logic, except
>>> for few minor improvements. Some of the newly added functions are used
>>> in just one place, but is added for efficient usage with eventmode.
>>>
>>> v1:
>>> * Fix all checkpatch reported issues
>>>
> My main concern here is how much this eventmode addition is going to
> complicate the l2fwd example. l2fwd has always been a pretty basic example
> app to get users started on the basics of DPDK use, and I'm not sure how
> much we want to move away from that. Is this eventmode-l2fwd better being a
> separate app, to allow l2fwd to be kept as simple as it can be?
>
> Looking for more thoughts from others here, since it's a community decision
> as to the scope of the examples.
>
> /Bruce
The eventmode helper abstracts most of the changes required by the
application to run in eventmode. This was taken up following the
comments on a patch submitted by Sunil(sunil.kori@nxp.com).
http://patches.dpdk.org/patch/37955/
With eventmode helper, an application can be moved to eventmode with
minimal changes. For l2fwd, the key patch which enables eventmode is,
http://patches.dpdk.org/patch/40920/
[The aforementioned patch is dependent on this patch series]
The bulk of the code in this patch(40920) is adding multiple event mode
worker functions.The existing init code and poll mode worker is barely
touched. Multiple workers were introduced because a single event mode
worker would not have made the best use of the varying capabilities of
event devices.
Single event mode worker could've demonstrated how minimal the changes
can be. But the ability to register multiple workers, fine tuned for
varying capabilities, is a good feature to have since it will enable
applications to utilize the full potential of the hardware.
Eventmode helper patch series:
http://patches.dpdk.org/project/dpdk/list/?series=61
The rules that were followed while drafting eventmode helper were very
simple,
1. Move any code common to multiple applications to eventmode helper
2. Expose all capabilities of the devices involved (event & eth devs)
3. Minimize changes to the existing code
For l2fwd we can opt for a new eventmode-l2fwd app, but this might not
work for more complicated apps like l3fwd & ipsec-secgw. L2fwd app will
stay the same even with the eventmode additions. It will still be a
quick-start, easy-to-use app. In addition to demonstrating DPDK, it will
also be able to demonstrate how easily an app can be made to run in
eventmode, using the helper functions.
With more event adapters getting added (tx adapter, crypto adapter,
timer adapter etc), the helper will prove useful in abstracting the
complex configuration options exposed by adapters. Similar changes would
be required in other example apps, and the additions in l2fwd is to
finalize on the approach.
The current patch series just re-factors the code with couple of patches
fixing preexisting checkpatch issues. The rest of the changes are split
into individual patches for ease of review and testing. Hence the large
number of patches.
Thanks,
Anoob
^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: [dpdk-dev] [PATCH v1 00/15] preparing l2fwd for eventmode additions
2018-06-19 14:07 ` Anoob Joseph
@ 2018-07-03 13:16 ` Joseph, Anoob
0 siblings, 0 replies; 83+ messages in thread
From: Joseph, Anoob @ 2018-07-03 13:16 UTC (permalink / raw)
To: Bruce Richardson
Cc: Pablo de Lara, Jacob, Jerin, Athreya, Narayana Prasad, dev,
Hemant Agrawal, Nikhil Rao, Sunil Kumar Kori, gage.eads,
harry.van.haaren, narender.vangati, Bhagavatula, Pavan,
Thomas Monjalon, Akhil Goyal
Hi,
Gentle reminder!
Thanks,
Anoob
On 19-06-2018 19:37, Anoob Joseph wrote:
> External Email
>
> Hi Bruce,
>
>
> Thanks for the feedback. Please see inline.
>
>
> + Hemant, Nikhil, Sunil, Gage, Harry, Narender, Pavan, Thomas, Akhil
>
>
> On 19/06/18 15:39, Bruce Richardson wrote:
>> On Tue, Jun 19, 2018 at 03:34:29PM +0530, Anoob Joseph wrote:
>>> Hi Bruce, Pablo,
>>>
>>> Any comments on this series?
>>>
>>> Thanks,
>>> Anoob
>>>
>>> On 14/06/18 17:18, Anoob Joseph wrote:
>>>> This patchset modularizes l2fwd application to prepare it for
>>>> eventmode
>>>> additions. This patchset doesn't change the code flow or logic, except
>>>> for few minor improvements. Some of the newly added functions are used
>>>> in just one place, but is added for efficient usage with eventmode.
>>>>
>>>> v1:
>>>> * Fix all checkpatch reported issues
>>>>
>> My main concern here is how much this eventmode addition is going to
>> complicate the l2fwd example. l2fwd has always been a pretty basic
>> example
>> app to get users started on the basics of DPDK use, and I'm not sure how
>> much we want to move away from that. Is this eventmode-l2fwd better
>> being a
>> separate app, to allow l2fwd to be kept as simple as it can be?
>>
>> Looking for more thoughts from others here, since it's a community
>> decision
>> as to the scope of the examples.
>>
>> /Bruce
> The eventmode helper abstracts most of the changes required by the
> application to run in eventmode. This was taken up following the
> comments on a patch submitted by Sunil(sunil.kori@nxp.com).
> http://patches.dpdk.org/patch/37955/
>
> With eventmode helper, an application can be moved to eventmode with
> minimal changes. For l2fwd, the key patch which enables eventmode is,
>
> http://patches.dpdk.org/patch/40920/
> [The aforementioned patch is dependent on this patch series]
>
> The bulk of the code in this patch(40920) is adding multiple event mode
> worker functions.The existing init code and poll mode worker is barely
> touched. Multiple workers were introduced because a single event mode
> worker would not have made the best use of the varying capabilities of
> event devices.
>
> Single event mode worker could've demonstrated how minimal the changes
> can be. But the ability to register multiple workers, fine tuned for
> varying capabilities, is a good feature to have since it will enable
> applications to utilize the full potential of the hardware.
>
> Eventmode helper patch series:
> http://patches.dpdk.org/project/dpdk/list/?series=61
>
> The rules that were followed while drafting eventmode helper were very
> simple,
> 1. Move any code common to multiple applications to eventmode helper
> 2. Expose all capabilities of the devices involved (event & eth devs)
> 3. Minimize changes to the existing code
>
> For l2fwd we can opt for a new eventmode-l2fwd app, but this might not
> work for more complicated apps like l3fwd & ipsec-secgw. L2fwd app will
> stay the same even with the eventmode additions. It will still be a
> quick-start, easy-to-use app. In addition to demonstrating DPDK, it will
> also be able to demonstrate how easily an app can be made to run in
> eventmode, using the helper functions.
>
> With more event adapters getting added (tx adapter, crypto adapter,
> timer adapter etc), the helper will prove useful in abstracting the
> complex configuration options exposed by adapters. Similar changes would
> be required in other example apps, and the additions in l2fwd is to
> finalize on the approach.
>
> The current patch series just re-factors the code with couple of patches
> fixing preexisting checkpatch issues. The rest of the changes are split
> into individual patches for ease of review and testing. Hence the large
> number of patches.
>
> Thanks,
> Anoob
^ permalink raw reply [flat|nested] 83+ messages in thread
* [dpdk-dev] [PATCH v2 00/12] preparing l2fwd for eventmode additions
2018-06-14 11:48 ` [dpdk-dev] [PATCH v1 00/15] preparing l2fwd for eventmode additions Anoob Joseph
` (15 preceding siblings ...)
2018-06-19 10:04 ` [dpdk-dev] [PATCH v1 00/15] preparing l2fwd for eventmode additions Anoob Joseph
@ 2018-07-11 6:07 ` Anoob Joseph
2018-07-11 6:07 ` [dpdk-dev] [PATCH v2 01/12] examples/l2fwd: move macro definitions to common header Anoob Joseph
` (11 more replies)
16 siblings, 12 replies; 83+ messages in thread
From: Anoob Joseph @ 2018-07-11 6:07 UTC (permalink / raw)
To: Bruce Richardson, Pablo de Lara
Cc: Anoob Joseph, Jerin Jacob, Narayana Prasad, dev
This patchset modularizes l2fwd application to prepare it for eventmode
additions. This patchset doesn't change the code flow or logic, except
for few minor improvements. Some of the newly added functions are used
in just one place, but is added for efficient usage with eventmode.
v2:
* Merged small patches with others as directed by Pablo
v1:
* Fix all checkpatch reported issues
Anoob Joseph (12):
examples/l2fwd: move macro definitions to common header
examples/l2fwd: move structure definitions to common header
examples/l2fwd: move globally accessed vars to common header
examples/l2fwd: move dataplane code to new file
examples/l2fwd: remove unused header includes
examples/l2fwd: move drain buffers to new function
examples/l2fwd: optimize check for master core
examples/l2fwd: move periodic tasks to new function
examples/l2fwd: skip timer updates for non master cores
examples/l2fwd: move pkt send code to a new function
examples/l2fwd: use fprint instead of printf for usage print
examples/l2fwd: improvements to the usage print
examples/l2fwd/Makefile | 1 +
examples/l2fwd/l2fwd_common.h | 63 ++++++++++
examples/l2fwd/l2fwd_worker.c | 249 +++++++++++++++++++++++++++++++++++++
examples/l2fwd/l2fwd_worker.h | 16 +++
examples/l2fwd/main.c | 276 ++++++------------------------------------
5 files changed, 364 insertions(+), 241 deletions(-)
create mode 100644 examples/l2fwd/l2fwd_common.h
create mode 100644 examples/l2fwd/l2fwd_worker.c
create mode 100644 examples/l2fwd/l2fwd_worker.h
--
2.7.4
^ permalink raw reply [flat|nested] 83+ messages in thread
* [dpdk-dev] [PATCH v2 01/12] examples/l2fwd: move macro definitions to common header
2018-07-11 6:07 ` [dpdk-dev] [PATCH v2 00/12] " Anoob Joseph
@ 2018-07-11 6:07 ` Anoob Joseph
2018-07-11 6:07 ` [dpdk-dev] [PATCH v2 03/12] examples/l2fwd: move globally accessed vars " Anoob Joseph
` (10 subsequent siblings)
11 siblings, 0 replies; 83+ messages in thread
From: Anoob Joseph @ 2018-07-11 6:07 UTC (permalink / raw)
To: Bruce Richardson, Pablo de Lara
Cc: Anoob Joseph, Jerin Jacob, Narayana Prasad, dev
Signed-off-by: Anoob Joseph <anoob.joseph@caviumnetworks.com>
---
v2:
* Merged the patch which was adding the common header
v1:
* Retaining Intel license with copied code
examples/l2fwd/l2fwd_common.h | 25 +++++++++++++++++++++++++
examples/l2fwd/main.c | 16 ++--------------
2 files changed, 27 insertions(+), 14 deletions(-)
create mode 100644 examples/l2fwd/l2fwd_common.h
diff --git a/examples/l2fwd/l2fwd_common.h b/examples/l2fwd/l2fwd_common.h
new file mode 100644
index 0000000..fceb0c3
--- /dev/null
+++ b/examples/l2fwd/l2fwd_common.h
@@ -0,0 +1,25 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2010-2016 Intel Corporation
+ * Copyright(c) 2018 Cavium, Inc
+ */
+#ifndef _L2FWD_COMMON_H_
+#define _L2FWD_COMMON_H_
+
+#define RTE_LOGTYPE_L2FWD RTE_LOGTYPE_USER1
+
+#define MAX_PKT_BURST 32
+#define BURST_TX_DRAIN_US 100 /* TX drain every ~100us */
+#define MEMPOOL_CACHE_SIZE 256
+
+/*
+ * Configurable number of RX/TX ring descriptors
+ */
+#define RTE_TEST_RX_DESC_DEFAULT 1024
+#define RTE_TEST_TX_DESC_DEFAULT 1024
+
+#define MAX_RX_QUEUE_PER_LCORE 16
+#define MAX_TX_QUEUE_PER_PORT 16
+
+#define MAX_TIMER_PERIOD 86400 /* 1 day max */
+
+#endif /* _L2FWD_COMMON_H_ */
diff --git a/examples/l2fwd/main.c b/examples/l2fwd/main.c
index 6908435..9f873c7 100644
--- a/examples/l2fwd/main.c
+++ b/examples/l2fwd/main.c
@@ -39,22 +39,13 @@
#include <rte_mempool.h>
#include <rte_mbuf.h>
+#include "l2fwd_common.h"
+
static volatile bool force_quit;
/* MAC updating enabled by default */
static int mac_updating = 1;
-#define RTE_LOGTYPE_L2FWD RTE_LOGTYPE_USER1
-
-#define MAX_PKT_BURST 32
-#define BURST_TX_DRAIN_US 100 /* TX drain every ~100us */
-#define MEMPOOL_CACHE_SIZE 256
-
-/*
- * Configurable number of RX/TX ring descriptors
- */
-#define RTE_TEST_RX_DESC_DEFAULT 1024
-#define RTE_TEST_TX_DESC_DEFAULT 1024
static uint16_t nb_rxd = RTE_TEST_RX_DESC_DEFAULT;
static uint16_t nb_txd = RTE_TEST_TX_DESC_DEFAULT;
@@ -69,8 +60,6 @@ static uint32_t l2fwd_dst_ports[RTE_MAX_ETHPORTS];
static unsigned int l2fwd_rx_queue_per_lcore = 1;
-#define MAX_RX_QUEUE_PER_LCORE 16
-#define MAX_TX_QUEUE_PER_PORT 16
struct lcore_queue_conf {
unsigned n_rx_port;
unsigned rx_port_list[MAX_RX_QUEUE_PER_LCORE];
@@ -100,7 +89,6 @@ struct l2fwd_port_statistics {
} __rte_cache_aligned;
struct l2fwd_port_statistics port_statistics[RTE_MAX_ETHPORTS];
-#define MAX_TIMER_PERIOD 86400 /* 1 day max */
/* A tsc-based timer responsible for triggering statistics printout */
static uint64_t timer_period = 10; /* default period is 10 seconds */
--
2.7.4
^ permalink raw reply [flat|nested] 83+ messages in thread
* [dpdk-dev] [PATCH v2 03/12] examples/l2fwd: move globally accessed vars to common header
2018-07-11 6:07 ` [dpdk-dev] [PATCH v2 00/12] " Anoob Joseph
2018-07-11 6:07 ` [dpdk-dev] [PATCH v2 01/12] examples/l2fwd: move macro definitions to common header Anoob Joseph
@ 2018-07-11 6:07 ` Anoob Joseph
2018-07-11 6:07 ` [dpdk-dev] [PATCH v2 04/12] examples/l2fwd: move dataplane code to new file Anoob Joseph
` (9 subsequent siblings)
11 siblings, 0 replies; 83+ messages in thread
From: Anoob Joseph @ 2018-07-11 6:07 UTC (permalink / raw)
To: Bruce Richardson, Pablo de Lara
Cc: Anoob Joseph, Jerin Jacob, Narayana Prasad, dev
Signed-off-by: Anoob Joseph <anoob.joseph@caviumnetworks.com>
---
v2:
* No change
v1:
* No change
examples/l2fwd/l2fwd_common.h | 26 ++++++++++++++++++++++++++
examples/l2fwd/main.c | 41 +++++++++++++++++------------------------
2 files changed, 43 insertions(+), 24 deletions(-)
diff --git a/examples/l2fwd/l2fwd_common.h b/examples/l2fwd/l2fwd_common.h
index ca82e29..dd9f268 100644
--- a/examples/l2fwd/l2fwd_common.h
+++ b/examples/l2fwd/l2fwd_common.h
@@ -5,6 +5,10 @@
#ifndef _L2FWD_COMMON_H_
#define _L2FWD_COMMON_H_
+#include <stdbool.h>
+
+#include <rte_common.h>
+
#define RTE_LOGTYPE_L2FWD RTE_LOGTYPE_USER1
#define MAX_PKT_BURST 32
@@ -34,4 +38,26 @@ struct l2fwd_port_statistics {
uint64_t dropped;
} __rte_cache_aligned;
+volatile bool force_quit;
+
+int mac_updating;
+
+/* ethernet addresses of ports */
+struct ether_addr l2fwd_ports_eth_addr[RTE_MAX_ETHPORTS];
+
+/* mask of enabled ports */
+uint32_t l2fwd_enabled_port_mask;
+
+/* list of enabled ports */
+uint32_t l2fwd_dst_ports[RTE_MAX_ETHPORTS];
+
+struct lcore_queue_conf lcore_queue_conf[RTE_MAX_LCORE];
+
+struct rte_eth_dev_tx_buffer *tx_buffer[RTE_MAX_ETHPORTS];
+
+struct l2fwd_port_statistics port_statistics[RTE_MAX_ETHPORTS];
+
+/* A tsc-based timer responsible for triggering statistics printout */
+uint64_t timer_period;
+
#endif /* _L2FWD_COMMON_H_ */
diff --git a/examples/l2fwd/main.c b/examples/l2fwd/main.c
index 11ca170..a6089a1 100644
--- a/examples/l2fwd/main.c
+++ b/examples/l2fwd/main.c
@@ -41,29 +41,11 @@
#include "l2fwd_common.h"
-static volatile bool force_quit;
-
-/* MAC updating enabled by default */
-static int mac_updating = 1;
-
static uint16_t nb_rxd = RTE_TEST_RX_DESC_DEFAULT;
static uint16_t nb_txd = RTE_TEST_TX_DESC_DEFAULT;
-/* ethernet addresses of ports */
-static struct ether_addr l2fwd_ports_eth_addr[RTE_MAX_ETHPORTS];
-
-/* mask of enabled ports */
-static uint32_t l2fwd_enabled_port_mask = 0;
-
-/* list of enabled ports */
-static uint32_t l2fwd_dst_ports[RTE_MAX_ETHPORTS];
-
static unsigned int l2fwd_rx_queue_per_lcore = 1;
-struct lcore_queue_conf lcore_queue_conf[RTE_MAX_LCORE];
-
-static struct rte_eth_dev_tx_buffer *tx_buffer[RTE_MAX_ETHPORTS];
-
static struct rte_eth_conf port_conf = {
.rxmode = {
.split_hdr_size = 0,
@@ -77,11 +59,6 @@ static struct rte_eth_conf port_conf = {
struct rte_mempool * l2fwd_pktmbuf_pool = NULL;
-struct l2fwd_port_statistics port_statistics[RTE_MAX_ETHPORTS];
-
-/* A tsc-based timer responsible for triggering statistics printout */
-static uint64_t timer_period = 10; /* default period is 10 seconds */
-
/* Print out statistics on packets dropped */
static void
print_stats(void)
@@ -489,6 +466,20 @@ signal_handler(int signum)
}
}
+static void
+l2fwd_init_global_vars(void)
+{
+ force_quit = false;
+
+ /* MAC updating enabled by default */
+ mac_updating = 1;
+
+ /* Default period is 10 seconds */
+ timer_period = 10;
+
+ l2fwd_enabled_port_mask = 0;
+}
+
int
main(int argc, char **argv)
{
@@ -502,6 +493,9 @@ main(int argc, char **argv)
unsigned int nb_lcores = 0;
unsigned int nb_mbufs;
+ /* Set default values for global vars */
+ l2fwd_init_global_vars();
+
/* init EAL */
ret = rte_eal_init(argc, argv);
if (ret < 0)
@@ -509,7 +503,6 @@ main(int argc, char **argv)
argc -= ret;
argv += ret;
- force_quit = false;
signal(SIGINT, signal_handler);
signal(SIGTERM, signal_handler);
--
2.7.4
^ permalink raw reply [flat|nested] 83+ messages in thread
* [dpdk-dev] [PATCH v2 04/12] examples/l2fwd: move dataplane code to new file
2018-07-11 6:07 ` [dpdk-dev] [PATCH v2 00/12] " Anoob Joseph
2018-07-11 6:07 ` [dpdk-dev] [PATCH v2 01/12] examples/l2fwd: move macro definitions to common header Anoob Joseph
2018-07-11 6:07 ` [dpdk-dev] [PATCH v2 03/12] examples/l2fwd: move globally accessed vars " Anoob Joseph
@ 2018-07-11 6:07 ` Anoob Joseph
2018-07-11 6:07 ` [dpdk-dev] [PATCH v2 05/12] examples/l2fwd: remove unused header includes Anoob Joseph
` (8 subsequent siblings)
11 siblings, 0 replies; 83+ messages in thread
From: Anoob Joseph @ 2018-07-11 6:07 UTC (permalink / raw)
To: Bruce Richardson, Pablo de Lara
Cc: Anoob Joseph, Jerin Jacob, Narayana Prasad, dev
Signed-off-by: Anoob Joseph <anoob.joseph@caviumnetworks.com>
---
v2:
* Merged checkpatch fix patches
v1:
* Replaced 'unsigned' with 'unsigned int'
examples/l2fwd/Makefile | 1 +
examples/l2fwd/l2fwd_worker.c | 233 ++++++++++++++++++++++++++++++++++++++++++
examples/l2fwd/l2fwd_worker.h | 10 ++
examples/l2fwd/main.c | 186 +--------------------------------
4 files changed, 245 insertions(+), 185 deletions(-)
create mode 100644 examples/l2fwd/l2fwd_worker.c
create mode 100644 examples/l2fwd/l2fwd_worker.h
diff --git a/examples/l2fwd/Makefile b/examples/l2fwd/Makefile
index a8a47ad..24d1e4e 100644
--- a/examples/l2fwd/Makefile
+++ b/examples/l2fwd/Makefile
@@ -6,6 +6,7 @@ APP = l2fwd
# all source are stored in SRCS-y
SRCS-y := main.c
+SRCS-y += l2fwd_worker.c
# Build using pkg-config variables if possible
$(shell pkg-config --exists libdpdk)
diff --git a/examples/l2fwd/l2fwd_worker.c b/examples/l2fwd/l2fwd_worker.c
new file mode 100644
index 0000000..663c505
--- /dev/null
+++ b/examples/l2fwd/l2fwd_worker.c
@@ -0,0 +1,233 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2010-2016 Intel Corporation
+ * Copyright(c) 2018 Cavium, Inc
+ */
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+#include <stdint.h>
+#include <inttypes.h>
+#include <sys/types.h>
+#include <sys/queue.h>
+#include <netinet/in.h>
+#include <setjmp.h>
+#include <stdarg.h>
+#include <ctype.h>
+#include <errno.h>
+#include <getopt.h>
+#include <signal.h>
+#include <stdbool.h>
+
+#include <rte_common.h>
+#include <rte_log.h>
+#include <rte_malloc.h>
+#include <rte_memory.h>
+#include <rte_memcpy.h>
+#include <rte_eal.h>
+#include <rte_launch.h>
+#include <rte_atomic.h>
+#include <rte_cycles.h>
+#include <rte_prefetch.h>
+#include <rte_lcore.h>
+#include <rte_per_lcore.h>
+#include <rte_branch_prediction.h>
+#include <rte_interrupts.h>
+#include <rte_random.h>
+#include <rte_debug.h>
+#include <rte_ether.h>
+#include <rte_ethdev.h>
+#include <rte_mempool.h>
+#include <rte_mbuf.h>
+
+#include "l2fwd_common.h"
+#include "l2fwd_worker.h"
+
+/* Print out statistics on packets dropped */
+static void
+print_stats(void)
+{
+ uint64_t total_packets_dropped, total_packets_tx, total_packets_rx;
+ unsigned int portid;
+
+ total_packets_dropped = 0;
+ total_packets_tx = 0;
+ total_packets_rx = 0;
+
+ const char clr[] = { 27, '[', '2', 'J', '\0' };
+ const char topLeft[] = { 27, '[', '1', ';', '1', 'H', '\0' };
+
+ /* Clear screen and move to top left */
+ printf("%s%s", clr, topLeft);
+
+ printf("\nPort statistics ====================================");
+
+ for (portid = 0; portid < RTE_MAX_ETHPORTS; portid++) {
+ /* skip disabled ports */
+ if ((l2fwd_enabled_port_mask & (1 << portid)) == 0)
+ continue;
+ printf("\nStatistics for port %u ------------------------------"
+ "\nPackets sent: %24"PRIu64
+ "\nPackets received: %20"PRIu64
+ "\nPackets dropped: %21"PRIu64,
+ portid,
+ port_statistics[portid].tx,
+ port_statistics[portid].rx,
+ port_statistics[portid].dropped);
+
+ total_packets_dropped += port_statistics[portid].dropped;
+ total_packets_tx += port_statistics[portid].tx;
+ total_packets_rx += port_statistics[portid].rx;
+ }
+ printf("\nAggregate statistics ==============================="
+ "\nTotal packets sent: %18"PRIu64
+ "\nTotal packets received: %14"PRIu64
+ "\nTotal packets dropped: %15"PRIu64,
+ total_packets_tx,
+ total_packets_rx,
+ total_packets_dropped);
+ printf("\n====================================================\n");
+}
+
+static void
+l2fwd_mac_updating(struct rte_mbuf *m, unsigned int dest_portid)
+{
+ struct ether_hdr *eth;
+ void *tmp;
+
+ eth = rte_pktmbuf_mtod(m, struct ether_hdr *);
+
+ /* 02:00:00:00:00:xx */
+ tmp = ð->d_addr.addr_bytes[0];
+ *((uint64_t *)tmp) = 0x000000000002 + ((uint64_t)dest_portid << 40);
+
+ /* src addr */
+ ether_addr_copy(&l2fwd_ports_eth_addr[dest_portid], ð->s_addr);
+}
+
+static void
+l2fwd_simple_forward(struct rte_mbuf *m, unsigned int portid)
+{
+ unsigned int dst_port;
+ int sent;
+ struct rte_eth_dev_tx_buffer *buffer;
+
+ dst_port = l2fwd_dst_ports[portid];
+
+ if (mac_updating)
+ l2fwd_mac_updating(m, dst_port);
+
+ buffer = tx_buffer[dst_port];
+ sent = rte_eth_tx_buffer(dst_port, 0, buffer, m);
+ if (sent)
+ port_statistics[dst_port].tx += sent;
+}
+
+/* main processing loop */
+static void
+l2fwd_main_loop(void)
+{
+ struct rte_mbuf *pkts_burst[MAX_PKT_BURST];
+ struct rte_mbuf *m;
+ int sent;
+ unsigned int lcore_id;
+ unsigned int master_core_id;
+ uint64_t prev_tsc, diff_tsc, cur_tsc, timer_tsc;
+ unsigned int i, j, portid, nb_rx;
+ struct lcore_queue_conf *qconf;
+ const uint64_t drain_tsc = (rte_get_tsc_hz() + US_PER_S - 1)
+ / US_PER_S * BURST_TX_DRAIN_US;
+ struct rte_eth_dev_tx_buffer *buffer;
+
+ prev_tsc = 0;
+ timer_tsc = 0;
+
+ lcore_id = rte_lcore_id();
+ qconf = &lcore_queue_conf[lcore_id];
+
+ if (qconf->n_rx_port == 0) {
+ RTE_LOG(INFO, L2FWD, "lcore %u has nothing to do\n", lcore_id);
+ return;
+ }
+
+ RTE_LOG(INFO, L2FWD, "entering main loop on lcore %u\n", lcore_id);
+
+ for (i = 0; i < qconf->n_rx_port; i++) {
+
+ portid = qconf->rx_port_list[i];
+ RTE_LOG(INFO, L2FWD, " -- lcoreid=%u portid=%u\n", lcore_id,
+ portid);
+
+ }
+
+ master_core_id = rte_get_master_lcore();
+
+ while (!force_quit) {
+
+ cur_tsc = rte_rdtsc();
+
+ /*
+ * TX burst queue drain
+ */
+ diff_tsc = cur_tsc - prev_tsc;
+ if (unlikely(diff_tsc > drain_tsc)) {
+
+ for (i = 0; i < qconf->n_rx_port; i++) {
+
+ portid =
+ l2fwd_dst_ports[qconf->rx_port_list[i]];
+ buffer = tx_buffer[portid];
+
+ sent = rte_eth_tx_buffer_flush(portid, 0,
+ buffer);
+ if (sent)
+ port_statistics[portid].tx += sent;
+
+ }
+
+ /* if timer is enabled */
+ if (timer_period > 0) {
+
+ /* advance the timer */
+ timer_tsc += diff_tsc;
+
+ /* if timer has reached its timeout */
+ if (unlikely(timer_tsc >= timer_period)) {
+
+ /* do this only on master core */
+ if (lcore_id == master_core_id) {
+ print_stats();
+ /* reset the timer */
+ timer_tsc = 0;
+ }
+ }
+ }
+
+ prev_tsc = cur_tsc;
+ }
+
+ /*
+ * Read packet from RX queues
+ */
+ for (i = 0; i < qconf->n_rx_port; i++) {
+
+ portid = qconf->rx_port_list[i];
+ nb_rx = rte_eth_rx_burst(portid, 0,
+ pkts_burst, MAX_PKT_BURST);
+
+ port_statistics[portid].rx += nb_rx;
+
+ for (j = 0; j < nb_rx; j++) {
+ m = pkts_burst[j];
+ rte_prefetch0(rte_pktmbuf_mtod(m, void *));
+ l2fwd_simple_forward(m, portid);
+ }
+ }
+ }
+}
+
+int
+l2fwd_launch_one_lcore(__attribute__((unused)) void *dummy)
+{
+ l2fwd_main_loop();
+ return 0;
+}
diff --git a/examples/l2fwd/l2fwd_worker.h b/examples/l2fwd/l2fwd_worker.h
new file mode 100644
index 0000000..8971a6a
--- /dev/null
+++ b/examples/l2fwd/l2fwd_worker.h
@@ -0,0 +1,10 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2018 Cavium, Inc
+ */
+#ifndef _L2FWD_WORKER_H_
+#define _L2FWD_WORKER_H_
+
+int
+l2fwd_launch_one_lcore(__attribute__((unused)) void *dummy);
+
+#endif /* _L2FWD_WORKER_H_ */
diff --git a/examples/l2fwd/main.c b/examples/l2fwd/main.c
index a6089a1..05f9d28 100644
--- a/examples/l2fwd/main.c
+++ b/examples/l2fwd/main.c
@@ -40,6 +40,7 @@
#include <rte_mbuf.h>
#include "l2fwd_common.h"
+#include "l2fwd_worker.h"
static uint16_t nb_rxd = RTE_TEST_RX_DESC_DEFAULT;
static uint16_t nb_txd = RTE_TEST_TX_DESC_DEFAULT;
@@ -59,191 +60,6 @@ static struct rte_eth_conf port_conf = {
struct rte_mempool * l2fwd_pktmbuf_pool = NULL;
-/* Print out statistics on packets dropped */
-static void
-print_stats(void)
-{
- uint64_t total_packets_dropped, total_packets_tx, total_packets_rx;
- unsigned portid;
-
- total_packets_dropped = 0;
- total_packets_tx = 0;
- total_packets_rx = 0;
-
- const char clr[] = { 27, '[', '2', 'J', '\0' };
- const char topLeft[] = { 27, '[', '1', ';', '1', 'H','\0' };
-
- /* Clear screen and move to top left */
- printf("%s%s", clr, topLeft);
-
- printf("\nPort statistics ====================================");
-
- for (portid = 0; portid < RTE_MAX_ETHPORTS; portid++) {
- /* skip disabled ports */
- if ((l2fwd_enabled_port_mask & (1 << portid)) == 0)
- continue;
- printf("\nStatistics for port %u ------------------------------"
- "\nPackets sent: %24"PRIu64
- "\nPackets received: %20"PRIu64
- "\nPackets dropped: %21"PRIu64,
- portid,
- port_statistics[portid].tx,
- port_statistics[portid].rx,
- port_statistics[portid].dropped);
-
- total_packets_dropped += port_statistics[portid].dropped;
- total_packets_tx += port_statistics[portid].tx;
- total_packets_rx += port_statistics[portid].rx;
- }
- printf("\nAggregate statistics ==============================="
- "\nTotal packets sent: %18"PRIu64
- "\nTotal packets received: %14"PRIu64
- "\nTotal packets dropped: %15"PRIu64,
- total_packets_tx,
- total_packets_rx,
- total_packets_dropped);
- printf("\n====================================================\n");
-}
-
-static void
-l2fwd_mac_updating(struct rte_mbuf *m, unsigned dest_portid)
-{
- struct ether_hdr *eth;
- void *tmp;
-
- eth = rte_pktmbuf_mtod(m, struct ether_hdr *);
-
- /* 02:00:00:00:00:xx */
- tmp = ð->d_addr.addr_bytes[0];
- *((uint64_t *)tmp) = 0x000000000002 + ((uint64_t)dest_portid << 40);
-
- /* src addr */
- ether_addr_copy(&l2fwd_ports_eth_addr[dest_portid], ð->s_addr);
-}
-
-static void
-l2fwd_simple_forward(struct rte_mbuf *m, unsigned portid)
-{
- unsigned dst_port;
- int sent;
- struct rte_eth_dev_tx_buffer *buffer;
-
- dst_port = l2fwd_dst_ports[portid];
-
- if (mac_updating)
- l2fwd_mac_updating(m, dst_port);
-
- buffer = tx_buffer[dst_port];
- sent = rte_eth_tx_buffer(dst_port, 0, buffer, m);
- if (sent)
- port_statistics[dst_port].tx += sent;
-}
-
-/* main processing loop */
-static void
-l2fwd_main_loop(void)
-{
- struct rte_mbuf *pkts_burst[MAX_PKT_BURST];
- struct rte_mbuf *m;
- int sent;
- unsigned lcore_id;
- uint64_t prev_tsc, diff_tsc, cur_tsc, timer_tsc;
- unsigned i, j, portid, nb_rx;
- struct lcore_queue_conf *qconf;
- const uint64_t drain_tsc = (rte_get_tsc_hz() + US_PER_S - 1) / US_PER_S *
- BURST_TX_DRAIN_US;
- struct rte_eth_dev_tx_buffer *buffer;
-
- prev_tsc = 0;
- timer_tsc = 0;
-
- lcore_id = rte_lcore_id();
- qconf = &lcore_queue_conf[lcore_id];
-
- if (qconf->n_rx_port == 0) {
- RTE_LOG(INFO, L2FWD, "lcore %u has nothing to do\n", lcore_id);
- return;
- }
-
- RTE_LOG(INFO, L2FWD, "entering main loop on lcore %u\n", lcore_id);
-
- for (i = 0; i < qconf->n_rx_port; i++) {
-
- portid = qconf->rx_port_list[i];
- RTE_LOG(INFO, L2FWD, " -- lcoreid=%u portid=%u\n", lcore_id,
- portid);
-
- }
-
- while (!force_quit) {
-
- cur_tsc = rte_rdtsc();
-
- /*
- * TX burst queue drain
- */
- diff_tsc = cur_tsc - prev_tsc;
- if (unlikely(diff_tsc > drain_tsc)) {
-
- for (i = 0; i < qconf->n_rx_port; i++) {
-
- portid = l2fwd_dst_ports[qconf->rx_port_list[i]];
- buffer = tx_buffer[portid];
-
- sent = rte_eth_tx_buffer_flush(portid, 0, buffer);
- if (sent)
- port_statistics[portid].tx += sent;
-
- }
-
- /* if timer is enabled */
- if (timer_period > 0) {
-
- /* advance the timer */
- timer_tsc += diff_tsc;
-
- /* if timer has reached its timeout */
- if (unlikely(timer_tsc >= timer_period)) {
-
- /* do this only on master core */
- if (lcore_id == rte_get_master_lcore()) {
- print_stats();
- /* reset the timer */
- timer_tsc = 0;
- }
- }
- }
-
- prev_tsc = cur_tsc;
- }
-
- /*
- * Read packet from RX queues
- */
- for (i = 0; i < qconf->n_rx_port; i++) {
-
- portid = qconf->rx_port_list[i];
- nb_rx = rte_eth_rx_burst(portid, 0,
- pkts_burst, MAX_PKT_BURST);
-
- port_statistics[portid].rx += nb_rx;
-
- for (j = 0; j < nb_rx; j++) {
- m = pkts_burst[j];
- rte_prefetch0(rte_pktmbuf_mtod(m, void *));
- l2fwd_simple_forward(m, portid);
- }
- }
- }
-}
-
-static int
-l2fwd_launch_one_lcore(__attribute__((unused)) void *dummy)
-{
- l2fwd_main_loop();
- return 0;
-}
-
/* display usage */
static void
l2fwd_usage(const char *prgname)
--
2.7.4
^ permalink raw reply [flat|nested] 83+ messages in thread
* [dpdk-dev] [PATCH v2 05/12] examples/l2fwd: remove unused header includes
2018-07-11 6:07 ` [dpdk-dev] [PATCH v2 00/12] " Anoob Joseph
` (2 preceding siblings ...)
2018-07-11 6:07 ` [dpdk-dev] [PATCH v2 04/12] examples/l2fwd: move dataplane code to new file Anoob Joseph
@ 2018-07-11 6:07 ` Anoob Joseph
2018-07-11 6:07 ` [dpdk-dev] [PATCH v2 06/12] examples/l2fwd: move drain buffers to new function Anoob Joseph
` (7 subsequent siblings)
11 siblings, 0 replies; 83+ messages in thread
From: Anoob Joseph @ 2018-07-11 6:07 UTC (permalink / raw)
To: Bruce Richardson, Pablo de Lara
Cc: Anoob Joseph, Jerin Jacob, Narayana Prasad, dev
Signed-off-by: Anoob Joseph <anoob.joseph@caviumnetworks.com>
---
v2:
* No change
v1:
* No change
examples/l2fwd/l2fwd_worker.c | 12 ------------
1 file changed, 12 deletions(-)
diff --git a/examples/l2fwd/l2fwd_worker.c b/examples/l2fwd/l2fwd_worker.c
index 663c505..ad5468a 100644
--- a/examples/l2fwd/l2fwd_worker.c
+++ b/examples/l2fwd/l2fwd_worker.c
@@ -13,30 +13,18 @@
#include <setjmp.h>
#include <stdarg.h>
#include <ctype.h>
-#include <errno.h>
-#include <getopt.h>
-#include <signal.h>
#include <stdbool.h>
#include <rte_common.h>
#include <rte_log.h>
-#include <rte_malloc.h>
-#include <rte_memory.h>
#include <rte_memcpy.h>
-#include <rte_eal.h>
-#include <rte_launch.h>
#include <rte_atomic.h>
#include <rte_cycles.h>
#include <rte_prefetch.h>
#include <rte_lcore.h>
-#include <rte_per_lcore.h>
#include <rte_branch_prediction.h>
-#include <rte_interrupts.h>
-#include <rte_random.h>
-#include <rte_debug.h>
#include <rte_ether.h>
#include <rte_ethdev.h>
-#include <rte_mempool.h>
#include <rte_mbuf.h>
#include "l2fwd_common.h"
--
2.7.4
^ permalink raw reply [flat|nested] 83+ messages in thread
* [dpdk-dev] [PATCH v2 06/12] examples/l2fwd: move drain buffers to new function
2018-07-11 6:07 ` [dpdk-dev] [PATCH v2 00/12] " Anoob Joseph
` (3 preceding siblings ...)
2018-07-11 6:07 ` [dpdk-dev] [PATCH v2 05/12] examples/l2fwd: remove unused header includes Anoob Joseph
@ 2018-07-11 6:07 ` Anoob Joseph
2018-07-11 6:07 ` [dpdk-dev] [PATCH v2 07/12] examples/l2fwd: optimize check for master core Anoob Joseph
` (6 subsequent siblings)
11 siblings, 0 replies; 83+ messages in thread
From: Anoob Joseph @ 2018-07-11 6:07 UTC (permalink / raw)
To: Bruce Richardson, Pablo de Lara
Cc: Anoob Joseph, Jerin Jacob, Narayana Prasad, dev
Signed-off-by: Anoob Joseph <anoob.joseph@caviumnetworks.com>
---
v2:
* No change
v1:
* Replaced 'unsigned' with 'unsigned int'
examples/l2fwd/l2fwd_worker.c | 34 ++++++++++++++++++++--------------
1 file changed, 20 insertions(+), 14 deletions(-)
diff --git a/examples/l2fwd/l2fwd_worker.c b/examples/l2fwd/l2fwd_worker.c
index ad5468a..dfa78ed 100644
--- a/examples/l2fwd/l2fwd_worker.c
+++ b/examples/l2fwd/l2fwd_worker.c
@@ -76,6 +76,24 @@ print_stats(void)
printf("\n====================================================\n");
}
+static inline void
+l2fwd_drain_buffers(struct lcore_queue_conf *qconf)
+{
+ unsigned int i, sent;
+ unsigned int portid;
+ struct rte_eth_dev_tx_buffer *buffer;
+
+ for (i = 0; i < qconf->n_rx_port; i++) {
+
+ portid = l2fwd_dst_ports[qconf->rx_port_list[i]];
+ buffer = tx_buffer[portid];
+
+ sent = rte_eth_tx_buffer_flush(portid, 0, buffer);
+ if (sent)
+ port_statistics[portid].tx += sent;
+ }
+}
+
static void
l2fwd_mac_updating(struct rte_mbuf *m, unsigned int dest_portid)
{
@@ -116,7 +134,6 @@ l2fwd_main_loop(void)
{
struct rte_mbuf *pkts_burst[MAX_PKT_BURST];
struct rte_mbuf *m;
- int sent;
unsigned int lcore_id;
unsigned int master_core_id;
uint64_t prev_tsc, diff_tsc, cur_tsc, timer_tsc;
@@ -124,7 +141,6 @@ l2fwd_main_loop(void)
struct lcore_queue_conf *qconf;
const uint64_t drain_tsc = (rte_get_tsc_hz() + US_PER_S - 1)
/ US_PER_S * BURST_TX_DRAIN_US;
- struct rte_eth_dev_tx_buffer *buffer;
prev_tsc = 0;
timer_tsc = 0;
@@ -159,18 +175,8 @@ l2fwd_main_loop(void)
diff_tsc = cur_tsc - prev_tsc;
if (unlikely(diff_tsc > drain_tsc)) {
- for (i = 0; i < qconf->n_rx_port; i++) {
-
- portid =
- l2fwd_dst_ports[qconf->rx_port_list[i]];
- buffer = tx_buffer[portid];
-
- sent = rte_eth_tx_buffer_flush(portid, 0,
- buffer);
- if (sent)
- port_statistics[portid].tx += sent;
-
- }
+ /* Drain buffers */
+ l2fwd_drain_buffers(qconf);
/* if timer is enabled */
if (timer_period > 0) {
--
2.7.4
^ permalink raw reply [flat|nested] 83+ messages in thread
* [dpdk-dev] [PATCH v2 07/12] examples/l2fwd: optimize check for master core
2018-07-11 6:07 ` [dpdk-dev] [PATCH v2 00/12] " Anoob Joseph
` (4 preceding siblings ...)
2018-07-11 6:07 ` [dpdk-dev] [PATCH v2 06/12] examples/l2fwd: move drain buffers to new function Anoob Joseph
@ 2018-07-11 6:07 ` Anoob Joseph
2018-07-11 6:07 ` [dpdk-dev] [PATCH v2 08/12] examples/l2fwd: move periodic tasks to new function Anoob Joseph
` (5 subsequent siblings)
11 siblings, 0 replies; 83+ messages in thread
From: Anoob Joseph @ 2018-07-11 6:07 UTC (permalink / raw)
To: Bruce Richardson, Pablo de Lara
Cc: Anoob Joseph, Jerin Jacob, Narayana Prasad, dev
Replacing the check for lcore_id & mastercore_id with the check for a
flag.
Signed-off-by: Anoob Joseph <anoob.joseph@caviumnetworks.com>
---
v2:
* No change
v1:
* Replaced 'unsigned' with 'unsigned int'
examples/l2fwd/l2fwd_worker.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/examples/l2fwd/l2fwd_worker.c b/examples/l2fwd/l2fwd_worker.c
index dfa78ed..f847832 100644
--- a/examples/l2fwd/l2fwd_worker.c
+++ b/examples/l2fwd/l2fwd_worker.c
@@ -135,12 +135,12 @@ l2fwd_main_loop(void)
struct rte_mbuf *pkts_burst[MAX_PKT_BURST];
struct rte_mbuf *m;
unsigned int lcore_id;
- unsigned int master_core_id;
uint64_t prev_tsc, diff_tsc, cur_tsc, timer_tsc;
unsigned int i, j, portid, nb_rx;
struct lcore_queue_conf *qconf;
const uint64_t drain_tsc = (rte_get_tsc_hz() + US_PER_S - 1)
/ US_PER_S * BURST_TX_DRAIN_US;
+ int is_master_core;
prev_tsc = 0;
timer_tsc = 0;
@@ -162,8 +162,8 @@ l2fwd_main_loop(void)
portid);
}
-
- master_core_id = rte_get_master_lcore();
+ /* Set the flag if master core */
+ is_master_core = (lcore_id == rte_get_master_lcore()) ? 1 : 0;
while (!force_quit) {
@@ -188,7 +188,7 @@ l2fwd_main_loop(void)
if (unlikely(timer_tsc >= timer_period)) {
/* do this only on master core */
- if (lcore_id == master_core_id) {
+ if (is_master_core) {
print_stats();
/* reset the timer */
timer_tsc = 0;
--
2.7.4
^ permalink raw reply [flat|nested] 83+ messages in thread
* [dpdk-dev] [PATCH v2 08/12] examples/l2fwd: move periodic tasks to new function
2018-07-11 6:07 ` [dpdk-dev] [PATCH v2 00/12] " Anoob Joseph
` (5 preceding siblings ...)
2018-07-11 6:07 ` [dpdk-dev] [PATCH v2 07/12] examples/l2fwd: optimize check for master core Anoob Joseph
@ 2018-07-11 6:07 ` Anoob Joseph
2018-07-11 6:07 ` [dpdk-dev] [PATCH v2 09/12] examples/l2fwd: skip timer updates for non master cores Anoob Joseph
` (4 subsequent siblings)
11 siblings, 0 replies; 83+ messages in thread
From: Anoob Joseph @ 2018-07-11 6:07 UTC (permalink / raw)
To: Bruce Richardson, Pablo de Lara
Cc: Anoob Joseph, Jerin Jacob, Narayana Prasad, dev
Move the periodic operations (stats flush and drain buffers) to a new
function.
Signed-off-by: Anoob Joseph <anoob.joseph@caviumnetworks.com>
---
v2:
* No change
v1:
* Replaced 'unsigned' with 'unsigned int'
examples/l2fwd/l2fwd_worker.c | 83 ++++++++++++++++++++++++-------------------
examples/l2fwd/l2fwd_worker.h | 6 ++++
2 files changed, 52 insertions(+), 37 deletions(-)
diff --git a/examples/l2fwd/l2fwd_worker.c b/examples/l2fwd/l2fwd_worker.c
index f847832..868d0c6 100644
--- a/examples/l2fwd/l2fwd_worker.c
+++ b/examples/l2fwd/l2fwd_worker.c
@@ -94,6 +94,45 @@ l2fwd_drain_buffers(struct lcore_queue_conf *qconf)
}
}
+static inline void
+l2fwd_periodic_drain_stats_monitor(struct lcore_queue_conf *qconf,
+ struct tsc_tracker *t, int is_master_core)
+{
+ uint64_t diff_tsc, cur_tsc;
+
+ cur_tsc = rte_rdtsc();
+
+ /*
+ * TX burst queue drain
+ */
+ diff_tsc = cur_tsc - t->prev_tsc;
+ if (unlikely(diff_tsc > t->drain_tsc)) {
+
+ /* Drain buffers */
+ l2fwd_drain_buffers(qconf);
+
+ /* if timer is enabled */
+ if (timer_period > 0) {
+
+ /* advance the timer */
+ t->timer_tsc += diff_tsc;
+
+ /* if timer has reached its timeout */
+ if (unlikely(t->timer_tsc >= timer_period)) {
+
+ /* do this only on master core */
+ if (is_master_core) {
+ print_stats();
+ /* reset the timer */
+ t->timer_tsc = 0;
+ }
+ }
+ }
+
+ t->prev_tsc = cur_tsc;
+ }
+}
+
static void
l2fwd_mac_updating(struct rte_mbuf *m, unsigned int dest_portid)
{
@@ -135,19 +174,18 @@ l2fwd_main_loop(void)
struct rte_mbuf *pkts_burst[MAX_PKT_BURST];
struct rte_mbuf *m;
unsigned int lcore_id;
- uint64_t prev_tsc, diff_tsc, cur_tsc, timer_tsc;
unsigned int i, j, portid, nb_rx;
struct lcore_queue_conf *qconf;
- const uint64_t drain_tsc = (rte_get_tsc_hz() + US_PER_S - 1)
- / US_PER_S * BURST_TX_DRAIN_US;
int is_master_core;
-
- prev_tsc = 0;
- timer_tsc = 0;
+ struct tsc_tracker tsc = {0};
lcore_id = rte_lcore_id();
qconf = &lcore_queue_conf[lcore_id];
+ /* Set drain tsc */
+ tsc.drain_tsc = (rte_get_tsc_hz() + US_PER_S - 1) /
+ US_PER_S * BURST_TX_DRAIN_US;
+
if (qconf->n_rx_port == 0) {
RTE_LOG(INFO, L2FWD, "lcore %u has nothing to do\n", lcore_id);
return;
@@ -167,37 +205,8 @@ l2fwd_main_loop(void)
while (!force_quit) {
- cur_tsc = rte_rdtsc();
-
- /*
- * TX burst queue drain
- */
- diff_tsc = cur_tsc - prev_tsc;
- if (unlikely(diff_tsc > drain_tsc)) {
-
- /* Drain buffers */
- l2fwd_drain_buffers(qconf);
-
- /* if timer is enabled */
- if (timer_period > 0) {
-
- /* advance the timer */
- timer_tsc += diff_tsc;
-
- /* if timer has reached its timeout */
- if (unlikely(timer_tsc >= timer_period)) {
-
- /* do this only on master core */
- if (is_master_core) {
- print_stats();
- /* reset the timer */
- timer_tsc = 0;
- }
- }
- }
-
- prev_tsc = cur_tsc;
- }
+ /* Do periodic operations (buffer drain & stats monitor) */
+ l2fwd_periodic_drain_stats_monitor(qconf, &tsc, is_master_core);
/*
* Read packet from RX queues
diff --git a/examples/l2fwd/l2fwd_worker.h b/examples/l2fwd/l2fwd_worker.h
index 8971a6a..65650aa 100644
--- a/examples/l2fwd/l2fwd_worker.h
+++ b/examples/l2fwd/l2fwd_worker.h
@@ -4,6 +4,12 @@
#ifndef _L2FWD_WORKER_H_
#define _L2FWD_WORKER_H_
+struct tsc_tracker {
+ uint64_t prev_tsc;
+ uint64_t timer_tsc;
+ uint64_t drain_tsc;
+};
+
int
l2fwd_launch_one_lcore(__attribute__((unused)) void *dummy);
--
2.7.4
^ permalink raw reply [flat|nested] 83+ messages in thread
* [dpdk-dev] [PATCH v2 09/12] examples/l2fwd: skip timer updates for non master cores
2018-07-11 6:07 ` [dpdk-dev] [PATCH v2 00/12] " Anoob Joseph
` (6 preceding siblings ...)
2018-07-11 6:07 ` [dpdk-dev] [PATCH v2 08/12] examples/l2fwd: move periodic tasks to new function Anoob Joseph
@ 2018-07-11 6:07 ` Anoob Joseph
2018-07-11 6:07 ` [dpdk-dev] [PATCH v2 10/12] examples/l2fwd: move pkt send code to a new function Anoob Joseph
` (3 subsequent siblings)
11 siblings, 0 replies; 83+ messages in thread
From: Anoob Joseph @ 2018-07-11 6:07 UTC (permalink / raw)
To: Bruce Richardson, Pablo de Lara
Cc: Anoob Joseph, Jerin Jacob, Narayana Prasad, dev
The timer updates and checks are required only for stats printing by the
master core. This can be entirely skipped for other cores.
Signed-off-by: Anoob Joseph <anoob.joseph@caviumnetworks.com>
---
v2:
* No change
v1:
* No change
examples/l2fwd/l2fwd_worker.c | 21 +++++++++++++--------
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/examples/l2fwd/l2fwd_worker.c b/examples/l2fwd/l2fwd_worker.c
index 868d0c6..d6a5e90 100644
--- a/examples/l2fwd/l2fwd_worker.c
+++ b/examples/l2fwd/l2fwd_worker.c
@@ -111,6 +111,14 @@ l2fwd_periodic_drain_stats_monitor(struct lcore_queue_conf *qconf,
/* Drain buffers */
l2fwd_drain_buffers(qconf);
+ t->prev_tsc = cur_tsc;
+
+ /* Skip the timer based stats prints if not master core */
+ if (!is_master_core)
+ return;
+
+ /* On master core */
+
/* if timer is enabled */
if (timer_period > 0) {
@@ -120,16 +128,13 @@ l2fwd_periodic_drain_stats_monitor(struct lcore_queue_conf *qconf,
/* if timer has reached its timeout */
if (unlikely(t->timer_tsc >= timer_period)) {
- /* do this only on master core */
- if (is_master_core) {
- print_stats();
- /* reset the timer */
- t->timer_tsc = 0;
- }
+ /* Print stats */
+ print_stats();
+
+ /* reset the timer */
+ t->timer_tsc = 0;
}
}
-
- t->prev_tsc = cur_tsc;
}
}
--
2.7.4
^ permalink raw reply [flat|nested] 83+ messages in thread
* [dpdk-dev] [PATCH v2 10/12] examples/l2fwd: move pkt send code to a new function
2018-07-11 6:07 ` [dpdk-dev] [PATCH v2 00/12] " Anoob Joseph
` (7 preceding siblings ...)
2018-07-11 6:07 ` [dpdk-dev] [PATCH v2 09/12] examples/l2fwd: skip timer updates for non master cores Anoob Joseph
@ 2018-07-11 6:07 ` Anoob Joseph
2018-07-11 6:07 ` [dpdk-dev] [PATCH v2 11/12] examples/l2fwd: use fprint instead of printf for usage print Anoob Joseph
` (2 subsequent siblings)
11 siblings, 0 replies; 83+ messages in thread
From: Anoob Joseph @ 2018-07-11 6:07 UTC (permalink / raw)
To: Bruce Richardson, Pablo de Lara
Cc: Anoob Joseph, Jerin Jacob, Narayana Prasad, dev
Signed-off-by: Anoob Joseph <anoob.joseph@caviumnetworks.com>
---
v2:
* No change
v1:
* Replaced 'unsigned' with 'unsigned int'
examples/l2fwd/l2fwd_worker.c | 20 ++++++++++++++------
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/examples/l2fwd/l2fwd_worker.c b/examples/l2fwd/l2fwd_worker.c
index d6a5e90..bac1946 100644
--- a/examples/l2fwd/l2fwd_worker.c
+++ b/examples/l2fwd/l2fwd_worker.c
@@ -154,22 +154,30 @@ l2fwd_mac_updating(struct rte_mbuf *m, unsigned int dest_portid)
ether_addr_copy(&l2fwd_ports_eth_addr[dest_portid], ð->s_addr);
}
+static inline void
+l2fwd_send_pkt(struct rte_mbuf *tx_pkt, unsigned int port_id)
+{
+ int sent;
+ struct rte_eth_dev_tx_buffer *buffer;
+
+ buffer = tx_buffer[port_id];
+ sent = rte_eth_tx_buffer(port_id, 0, buffer, tx_pkt);
+ if (sent)
+ port_statistics[port_id].tx += sent;
+}
+
static void
l2fwd_simple_forward(struct rte_mbuf *m, unsigned int portid)
{
unsigned int dst_port;
- int sent;
- struct rte_eth_dev_tx_buffer *buffer;
dst_port = l2fwd_dst_ports[portid];
if (mac_updating)
l2fwd_mac_updating(m, dst_port);
- buffer = tx_buffer[dst_port];
- sent = rte_eth_tx_buffer(dst_port, 0, buffer, m);
- if (sent)
- port_statistics[dst_port].tx += sent;
+ /* Send packet */
+ l2fwd_send_pkt(m, dst_port);
}
/* main processing loop */
--
2.7.4
^ permalink raw reply [flat|nested] 83+ messages in thread
* [dpdk-dev] [PATCH v2 11/12] examples/l2fwd: use fprint instead of printf for usage print
2018-07-11 6:07 ` [dpdk-dev] [PATCH v2 00/12] " Anoob Joseph
` (8 preceding siblings ...)
2018-07-11 6:07 ` [dpdk-dev] [PATCH v2 10/12] examples/l2fwd: move pkt send code to a new function Anoob Joseph
@ 2018-07-11 6:07 ` Anoob Joseph
2018-07-11 6:07 ` [dpdk-dev] [PATCH v2 12/12] examples/l2fwd: improvements to the " Anoob Joseph
2018-07-26 16:57 ` [dpdk-dev] [PATCH v2 00/12] preparing l2fwd for eventmode additions Thomas Monjalon
11 siblings, 0 replies; 83+ messages in thread
From: Anoob Joseph @ 2018-07-11 6:07 UTC (permalink / raw)
To: Bruce Richardson, Pablo de Lara
Cc: Anoob Joseph, Jerin Jacob, Narayana Prasad, dev
Following the convention of l3fwd, using fprintf instead of printf for
printing usage.
Signed-off-by: Anoob Joseph <anoob.joseph@caviumnetworks.com>
---
v2:
* No change
v1:
* No change
examples/l2fwd/main.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/examples/l2fwd/main.c b/examples/l2fwd/main.c
index 05f9d28..3b697d1 100644
--- a/examples/l2fwd/main.c
+++ b/examples/l2fwd/main.c
@@ -64,7 +64,9 @@ struct rte_mempool * l2fwd_pktmbuf_pool = NULL;
static void
l2fwd_usage(const char *prgname)
{
- printf("%s [EAL options] -- -p PORTMASK [-q NQ]\n"
+ fprintf(stderr, "%s [EAL options] --"
+ " -p PORTMASK"
+ " [-q NQ]\n"
" -p PORTMASK: hexadecimal bitmask of ports to configure\n"
" -q NQ: number of queue (=ports) per lcore (default is 1)\n"
" -T PERIOD: statistics will be refreshed each PERIOD seconds (0 to disable, 10 default, 86400 maximum)\n"
--
2.7.4
^ permalink raw reply [flat|nested] 83+ messages in thread
* [dpdk-dev] [PATCH v2 12/12] examples/l2fwd: improvements to the usage print
2018-07-11 6:07 ` [dpdk-dev] [PATCH v2 00/12] " Anoob Joseph
` (9 preceding siblings ...)
2018-07-11 6:07 ` [dpdk-dev] [PATCH v2 11/12] examples/l2fwd: use fprint instead of printf for usage print Anoob Joseph
@ 2018-07-11 6:07 ` Anoob Joseph
2018-07-26 16:57 ` [dpdk-dev] [PATCH v2 00/12] preparing l2fwd for eventmode additions Thomas Monjalon
11 siblings, 0 replies; 83+ messages in thread
From: Anoob Joseph @ 2018-07-11 6:07 UTC (permalink / raw)
To: Bruce Richardson, Pablo de Lara
Cc: Anoob Joseph, Jerin Jacob, Narayana Prasad, dev
Fixed alignment and split the usage print to aid easy addition of
eventmode usage prints.
Signed-off-by: Anoob Joseph <anoob.joseph@caviumnetworks.com>
---
v2:
* No change
v1:
* No change
examples/l2fwd/main.c | 23 ++++++++++++++---------
1 file changed, 14 insertions(+), 9 deletions(-)
diff --git a/examples/l2fwd/main.c b/examples/l2fwd/main.c
index 3b697d1..ac81beb 100644
--- a/examples/l2fwd/main.c
+++ b/examples/l2fwd/main.c
@@ -66,15 +66,20 @@ l2fwd_usage(const char *prgname)
{
fprintf(stderr, "%s [EAL options] --"
" -p PORTMASK"
- " [-q NQ]\n"
- " -p PORTMASK: hexadecimal bitmask of ports to configure\n"
- " -q NQ: number of queue (=ports) per lcore (default is 1)\n"
- " -T PERIOD: statistics will be refreshed each PERIOD seconds (0 to disable, 10 default, 86400 maximum)\n"
- " --[no-]mac-updating: Enable or disable MAC addresses updating (enabled by default)\n"
- " When enabled:\n"
- " - The source MAC address is replaced by the TX port MAC address\n"
- " - The destination MAC address is replaced by 02:00:00:00:00:TX_PORT_ID\n",
- prgname);
+ " [-q NQ]",
+ prgname);
+
+ fprintf(stderr, "\n\n");
+
+ fprintf(stderr,
+ " -p PORTMASK: hexadecimal bitmask of ports to configure\n"
+ " -q NQ: number of queue (=ports) per lcore (default is 1)\n"
+ " -T PERIOD: statistics will be refreshed each PERIOD seconds (0 to disable, 10 default, 86400 maximum)\n"
+ " --[no-]mac-updating: Enable or disable MAC addresses updating (enabled by default)\n"
+ " When enabled:\n"
+ " - The source MAC address is replaced by the TX port MAC address\n"
+ " - The destination MAC address is replaced by 02:00:00:00:00:TX_PORT_ID\n"
+ "\n");
}
static int
--
2.7.4
^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: [dpdk-dev] [PATCH v2 00/12] preparing l2fwd for eventmode additions
2018-07-11 6:07 ` [dpdk-dev] [PATCH v2 00/12] " Anoob Joseph
` (10 preceding siblings ...)
2018-07-11 6:07 ` [dpdk-dev] [PATCH v2 12/12] examples/l2fwd: improvements to the " Anoob Joseph
@ 2018-07-26 16:57 ` Thomas Monjalon
2018-08-01 6:59 ` Joseph, Anoob
11 siblings, 1 reply; 83+ messages in thread
From: Thomas Monjalon @ 2018-07-26 16:57 UTC (permalink / raw)
To: Anoob Joseph
Cc: dev, Bruce Richardson, Pablo de Lara, Jerin Jacob, Narayana Prasad
> Anoob Joseph (12):
> examples/l2fwd: move macro definitions to common header
> examples/l2fwd: move structure definitions to common header
> examples/l2fwd: move globally accessed vars to common header
> examples/l2fwd: move dataplane code to new file
> examples/l2fwd: remove unused header includes
> examples/l2fwd: move drain buffers to new function
> examples/l2fwd: optimize check for master core
> examples/l2fwd: move periodic tasks to new function
> examples/l2fwd: skip timer updates for non master cores
> examples/l2fwd: move pkt send code to a new function
> examples/l2fwd: use fprint instead of printf for usage print
> examples/l2fwd: improvements to the usage print
Maintainers of this app look to be against adding complexity.
In order to get this series accepted, we need more discussions
with more people involved.
So it will miss 18.08.
It can be discussed in a more global discussion about examples maintenance.
If discussion does not happen, you can request it to the technical board.
^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: [dpdk-dev] [PATCH v2 00/12] preparing l2fwd for eventmode additions
2018-07-26 16:57 ` [dpdk-dev] [PATCH v2 00/12] preparing l2fwd for eventmode additions Thomas Monjalon
@ 2018-08-01 6:59 ` Joseph, Anoob
2018-08-01 16:54 ` Stephen Hemminger
0 siblings, 1 reply; 83+ messages in thread
From: Joseph, Anoob @ 2018-08-01 6:59 UTC (permalink / raw)
To: Thomas Monjalon
Cc: dev, Bruce Richardson, Pablo de Lara, Jerin Jacob,
Narayana Prasad, Hemant Agrawal, Ananyev, Konstantin,
Sunil Kumar Kori, Nikhil Rao
Hi Thomas,
On 26-07-2018 22:27, Thomas Monjalon wrote:
> External Email
>
>> Anoob Joseph (12):
>> examples/l2fwd: move macro definitions to common header
>> examples/l2fwd: move structure definitions to common header
>> examples/l2fwd: move globally accessed vars to common header
>> examples/l2fwd: move dataplane code to new file
>> examples/l2fwd: remove unused header includes
>> examples/l2fwd: move drain buffers to new function
>> examples/l2fwd: optimize check for master core
>> examples/l2fwd: move periodic tasks to new function
>> examples/l2fwd: skip timer updates for non master cores
>> examples/l2fwd: move pkt send code to a new function
>> examples/l2fwd: use fprint instead of printf for usage print
>> examples/l2fwd: improvements to the usage print
> Maintainers of this app look to be against adding complexity.
>
> In order to get this series accepted, we need more discussions
> with more people involved.
> So it will miss 18.08.
>
> It can be discussed in a more global discussion about examples maintenance.
> If discussion does not happen, you can request it to the technical board.
>
Event dev framework and various adapters enable multiple packet handling
schemes, as opposed to the traditional polling on queues. But these
features are not integrated into any established example application.
There are specific example applications for event dev etc, which can be
used to analyze an event device or a particular eventdev adapter, but
there is no standard application which can be used to compare the real
world performance for a system when it's using event device for packet
handling and when it's done via polling on queues.
The following patch submitted by Sunil was looking to address this issue
with l3fwd,
https://mails.dpdk.org/archives/dev/2018-March/093131.html
Bruce & Jerin reviewed the patch and suggested the addition of helper
functions to abstract the event mode additions in applications,
https://mails.dpdk.org/archives/dev/2018-April/096879.html
This effort of adding helper functions for eventmode was taken up
following the above suggestion. The idea is to add eventmode without
touching the existing code path. All the eventmode specific additions
would go into library so that these need not be repeated for every
application. And since there is no change in the existing code path,
performance for any vendor should not have any impact with the additions.
The scope of this effort has increased since the submission, as now we
have Tx adapter as well. Sunil & Konstantin had clarified their
concerns, and gave green flag to this approach.
https://mails.dpdk.org/archives/dev/2018-June/105730.html
https://mails.dpdk.org/archives/dev/2018-July/106453.html
I guess Bruce was opening this question to the community. For compute
intense applications like ipsec-secgw, eventmode might be the right
approach in the first place. Such complex applications would need a
scheduler to perform dynamic load balancing. Addition of eventmode in
l2fwd was to float around the idea which can then be scaled for more
complex applications.
If maintainers doesn't have any objection to this, I'm fine with adding
this in the next release.
Thanks,
Anoob
^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: [dpdk-dev] [PATCH v2 00/12] preparing l2fwd for eventmode additions
2018-08-01 6:59 ` Joseph, Anoob
@ 2018-08-01 16:54 ` Stephen Hemminger
2018-08-01 17:26 ` Jerin Jacob
0 siblings, 1 reply; 83+ messages in thread
From: Stephen Hemminger @ 2018-08-01 16:54 UTC (permalink / raw)
To: Joseph, Anoob
Cc: Thomas Monjalon, dev, Bruce Richardson, Pablo de Lara,
Jerin Jacob, Narayana Prasad, Hemant Agrawal, Ananyev,
Konstantin, Sunil Kumar Kori, Nikhil Rao
On Wed, 1 Aug 2018 12:29:50 +0530
"Joseph, Anoob" <Anoob.Joseph@caviumnetworks.com> wrote:
> Hi Thomas,
>
> On 26-07-2018 22:27, Thomas Monjalon wrote:
> > External Email
> >
> >> Anoob Joseph (12):
> >> examples/l2fwd: move macro definitions to common header
> >> examples/l2fwd: move structure definitions to common header
> >> examples/l2fwd: move globally accessed vars to common header
> >> examples/l2fwd: move dataplane code to new file
> >> examples/l2fwd: remove unused header includes
> >> examples/l2fwd: move drain buffers to new function
> >> examples/l2fwd: optimize check for master core
> >> examples/l2fwd: move periodic tasks to new function
> >> examples/l2fwd: skip timer updates for non master cores
> >> examples/l2fwd: move pkt send code to a new function
> >> examples/l2fwd: use fprint instead of printf for usage print
> >> examples/l2fwd: improvements to the usage print
> > Maintainers of this app look to be against adding complexity.
> >
> > In order to get this series accepted, we need more discussions
> > with more people involved.
> > So it will miss 18.08.
> >
> > It can be discussed in a more global discussion about examples maintenance.
> > If discussion does not happen, you can request it to the technical board.
> >
> Event dev framework and various adapters enable multiple packet handling
> schemes, as opposed to the traditional polling on queues. But these
> features are not integrated into any established example application.
> There are specific example applications for event dev etc, which can be
> used to analyze an event device or a particular eventdev adapter, but
> there is no standard application which can be used to compare the real
> world performance for a system when it's using event device for packet
> handling and when it's done via polling on queues.
>
> The following patch submitted by Sunil was looking to address this issue
> with l3fwd,
> https://mails.dpdk.org/archives/dev/2018-March/093131.html
>
> Bruce & Jerin reviewed the patch and suggested the addition of helper
> functions to abstract the event mode additions in applications,
> https://mails.dpdk.org/archives/dev/2018-April/096879.html
>
> This effort of adding helper functions for eventmode was taken up
> following the above suggestion. The idea is to add eventmode without
> touching the existing code path. All the eventmode specific additions
> would go into library so that these need not be repeated for every
> application. And since there is no change in the existing code path,
> performance for any vendor should not have any impact with the additions.
>
> The scope of this effort has increased since the submission, as now we
> have Tx adapter as well. Sunil & Konstantin had clarified their
> concerns, and gave green flag to this approach.
> https://mails.dpdk.org/archives/dev/2018-June/105730.html
> https://mails.dpdk.org/archives/dev/2018-July/106453.html
>
> I guess Bruce was opening this question to the community. For compute
> intense applications like ipsec-secgw, eventmode might be the right
> approach in the first place. Such complex applications would need a
> scheduler to perform dynamic load balancing. Addition of eventmode in
> l2fwd was to float around the idea which can then be scaled for more
> complex applications.
>
> If maintainers doesn't have any objection to this, I'm fine with adding
> this in the next release.
>
> Thanks,
> Anoob
It is important that DPDK has good examples of how to use existing
frameworks and libraries. These applications are what most customers
build their applications from and they provide basis for testing.
The DPDK needs to continue to support multiple usage models. This
is one of its strong points. I would rather leave existing l2fwd
and l3fwd alone and instead make new examples that use the frameworks.
If nothing else haveing l2fwd and l2fwd-eventdev would allow for
performance comparisons.
As the number of examples increases, probably also need to have
a roadmap or decision chart to explain the advangage/disadvantage
of each architecture.
^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: [dpdk-dev] [PATCH v2 00/12] preparing l2fwd for eventmode additions
2018-08-01 16:54 ` Stephen Hemminger
@ 2018-08-01 17:26 ` Jerin Jacob
2018-08-02 8:19 ` Ananyev, Konstantin
0 siblings, 1 reply; 83+ messages in thread
From: Jerin Jacob @ 2018-08-01 17:26 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Joseph, Anoob, Thomas Monjalon, dev, Bruce Richardson,
Pablo de Lara, Narayana Prasad, Hemant Agrawal, Ananyev,
Konstantin, Sunil Kumar Kori, Nikhil Rao
-----Original Message-----
> Date: Wed, 1 Aug 2018 09:54:14 -0700
> From: Stephen Hemminger <stephen@networkplumber.org>
> To: "Joseph, Anoob" <Anoob.Joseph@caviumnetworks.com>
> Cc: Thomas Monjalon <thomas@monjalon.net>, dev@dpdk.org, Bruce Richardson
> <bruce.richardson@intel.com>, Pablo de Lara
> <pablo.de.lara.guarch@intel.com>, Jerin Jacob
> <jerin.jacob@caviumnetworks.com>, Narayana Prasad
> <narayanaprasad.athreya@caviumnetworks.com>, Hemant Agrawal
> <hemant.agrawal@nxp.com>, "Ananyev, Konstantin"
> <konstantin.ananyev@intel.com>, Sunil Kumar Kori <sunil.kori@nxp.com>,
> Nikhil Rao <nikhil.rao@intel.com>
> Subject: Re: [dpdk-dev] [PATCH v2 00/12] preparing l2fwd for eventmode
> additions
>
>
> On Wed, 1 Aug 2018 12:29:50 +0530
> "Joseph, Anoob" <Anoob.Joseph@caviumnetworks.com> wrote:
>
> > Hi Thomas,
> >
> > On 26-07-2018 22:27, Thomas Monjalon wrote:
> > > External Email
> > >
> > >> Anoob Joseph (12):
> > >> examples/l2fwd: move macro definitions to common header
> > >> examples/l2fwd: move structure definitions to common header
> > >> examples/l2fwd: move globally accessed vars to common header
> > >> examples/l2fwd: move dataplane code to new file
> > >> examples/l2fwd: remove unused header includes
> > >> examples/l2fwd: move drain buffers to new function
> > >> examples/l2fwd: optimize check for master core
> > >> examples/l2fwd: move periodic tasks to new function
> > >> examples/l2fwd: skip timer updates for non master cores
> > >> examples/l2fwd: move pkt send code to a new function
> > >> examples/l2fwd: use fprint instead of printf for usage print
> > >> examples/l2fwd: improvements to the usage print
> > > Maintainers of this app look to be against adding complexity.
> > >
> > > In order to get this series accepted, we need more discussions
> > > with more people involved.
> > > So it will miss 18.08.
> > >
> > > It can be discussed in a more global discussion about examples maintenance.
> > > If discussion does not happen, you can request it to the technical board.
> > >
> > Event dev framework and various adapters enable multiple packet handling
> > schemes, as opposed to the traditional polling on queues. But these
> > features are not integrated into any established example application.
> > There are specific example applications for event dev etc, which can be
> > used to analyze an event device or a particular eventdev adapter, but
> > there is no standard application which can be used to compare the real
> > world performance for a system when it's using event device for packet
> > handling and when it's done via polling on queues.
> >
> > The following patch submitted by Sunil was looking to address this issue
> > with l3fwd,
> > https://mails.dpdk.org/archives/dev/2018-March/093131.html
> >
> > Bruce & Jerin reviewed the patch and suggested the addition of helper
> > functions to abstract the event mode additions in applications,
> > https://mails.dpdk.org/archives/dev/2018-April/096879.html
> >
> > This effort of adding helper functions for eventmode was taken up
> > following the above suggestion. The idea is to add eventmode without
> > touching the existing code path. All the eventmode specific additions
> > would go into library so that these need not be repeated for every
> > application. And since there is no change in the existing code path,
> > performance for any vendor should not have any impact with the additions.
> >
> > The scope of this effort has increased since the submission, as now we
> > have Tx adapter as well. Sunil & Konstantin had clarified their
> > concerns, and gave green flag to this approach.
> > https://mails.dpdk.org/archives/dev/2018-June/105730.html
> > https://mails.dpdk.org/archives/dev/2018-July/106453.html
> >
> > I guess Bruce was opening this question to the community. For compute
> > intense applications like ipsec-secgw, eventmode might be the right
> > approach in the first place. Such complex applications would need a
> > scheduler to perform dynamic load balancing. Addition of eventmode in
> > l2fwd was to float around the idea which can then be scaled for more
> > complex applications.
> >
> > If maintainers doesn't have any objection to this, I'm fine with adding
> > this in the next release.
> >
> > Thanks,
> > Anoob
>
> It is important that DPDK has good examples of how to use existing
> frameworks and libraries. These applications are what most customers
> build their applications from and they provide basis for testing.
>
> The DPDK needs to continue to support multiple usage models. This
> is one of its strong points. I would rather leave existing l2fwd
> and l3fwd alone and instead make new examples that use the frameworks.
> If nothing else haveing l2fwd and l2fwd-eventdev would allow for
> performance comparisons.
Unlike other applications example, there wont be any change in packet
processing functions in eventdev vs poll mode case. Only worker
schematics will change and that can be moved to separated files.
something like worker_poll.c and worker_event.c and both of them
use common packet processing functions using mbuf.
The only disadvantage of having separate application would be packet
processing code duplication. Which is non trivial for l3fwd, IPSec
application IMO.
# Are we fine with code duplication in example application like l3fwd and
IPSec?
# if yes, Are we fine with keeping l2fwd _as is_ to reduce the
complexity and l2fwd-eventdev supports both modes wherever possible?
>
> As the number of examples increases, probably also need to have
> a roadmap or decision chart to explain the advangage/disadvantage
> of each architecture.
>
^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: [dpdk-dev] [PATCH v2 00/12] preparing l2fwd for eventmode additions
2018-08-01 17:26 ` Jerin Jacob
@ 2018-08-02 8:19 ` Ananyev, Konstantin
2018-08-13 7:22 ` Joseph, Anoob
0 siblings, 1 reply; 83+ messages in thread
From: Ananyev, Konstantin @ 2018-08-02 8:19 UTC (permalink / raw)
To: Jerin Jacob, Stephen Hemminger
Cc: Joseph, Anoob, Thomas Monjalon, dev, Richardson, Bruce,
De Lara Guarch, Pablo, Narayana Prasad, Hemant Agrawal,
Sunil Kumar Kori, Rao, Nikhil
Hi everyone,
> > > >
> > > > In order to get this series accepted, we need more discussions
> > > > with more people involved.
> > > > So it will miss 18.08.
> > > >
> > > > It can be discussed in a more global discussion about examples maintenance.
> > > > If discussion does not happen, you can request it to the technical board.
> > > >
> > > Event dev framework and various adapters enable multiple packet handling
> > > schemes, as opposed to the traditional polling on queues. But these
> > > features are not integrated into any established example application.
> > > There are specific example applications for event dev etc, which can be
> > > used to analyze an event device or a particular eventdev adapter, but
> > > there is no standard application which can be used to compare the real
> > > world performance for a system when it's using event device for packet
> > > handling and when it's done via polling on queues.
> > >
> > > The following patch submitted by Sunil was looking to address this issue
> > > with l3fwd,
> > > https://mails.dpdk.org/archives/dev/2018-March/093131.html
> > >
> > > Bruce & Jerin reviewed the patch and suggested the addition of helper
> > > functions to abstract the event mode additions in applications,
> > > https://mails.dpdk.org/archives/dev/2018-April/096879.html
> > >
> > > This effort of adding helper functions for eventmode was taken up
> > > following the above suggestion. The idea is to add eventmode without
> > > touching the existing code path. All the eventmode specific additions
> > > would go into library so that these need not be repeated for every
> > > application. And since there is no change in the existing code path,
> > > performance for any vendor should not have any impact with the additions.
> > >
> > > The scope of this effort has increased since the submission, as now we
> > > have Tx adapter as well. Sunil & Konstantin had clarified their
> > > concerns, and gave green flag to this approach.
> > > https://mails.dpdk.org/archives/dev/2018-June/105730.html
> > > https://mails.dpdk.org/archives/dev/2018-July/106453.html
> > >
> > > I guess Bruce was opening this question to the community. For compute
> > > intense applications like ipsec-secgw, eventmode might be the right
> > > approach in the first place. Such complex applications would need a
> > > scheduler to perform dynamic load balancing. Addition of eventmode in
> > > l2fwd was to float around the idea which can then be scaled for more
> > > complex applications.
> > >
> > > If maintainers doesn't have any objection to this, I'm fine with adding
> > > this in the next release.
> > >
> > > Thanks,
> > > Anoob
> >
> > It is important that DPDK has good examples of how to use existing
> > frameworks and libraries. These applications are what most customers
> > build their applications from and they provide basis for testing.
> >
> > The DPDK needs to continue to support multiple usage models. This
> > is one of its strong points. I would rather leave existing l2fwd
> > and l3fwd alone and instead make new examples that use the frameworks.
> > If nothing else haveing l2fwd and l2fwd-eventdev would allow for
> > performance comparisons.
>
> Unlike other applications example, there wont be any change in packet
> processing functions in eventdev vs poll mode case. Only worker
> schematics will change and that can be moved to separated files.
> something like worker_poll.c and worker_event.c and both of them
> use common packet processing functions using mbuf.
>
> The only disadvantage of having separate application would be packet
> processing code duplication. Which is non trivial for l3fwd, IPSec
> application IMO.
Personally I am ok with original design suggestion:
keep packet processing code common, that would be used by both poll and event modes.
We could just have a command-line parameter in which mode the app will run.
Another alternative - generate two binaries l2fwd-poll, l2fwd-event (or so).
Konstantin
>
> # Are we fine with code duplication in example application like l3fwd and
> IPSec?
> # if yes, Are we fine with keeping l2fwd _as is_ to reduce the
> complexity and l2fwd-eventdev supports both modes wherever possible?
>
> >
> > As the number of examples increases, probably also need to have
> > a roadmap or decision chart to explain the advangage/disadvantage
> > of each architecture.
> >
^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: [dpdk-dev] [PATCH v2 00/12] preparing l2fwd for eventmode additions
2018-08-02 8:19 ` Ananyev, Konstantin
@ 2018-08-13 7:22 ` Joseph, Anoob
2018-08-13 9:27 ` Bruce Richardson
0 siblings, 1 reply; 83+ messages in thread
From: Joseph, Anoob @ 2018-08-13 7:22 UTC (permalink / raw)
To: Thomas Monjalon, Richardson, Bruce, De Lara Guarch, Pablo
Cc: Ananyev, Konstantin, Jerin Jacob, Stephen Hemminger, dev,
Narayana Prasad, Hemant Agrawal, Sunil Kumar Kori, Rao, Nikhil
Hi Bruce, Pablo,
If there are no more issues about the approach, can you review the
patches and give the feedback?
Please do note that this series doesn't add any event mode specific
code. That will come as a different patch series after incorporating
Jerin's comments.
Thanks,
Anoob
On 02-08-2018 13:49, Ananyev, Konstantin wrote:
> External Email
>
> Hi everyone,
>
>>>>> In order to get this series accepted, we need more discussions
>>>>> with more people involved.
>>>>> So it will miss 18.08.
>>>>>
>>>>> It can be discussed in a more global discussion about examples maintenance.
>>>>> If discussion does not happen, you can request it to the technical board.
>>>>>
>>>> Event dev framework and various adapters enable multiple packet handling
>>>> schemes, as opposed to the traditional polling on queues. But these
>>>> features are not integrated into any established example application.
>>>> There are specific example applications for event dev etc, which can be
>>>> used to analyze an event device or a particular eventdev adapter, but
>>>> there is no standard application which can be used to compare the real
>>>> world performance for a system when it's using event device for packet
>>>> handling and when it's done via polling on queues.
>>>>
>>>> The following patch submitted by Sunil was looking to address this issue
>>>> with l3fwd,
>>>> https://mails.dpdk.org/archives/dev/2018-March/093131.html
>>>>
>>>> Bruce & Jerin reviewed the patch and suggested the addition of helper
>>>> functions to abstract the event mode additions in applications,
>>>> https://mails.dpdk.org/archives/dev/2018-April/096879.html
>>>>
>>>> This effort of adding helper functions for eventmode was taken up
>>>> following the above suggestion. The idea is to add eventmode without
>>>> touching the existing code path. All the eventmode specific additions
>>>> would go into library so that these need not be repeated for every
>>>> application. And since there is no change in the existing code path,
>>>> performance for any vendor should not have any impact with the additions.
>>>>
>>>> The scope of this effort has increased since the submission, as now we
>>>> have Tx adapter as well. Sunil & Konstantin had clarified their
>>>> concerns, and gave green flag to this approach.
>>>> https://mails.dpdk.org/archives/dev/2018-June/105730.html
>>>> https://mails.dpdk.org/archives/dev/2018-July/106453.html
>>>>
>>>> I guess Bruce was opening this question to the community. For compute
>>>> intense applications like ipsec-secgw, eventmode might be the right
>>>> approach in the first place. Such complex applications would need a
>>>> scheduler to perform dynamic load balancing. Addition of eventmode in
>>>> l2fwd was to float around the idea which can then be scaled for more
>>>> complex applications.
>>>>
>>>> If maintainers doesn't have any objection to this, I'm fine with adding
>>>> this in the next release.
>>>>
>>>> Thanks,
>>>> Anoob
>>> It is important that DPDK has good examples of how to use existing
>>> frameworks and libraries. These applications are what most customers
>>> build their applications from and they provide basis for testing.
>>>
>>> The DPDK needs to continue to support multiple usage models. This
>>> is one of its strong points. I would rather leave existing l2fwd
>>> and l3fwd alone and instead make new examples that use the frameworks.
>>> If nothing else haveing l2fwd and l2fwd-eventdev would allow for
>>> performance comparisons.
>> Unlike other applications example, there wont be any change in packet
>> processing functions in eventdev vs poll mode case. Only worker
>> schematics will change and that can be moved to separated files.
>> something like worker_poll.c and worker_event.c and both of them
>> use common packet processing functions using mbuf.
>>
>> The only disadvantage of having separate application would be packet
>> processing code duplication. Which is non trivial for l3fwd, IPSec
>> application IMO.
> Personally I am ok with original design suggestion:
> keep packet processing code common, that would be used by both poll and event modes.
> We could just have a command-line parameter in which mode the app will run.
> Another alternative - generate two binaries l2fwd-poll, l2fwd-event (or so).
> Konstantin
>> # Are we fine with code duplication in example application like l3fwd and
>> IPSec?
>> # if yes, Are we fine with keeping l2fwd _as is_ to reduce the
>> complexity and l2fwd-eventdev supports both modes wherever possible?
>>
>>> As the number of examples increases, probably also need to have
>>> a roadmap or decision chart to explain the advangage/disadvantage
>>> of each architecture.
>>>
^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: [dpdk-dev] [PATCH v2 00/12] preparing l2fwd for eventmode additions
2018-08-13 7:22 ` Joseph, Anoob
@ 2018-08-13 9:27 ` Bruce Richardson
2018-08-13 15:59 ` Joseph, Anoob
0 siblings, 1 reply; 83+ messages in thread
From: Bruce Richardson @ 2018-08-13 9:27 UTC (permalink / raw)
To: Joseph, Anoob
Cc: Thomas Monjalon, De Lara Guarch, Pablo, Ananyev, Konstantin,
Jerin Jacob, Stephen Hemminger, dev, Narayana Prasad,
Hemant Agrawal, Sunil Kumar Kori, Rao, Nikhil
On Mon, Aug 13, 2018 at 12:52:19PM +0530, Joseph, Anoob wrote:
> Hi Bruce, Pablo,
>
> If there are no more issues about the approach, can you review the patches
> and give the feedback?
>
> Please do note that this series doesn't add any event mode specific code.
> That will come as a different patch series after incorporating Jerin's
> comments.
>
> Thanks,
> Anoob
My main concern is with l2fwd, rather than l3fwd, which is already fairly
complicated. I could see l3fwd being updated to allow an eventmode without
too many problems.
With l2fwd, the only issue I have is with the volume of code involved.
l2fwd is currently a very simple application which fits in a single file.
With these updates it's no longer such a simple, approachable app, rather
it becomes one which takes a bit of studying a switching between files to
fully understand. The data path is only a very small part of the app, so by
adding an event-based path to the same app we have very little code saving.
Therefore, I think having a separate l2fwd-eventdev would be better for
this case. Two simpler to understand apps is better than one more
complicated on IMHO.
My 2c.
/Bruce
> On 02-08-2018 13:49, Ananyev, Konstantin wrote:
> > External Email
> >
> > Hi everyone,
> >
> > > > > > In order to get this series accepted, we need more discussions
> > > > > > with more people involved.
> > > > > > So it will miss 18.08.
> > > > > >
> > > > > > It can be discussed in a more global discussion about examples maintenance.
> > > > > > If discussion does not happen, you can request it to the technical board.
> > > > > >
> > > > > Event dev framework and various adapters enable multiple packet handling
> > > > > schemes, as opposed to the traditional polling on queues. But these
> > > > > features are not integrated into any established example application.
> > > > > There are specific example applications for event dev etc, which can be
> > > > > used to analyze an event device or a particular eventdev adapter, but
> > > > > there is no standard application which can be used to compare the real
> > > > > world performance for a system when it's using event device for packet
> > > > > handling and when it's done via polling on queues.
> > > > >
> > > > > The following patch submitted by Sunil was looking to address this issue
> > > > > with l3fwd,
> > > > > https://mails.dpdk.org/archives/dev/2018-March/093131.html
> > > > >
> > > > > Bruce & Jerin reviewed the patch and suggested the addition of helper
> > > > > functions to abstract the event mode additions in applications,
> > > > > https://mails.dpdk.org/archives/dev/2018-April/096879.html
> > > > >
> > > > > This effort of adding helper functions for eventmode was taken up
> > > > > following the above suggestion. The idea is to add eventmode without
> > > > > touching the existing code path. All the eventmode specific additions
> > > > > would go into library so that these need not be repeated for every
> > > > > application. And since there is no change in the existing code path,
> > > > > performance for any vendor should not have any impact with the additions.
> > > > >
> > > > > The scope of this effort has increased since the submission, as now we
> > > > > have Tx adapter as well. Sunil & Konstantin had clarified their
> > > > > concerns, and gave green flag to this approach.
> > > > > https://mails.dpdk.org/archives/dev/2018-June/105730.html
> > > > > https://mails.dpdk.org/archives/dev/2018-July/106453.html
> > > > >
> > > > > I guess Bruce was opening this question to the community. For compute
> > > > > intense applications like ipsec-secgw, eventmode might be the right
> > > > > approach in the first place. Such complex applications would need a
> > > > > scheduler to perform dynamic load balancing. Addition of eventmode in
> > > > > l2fwd was to float around the idea which can then be scaled for more
> > > > > complex applications.
> > > > >
> > > > > If maintainers doesn't have any objection to this, I'm fine with adding
> > > > > this in the next release.
> > > > >
> > > > > Thanks,
> > > > > Anoob
> > > > It is important that DPDK has good examples of how to use existing
> > > > frameworks and libraries. These applications are what most customers
> > > > build their applications from and they provide basis for testing.
> > > >
> > > > The DPDK needs to continue to support multiple usage models. This
> > > > is one of its strong points. I would rather leave existing l2fwd
> > > > and l3fwd alone and instead make new examples that use the frameworks.
> > > > If nothing else haveing l2fwd and l2fwd-eventdev would allow for
> > > > performance comparisons.
> > > Unlike other applications example, there wont be any change in packet
> > > processing functions in eventdev vs poll mode case. Only worker
> > > schematics will change and that can be moved to separated files.
> > > something like worker_poll.c and worker_event.c and both of them
> > > use common packet processing functions using mbuf.
> > >
> > > The only disadvantage of having separate application would be packet
> > > processing code duplication. Which is non trivial for l3fwd, IPSec
> > > application IMO.
> > Personally I am ok with original design suggestion:
> > keep packet processing code common, that would be used by both poll and event modes.
> > We could just have a command-line parameter in which mode the app will run.
> > Another alternative - generate two binaries l2fwd-poll, l2fwd-event (or so).
> > Konstantin
> > > # Are we fine with code duplication in example application like l3fwd and
> > > IPSec?
> > > # if yes, Are we fine with keeping l2fwd _as is_ to reduce the
> > > complexity and l2fwd-eventdev supports both modes wherever possible?
> > >
> > > > As the number of examples increases, probably also need to have
> > > > a roadmap or decision chart to explain the advangage/disadvantage
> > > > of each architecture.
> > > >
>
^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: [dpdk-dev] [PATCH v2 00/12] preparing l2fwd for eventmode additions
2018-08-13 9:27 ` Bruce Richardson
@ 2018-08-13 15:59 ` Joseph, Anoob
2018-08-14 10:33 ` Bruce Richardson
0 siblings, 1 reply; 83+ messages in thread
From: Joseph, Anoob @ 2018-08-13 15:59 UTC (permalink / raw)
To: Bruce Richardson
Cc: Thomas Monjalon, De Lara Guarch, Pablo, Ananyev, Konstantin,
Jerin Jacob, Stephen Hemminger, dev, Narayana Prasad,
Hemant Agrawal, Sunil Kumar Kori, Rao, Nikhil
Hi Bruce,
The reason why l2fwd was chosen was to allow everyone to chip in their
ideas while preparing the framework.
This framework would be extended to other applications, hence needed
enough inputs before expanding to complex applications. If your
suggestion is to make l3fwd event driven first, I'll start looking in
that direction.
As for l2fwd, I'm fine with moving event-mode additions to a new app.
But with the present approach, the app would run in both event mode and
poll mode.
Your thoughts on renaming the existing app to l2fwd-poll and the
proposed app as l2fwd?
Thanks,
Anoob
On 13-08-2018 14:57, Bruce Richardson wrote:
> External Email
>
> On Mon, Aug 13, 2018 at 12:52:19PM +0530, Joseph, Anoob wrote:
>> Hi Bruce, Pablo,
>>
>> If there are no more issues about the approach, can you review the patches
>> and give the feedback?
>>
>> Please do note that this series doesn't add any event mode specific code.
>> That will come as a different patch series after incorporating Jerin's
>> comments.
>>
>> Thanks,
>> Anoob
> My main concern is with l2fwd, rather than l3fwd, which is already fairly
> complicated. I could see l3fwd being updated to allow an eventmode without
> too many problems.
>
> With l2fwd, the only issue I have is with the volume of code involved.
> l2fwd is currently a very simple application which fits in a single file.
> With these updates it's no longer such a simple, approachable app, rather
> it becomes one which takes a bit of studying a switching between files to
> fully understand. The data path is only a very small part of the app, so by
> adding an event-based path to the same app we have very little code saving.
> Therefore, I think having a separate l2fwd-eventdev would be better for
> this case. Two simpler to understand apps is better than one more
> complicated on IMHO.
>
> My 2c.
>
> /Bruce
>
>> On 02-08-2018 13:49, Ananyev, Konstantin wrote:
>>> External Email
>>>
>>> Hi everyone,
>>>
>>>>>>> In order to get this series accepted, we need more discussions
>>>>>>> with more people involved.
>>>>>>> So it will miss 18.08.
>>>>>>>
>>>>>>> It can be discussed in a more global discussion about examples maintenance.
>>>>>>> If discussion does not happen, you can request it to the technical board.
>>>>>>>
>>>>>> Event dev framework and various adapters enable multiple packet handling
>>>>>> schemes, as opposed to the traditional polling on queues. But these
>>>>>> features are not integrated into any established example application.
>>>>>> There are specific example applications for event dev etc, which can be
>>>>>> used to analyze an event device or a particular eventdev adapter, but
>>>>>> there is no standard application which can be used to compare the real
>>>>>> world performance for a system when it's using event device for packet
>>>>>> handling and when it's done via polling on queues.
>>>>>>
>>>>>> The following patch submitted by Sunil was looking to address this issue
>>>>>> with l3fwd,
>>>>>> https://mails.dpdk.org/archives/dev/2018-March/093131.html
>>>>>>
>>>>>> Bruce & Jerin reviewed the patch and suggested the addition of helper
>>>>>> functions to abstract the event mode additions in applications,
>>>>>> https://mails.dpdk.org/archives/dev/2018-April/096879.html
>>>>>>
>>>>>> This effort of adding helper functions for eventmode was taken up
>>>>>> following the above suggestion. The idea is to add eventmode without
>>>>>> touching the existing code path. All the eventmode specific additions
>>>>>> would go into library so that these need not be repeated for every
>>>>>> application. And since there is no change in the existing code path,
>>>>>> performance for any vendor should not have any impact with the additions.
>>>>>>
>>>>>> The scope of this effort has increased since the submission, as now we
>>>>>> have Tx adapter as well. Sunil & Konstantin had clarified their
>>>>>> concerns, and gave green flag to this approach.
>>>>>> https://mails.dpdk.org/archives/dev/2018-June/105730.html
>>>>>> https://mails.dpdk.org/archives/dev/2018-July/106453.html
>>>>>>
>>>>>> I guess Bruce was opening this question to the community. For compute
>>>>>> intense applications like ipsec-secgw, eventmode might be the right
>>>>>> approach in the first place. Such complex applications would need a
>>>>>> scheduler to perform dynamic load balancing. Addition of eventmode in
>>>>>> l2fwd was to float around the idea which can then be scaled for more
>>>>>> complex applications.
>>>>>>
>>>>>> If maintainers doesn't have any objection to this, I'm fine with adding
>>>>>> this in the next release.
>>>>>>
>>>>>> Thanks,
>>>>>> Anoob
>>>>> It is important that DPDK has good examples of how to use existing
>>>>> frameworks and libraries. These applications are what most customers
>>>>> build their applications from and they provide basis for testing.
>>>>>
>>>>> The DPDK needs to continue to support multiple usage models. This
>>>>> is one of its strong points. I would rather leave existing l2fwd
>>>>> and l3fwd alone and instead make new examples that use the frameworks.
>>>>> If nothing else haveing l2fwd and l2fwd-eventdev would allow for
>>>>> performance comparisons.
>>>> Unlike other applications example, there wont be any change in packet
>>>> processing functions in eventdev vs poll mode case. Only worker
>>>> schematics will change and that can be moved to separated files.
>>>> something like worker_poll.c and worker_event.c and both of them
>>>> use common packet processing functions using mbuf.
>>>>
>>>> The only disadvantage of having separate application would be packet
>>>> processing code duplication. Which is non trivial for l3fwd, IPSec
>>>> application IMO.
>>> Personally I am ok with original design suggestion:
>>> keep packet processing code common, that would be used by both poll and event modes.
>>> We could just have a command-line parameter in which mode the app will run.
>>> Another alternative - generate two binaries l2fwd-poll, l2fwd-event (or so).
>>> Konstantin
>>>> # Are we fine with code duplication in example application like l3fwd and
>>>> IPSec?
>>>> # if yes, Are we fine with keeping l2fwd _as is_ to reduce the
>>>> complexity and l2fwd-eventdev supports both modes wherever possible?
>>>>
>>>>> As the number of examples increases, probably also need to have
>>>>> a roadmap or decision chart to explain the advangage/disadvantage
>>>>> of each architecture.
>>>>>
^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: [dpdk-dev] [PATCH v2 00/12] preparing l2fwd for eventmode additions
2018-08-13 15:59 ` Joseph, Anoob
@ 2018-08-14 10:33 ` Bruce Richardson
2018-08-18 9:58 ` Joseph, Anoob
0 siblings, 1 reply; 83+ messages in thread
From: Bruce Richardson @ 2018-08-14 10:33 UTC (permalink / raw)
To: Joseph, Anoob
Cc: Thomas Monjalon, De Lara Guarch, Pablo, Ananyev, Konstantin,
Jerin Jacob, Stephen Hemminger, dev, Narayana Prasad,
Hemant Agrawal, Sunil Kumar Kori, Rao, Nikhil
On Mon, Aug 13, 2018 at 09:29:01PM +0530, Joseph, Anoob wrote:
> Hi Bruce,
>
> The reason why l2fwd was chosen was to allow everyone to chip in their ideas
> while preparing the framework.
> This framework would be extended to other applications, hence needed enough
> inputs before expanding to complex applications. If your suggestion is to
> make l3fwd event driven first, I'll start looking in that direction.
Seems good to me, if others don't have an issue with it.
>
> As for l2fwd, I'm fine with moving event-mode additions to a new app. But
> with the present approach, the app would run in both event mode and poll
> mode.
>
> Your thoughts on renaming the existing app to l2fwd-poll and the proposed
> app as l2fwd?
>
> Thanks,
> Anoob
I'm not sure about the name "poll", I think "ethdev" and "eventdev" should be
the suffixes, if we want to move in that direction.
However, my preference would be to leave l2fwd as-is, and to have a comment
at the top of the source file, and note in the documentation along the
lines of:
"This example demonstrates basic l2 forwarding using ethdev primitives. To
see the same use-case implemented using event-based primitives, see the
'l2fwd-eventdev' example".
As I said before, my main concern is to keep the basic examples short and
readable.
/Bruce
> On 13-08-2018 14:57, Bruce Richardson wrote:
> > External Email
> >
> > On Mon, Aug 13, 2018 at 12:52:19PM +0530, Joseph, Anoob wrote:
> > > Hi Bruce, Pablo,
> > >
> > > If there are no more issues about the approach, can you review the patches
> > > and give the feedback?
> > >
> > > Please do note that this series doesn't add any event mode specific code.
> > > That will come as a different patch series after incorporating Jerin's
> > > comments.
> > >
> > > Thanks,
> > > Anoob
> > My main concern is with l2fwd, rather than l3fwd, which is already fairly
> > complicated. I could see l3fwd being updated to allow an eventmode without
> > too many problems.
> >
> > With l2fwd, the only issue I have is with the volume of code involved.
> > l2fwd is currently a very simple application which fits in a single file.
> > With these updates it's no longer such a simple, approachable app, rather
> > it becomes one which takes a bit of studying a switching between files to
> > fully understand. The data path is only a very small part of the app, so by
> > adding an event-based path to the same app we have very little code saving.
> > Therefore, I think having a separate l2fwd-eventdev would be better for
> > this case. Two simpler to understand apps is better than one more
> > complicated on IMHO.
> >
> > My 2c.
> >
> > /Bruce
> >
> > > On 02-08-2018 13:49, Ananyev, Konstantin wrote:
> > > > External Email
> > > >
> > > > Hi everyone,
> > > >
> > > > > > > > In order to get this series accepted, we need more discussions
> > > > > > > > with more people involved.
> > > > > > > > So it will miss 18.08.
> > > > > > > >
> > > > > > > > It can be discussed in a more global discussion about examples maintenance.
> > > > > > > > If discussion does not happen, you can request it to the technical board.
> > > > > > > >
> > > > > > > Event dev framework and various adapters enable multiple packet handling
> > > > > > > schemes, as opposed to the traditional polling on queues. But these
> > > > > > > features are not integrated into any established example application.
> > > > > > > There are specific example applications for event dev etc, which can be
> > > > > > > used to analyze an event device or a particular eventdev adapter, but
> > > > > > > there is no standard application which can be used to compare the real
> > > > > > > world performance for a system when it's using event device for packet
> > > > > > > handling and when it's done via polling on queues.
> > > > > > >
> > > > > > > The following patch submitted by Sunil was looking to address this issue
> > > > > > > with l3fwd,
> > > > > > > https://mails.dpdk.org/archives/dev/2018-March/093131.html
> > > > > > >
> > > > > > > Bruce & Jerin reviewed the patch and suggested the addition of helper
> > > > > > > functions to abstract the event mode additions in applications,
> > > > > > > https://mails.dpdk.org/archives/dev/2018-April/096879.html
> > > > > > >
> > > > > > > This effort of adding helper functions for eventmode was taken up
> > > > > > > following the above suggestion. The idea is to add eventmode without
> > > > > > > touching the existing code path. All the eventmode specific additions
> > > > > > > would go into library so that these need not be repeated for every
> > > > > > > application. And since there is no change in the existing code path,
> > > > > > > performance for any vendor should not have any impact with the additions.
> > > > > > >
> > > > > > > The scope of this effort has increased since the submission, as now we
> > > > > > > have Tx adapter as well. Sunil & Konstantin had clarified their
> > > > > > > concerns, and gave green flag to this approach.
> > > > > > > https://mails.dpdk.org/archives/dev/2018-June/105730.html
> > > > > > > https://mails.dpdk.org/archives/dev/2018-July/106453.html
> > > > > > >
> > > > > > > I guess Bruce was opening this question to the community. For compute
> > > > > > > intense applications like ipsec-secgw, eventmode might be the right
> > > > > > > approach in the first place. Such complex applications would need a
> > > > > > > scheduler to perform dynamic load balancing. Addition of eventmode in
> > > > > > > l2fwd was to float around the idea which can then be scaled for more
> > > > > > > complex applications.
> > > > > > >
> > > > > > > If maintainers doesn't have any objection to this, I'm fine with adding
> > > > > > > this in the next release.
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Anoob
> > > > > > It is important that DPDK has good examples of how to use existing
> > > > > > frameworks and libraries. These applications are what most customers
> > > > > > build their applications from and they provide basis for testing.
> > > > > >
> > > > > > The DPDK needs to continue to support multiple usage models. This
> > > > > > is one of its strong points. I would rather leave existing l2fwd
> > > > > > and l3fwd alone and instead make new examples that use the frameworks.
> > > > > > If nothing else haveing l2fwd and l2fwd-eventdev would allow for
> > > > > > performance comparisons.
> > > > > Unlike other applications example, there wont be any change in packet
> > > > > processing functions in eventdev vs poll mode case. Only worker
> > > > > schematics will change and that can be moved to separated files.
> > > > > something like worker_poll.c and worker_event.c and both of them
> > > > > use common packet processing functions using mbuf.
> > > > >
> > > > > The only disadvantage of having separate application would be packet
> > > > > processing code duplication. Which is non trivial for l3fwd, IPSec
> > > > > application IMO.
> > > > Personally I am ok with original design suggestion:
> > > > keep packet processing code common, that would be used by both poll and event modes.
> > > > We could just have a command-line parameter in which mode the app will run.
> > > > Another alternative - generate two binaries l2fwd-poll, l2fwd-event (or so).
> > > > Konstantin
> > > > > # Are we fine with code duplication in example application like l3fwd and
> > > > > IPSec?
> > > > > # if yes, Are we fine with keeping l2fwd _as is_ to reduce the
> > > > > complexity and l2fwd-eventdev supports both modes wherever possible?
> > > > >
> > > > > > As the number of examples increases, probably also need to have
> > > > > > a roadmap or decision chart to explain the advangage/disadvantage
> > > > > > of each architecture.
> > > > > >
>
^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: [dpdk-dev] [PATCH v2 00/12] preparing l2fwd for eventmode additions
2018-08-14 10:33 ` Bruce Richardson
@ 2018-08-18 9:58 ` Joseph, Anoob
2018-10-29 2:22 ` Thomas Monjalon
0 siblings, 1 reply; 83+ messages in thread
From: Joseph, Anoob @ 2018-08-18 9:58 UTC (permalink / raw)
To: Bruce Richardson
Cc: Thomas Monjalon, De Lara Guarch, Pablo, Ananyev, Konstantin,
Jerin Jacob, Stephen Hemminger, dev, Narayana Prasad,
Hemant Agrawal, Sunil Kumar Kori, Rao, Nikhil
Hi Bruce,
On 14-08-2018 16:03, Bruce Richardson wrote:
> External Email
>
> On Mon, Aug 13, 2018 at 09:29:01PM +0530, Joseph, Anoob wrote:
>> Hi Bruce,
>>
>> The reason why l2fwd was chosen was to allow everyone to chip in their ideas
>> while preparing the framework.
>> This framework would be extended to other applications, hence needed enough
>> inputs before expanding to complex applications. If your suggestion is to
>> make l3fwd event driven first, I'll start looking in that direction.
> Seems good to me, if others don't have an issue with it.
>
>> As for l2fwd, I'm fine with moving event-mode additions to a new app. But
>> with the present approach, the app would run in both event mode and poll
>> mode.
>>
>> Your thoughts on renaming the existing app to l2fwd-poll and the proposed
>> app as l2fwd?
>>
>> Thanks,
>> Anoob
> I'm not sure about the name "poll", I think "ethdev" and "eventdev" should be
> the suffixes, if we want to move in that direction.
With new adapters, like crypto adapter, event device will be able to
handle multiple devices at the same time. It will be able to abstract
not just eth device but other devices too (crypto for example). For apps
like ipsec-secgw, crypto also would be abstracted with event-device. So
what should be the ideal naming convention taking into account all that?
Using "eth"& "event" won't fit in for such cases.
Presently, mode was defined by the way packets were submitted to &
received from the device. With poll mode, device(eth, crypto etc) would
get packets directly from the core & the core would then poll for
completion. In case of event-mode, event device handles this scheduling.
Event device would submit (to all devices) and receive packets (from all
devices). Core need not poll on the device, in that case. Hence the
naming...
Your thoughts?
Anoob
> However, my preference would be to leave l2fwd as-is, and to have a comment
> at the top of the source file, and note in the documentation along the
> lines of:
>
> "This example demonstrates basic l2 forwarding using ethdev primitives. To
> see the same use-case implemented using event-based primitives, see the
> 'l2fwd-eventdev' example".
>
> As I said before, my main concern is to keep the basic examples short and
> readable.
>
> /Bruce
>
>> On 13-08-2018 14:57, Bruce Richardson wrote:
>>> External Email
>>>
>>> On Mon, Aug 13, 2018 at 12:52:19PM +0530, Joseph, Anoob wrote:
>>>> Hi Bruce, Pablo,
>>>>
>>>> If there are no more issues about the approach, can you review the patches
>>>> and give the feedback?
>>>>
>>>> Please do note that this series doesn't add any event mode specific code.
>>>> That will come as a different patch series after incorporating Jerin's
>>>> comments.
>>>>
>>>> Thanks,
>>>> Anoob
>>> My main concern is with l2fwd, rather than l3fwd, which is already fairly
>>> complicated. I could see l3fwd being updated to allow an eventmode without
>>> too many problems.
>>>
>>> With l2fwd, the only issue I have is with the volume of code involved.
>>> l2fwd is currently a very simple application which fits in a single file.
>>> With these updates it's no longer such a simple, approachable app, rather
>>> it becomes one which takes a bit of studying a switching between files to
>>> fully understand. The data path is only a very small part of the app, so by
>>> adding an event-based path to the same app we have very little code saving.
>>> Therefore, I think having a separate l2fwd-eventdev would be better for
>>> this case. Two simpler to understand apps is better than one more
>>> complicated on IMHO.
>>>
>>> My 2c.
>>>
>>> /Bruce
>>>
>>>> On 02-08-2018 13:49, Ananyev, Konstantin wrote:
>>>>> External Email
>>>>>
>>>>> Hi everyone,
>>>>>
>>>>>>>>> In order to get this series accepted, we need more discussions
>>>>>>>>> with more people involved.
>>>>>>>>> So it will miss 18.08.
>>>>>>>>>
>>>>>>>>> It can be discussed in a more global discussion about examples maintenance.
>>>>>>>>> If discussion does not happen, you can request it to the technical board.
>>>>>>>>>
>>>>>>>> Event dev framework and various adapters enable multiple packet handling
>>>>>>>> schemes, as opposed to the traditional polling on queues. But these
>>>>>>>> features are not integrated into any established example application.
>>>>>>>> There are specific example applications for event dev etc, which can be
>>>>>>>> used to analyze an event device or a particular eventdev adapter, but
>>>>>>>> there is no standard application which can be used to compare the real
>>>>>>>> world performance for a system when it's using event device for packet
>>>>>>>> handling and when it's done via polling on queues.
>>>>>>>>
>>>>>>>> The following patch submitted by Sunil was looking to address this issue
>>>>>>>> with l3fwd,
>>>>>>>> https://mails.dpdk.org/archives/dev/2018-March/093131.html
>>>>>>>>
>>>>>>>> Bruce & Jerin reviewed the patch and suggested the addition of helper
>>>>>>>> functions to abstract the event mode additions in applications,
>>>>>>>> https://mails.dpdk.org/archives/dev/2018-April/096879.html
>>>>>>>>
>>>>>>>> This effort of adding helper functions for eventmode was taken up
>>>>>>>> following the above suggestion. The idea is to add eventmode without
>>>>>>>> touching the existing code path. All the eventmode specific additions
>>>>>>>> would go into library so that these need not be repeated for every
>>>>>>>> application. And since there is no change in the existing code path,
>>>>>>>> performance for any vendor should not have any impact with the additions.
>>>>>>>>
>>>>>>>> The scope of this effort has increased since the submission, as now we
>>>>>>>> have Tx adapter as well. Sunil & Konstantin had clarified their
>>>>>>>> concerns, and gave green flag to this approach.
>>>>>>>> https://mails.dpdk.org/archives/dev/2018-June/105730.html
>>>>>>>> https://mails.dpdk.org/archives/dev/2018-July/106453.html
>>>>>>>>
>>>>>>>> I guess Bruce was opening this question to the community. For compute
>>>>>>>> intense applications like ipsec-secgw, eventmode might be the right
>>>>>>>> approach in the first place. Such complex applications would need a
>>>>>>>> scheduler to perform dynamic load balancing. Addition of eventmode in
>>>>>>>> l2fwd was to float around the idea which can then be scaled for more
>>>>>>>> complex applications.
>>>>>>>>
>>>>>>>> If maintainers doesn't have any objection to this, I'm fine with adding
>>>>>>>> this in the next release.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Anoob
>>>>>>> It is important that DPDK has good examples of how to use existing
>>>>>>> frameworks and libraries. These applications are what most customers
>>>>>>> build their applications from and they provide basis for testing.
>>>>>>>
>>>>>>> The DPDK needs to continue to support multiple usage models. This
>>>>>>> is one of its strong points. I would rather leave existing l2fwd
>>>>>>> and l3fwd alone and instead make new examples that use the frameworks.
>>>>>>> If nothing else haveing l2fwd and l2fwd-eventdev would allow for
>>>>>>> performance comparisons.
>>>>>> Unlike other applications example, there wont be any change in packet
>>>>>> processing functions in eventdev vs poll mode case. Only worker
>>>>>> schematics will change and that can be moved to separated files.
>>>>>> something like worker_poll.c and worker_event.c and both of them
>>>>>> use common packet processing functions using mbuf.
>>>>>>
>>>>>> The only disadvantage of having separate application would be packet
>>>>>> processing code duplication. Which is non trivial for l3fwd, IPSec
>>>>>> application IMO.
>>>>> Personally I am ok with original design suggestion:
>>>>> keep packet processing code common, that would be used by both poll and event modes.
>>>>> We could just have a command-line parameter in which mode the app will run.
>>>>> Another alternative - generate two binaries l2fwd-poll, l2fwd-event (or so).
>>>>> Konstantin
>>>>>> # Are we fine with code duplication in example application like l3fwd and
>>>>>> IPSec?
>>>>>> # if yes, Are we fine with keeping l2fwd _as is_ to reduce the
>>>>>> complexity and l2fwd-eventdev supports both modes wherever possible?
>>>>>>
>>>>>>> As the number of examples increases, probably also need to have
>>>>>>> a roadmap or decision chart to explain the advangage/disadvantage
>>>>>>> of each architecture.
>>>>>>>
^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: [dpdk-dev] [PATCH v2 00/12] preparing l2fwd for eventmode additions
2018-08-18 9:58 ` Joseph, Anoob
@ 2018-10-29 2:22 ` Thomas Monjalon
0 siblings, 0 replies; 83+ messages in thread
From: Thomas Monjalon @ 2018-10-29 2:22 UTC (permalink / raw)
To: Joseph, Anoob
Cc: dev, Bruce Richardson, De Lara Guarch, Pablo, Ananyev,
Konstantin, Jerin Jacob, Stephen Hemminger, Narayana Prasad,
Hemant Agrawal, Sunil Kumar Kori, Rao, Nikhil
18/08/2018 11:58, Joseph, Anoob:
> Hi Bruce,
>
> On 14-08-2018 16:03, Bruce Richardson wrote:
> > On Mon, Aug 13, 2018 at 09:29:01PM +0530, Joseph, Anoob wrote:
> >> Hi Bruce,
> >>
> >> The reason why l2fwd was chosen was to allow everyone to chip in their ideas
> >> while preparing the framework.
> >> This framework would be extended to other applications, hence needed enough
> >> inputs before expanding to complex applications. If your suggestion is to
> >> make l3fwd event driven first, I'll start looking in that direction.
> > Seems good to me, if others don't have an issue with it.
> >
> >> As for l2fwd, I'm fine with moving event-mode additions to a new app. But
> >> with the present approach, the app would run in both event mode and poll
> >> mode.
> >>
> >> Your thoughts on renaming the existing app to l2fwd-poll and the proposed
> >> app as l2fwd?
> >>
> >> Thanks,
> >> Anoob
> > I'm not sure about the name "poll", I think "ethdev" and "eventdev" should be
> > the suffixes, if we want to move in that direction.
> With new adapters, like crypto adapter, event device will be able to
> handle multiple devices at the same time. It will be able to abstract
> not just eth device but other devices too (crypto for example). For apps
> like ipsec-secgw, crypto also would be abstracted with event-device. So
> what should be the ideal naming convention taking into account all that?
> Using "eth"& "event" won't fit in for such cases.
>
> Presently, mode was defined by the way packets were submitted to &
> received from the device. With poll mode, device(eth, crypto etc) would
> get packets directly from the core & the core would then poll for
> completion. In case of event-mode, event device handles this scheduling.
> Event device would submit (to all devices) and receive packets (from all
> devices). Core need not poll on the device, in that case. Hence the
> naming...
>
> Your thoughts?
I think it is OK to have event mode in examples, in general.
The only concern of Bruce was to keep l2fwd example simple.
So for l2fwd, and only for this one, you can create a new example
called l2fwd-event.
^ permalink raw reply [flat|nested] 83+ messages in thread