Re: [dpdk-dev] [PATCH v4 1/4] ethdev: add the API for getting burst mode information
> -Original Message-
> From: Thomas Monjalon [mailto:tho...@monjalon.net]
> Sent: Saturday, October 26, 2019 14:24
> To: Wang, Haiyue
> Cc: Jerin Jacob ; Yigit, Ferruh
> ; dpdk-dev
> ; Ye, Xiaolong ; Kinsella, Ray
> ;
> Iremonger, Bernard ; Sun, Chenmin
> ; Andrew
> Rybchenko ; Slava Ovsiienko
> ; Stephen Hemminger
> ; David Marchand ;
> Jerin Jacob
>
> Subject: Re: [dpdk-dev] [PATCH v4 1/4] ethdev: add the API for getting burst
> mode information
>
> 26/10/2019 06:40, Wang, Haiyue:
> > From: Thomas Monjalon [mailto:tho...@monjalon.net]
> > > 25/10/2019 18:02, Jerin Jacob:
> > > > On Fri, Oct 25, 2019 at 9:15 PM Thomas Monjalon
> > > > wrote:
> > > > > 25/10/2019 16:08, Ferruh Yigit:
> > > > > > On 10/25/2019 10:36 AM, Thomas Monjalon wrote:
> > > > > > > 15/10/2019 09:51, Haiyue Wang:
> > > > > > >> Some PMDs have more than one RX/TX burst paths, add the ethdev
> > > > > > >> API
> > > > > > >> that allows an application to retrieve the mode information about
> > > > > > >> Rx/Tx packet burst such as Scalar or Vector, and Vector
> > > > > > >> technology
> > > > > > >> like AVX2.
> > > > > > >
> > > > > > > I missed this patch. I and Andrew, maintainers of ethdev, were
> > > > > > > not CC'ed.
> > > > > > > Ferruh, I would expect to be Cc'ed and/or get a notification
> > > > > > > before merging.
> > > > > >
> > > > > > It has been discussed in the mail list and went through multiple
> > > > > > discussions,
> > > > > > patch is out since the August, +1 to cc all maintainers I missed
> > > > > > that part,
> > > > > > but when the patch is reviewed and there is no objection, why block
> > > > > > the merge?
> > > > >
> > > > > I'm not saying blocking the merge.
> > > > > My bad is that I missed the patch and I am asking for help with a
> > > > > notification
> > > > > in this case. Same for Andrew I guess.
> > > > > Note: it is merged in master and I am looking to improve this feature.
> > > >
> > > > > > >> +/**
> > > > > > >> + * Ethernet device RX/TX queue packet burst mode information
> > > > > > >> structure.
> > > > > > >> + * Used to retrieve information about packet burst mode setting.
> > > > > > >> + */
> > > > > > >> +struct rte_eth_burst_mode {
> > > > > > >> + uint64_t options;
> > > > > > >> +};
> > > > > > >
> > > > > > > Why a struct for an integer?
> > > > > >
> > > > > > Again by a request from me, to not need to break the API if we need
> > > > > > to add more
> > > > > > thing in the future.
> > > > >
> > > > > I would replace it with a string. This is the most flexible API.
> > > >
> > > > IMO, Probably, best of both worlds make a good option here,
> > > > as Haiyue suggested if we have an additional dev_specific[1] in
> > > > structure.
> > > > and when a pass to the application, let common code make final string as
> > > > (options flags to string + dev_specific)
> > > >
> > > > options flag can be zero if PMD does not have any generic flags nor
> > > > interested in such a scheme.
> > > > Generic flags will help at least to have some common code.
> > > >
> > > > [1]
> > > > struct rte_eth_burst_mode {
> > > > uint64_t options;
> > > > char dev_specific[128]; /* PMD has specific burst mode
> > > > information */
> > > > };
> > >
> > > I really don't see how we can have generic flags.
> > > The flags which are proposed are just matching
> > > the functions implemented in Intel PMDs.
> > > And this is a complicate solution.
> > > Why not just returning a name for the selected Rx/Tx mode?
> >
> > Intel PMDs use the *generic* methods like x86 SSE, AVX2, ARM NEON, PPC
> > ALTIVEC,
> > 'dev->data->scattered_rx' etc for the target : "DPDK is the Data Plane
> > Development Kit
> > that consists of libraries to accelerate packet processing workloads
> > running on a wide
> > variety of CPU architectures."
>
> How RTE_ETH_BURST_SCATTERED and RTE_ETH_BURST_BULK_ALLOC are generic?
> They just match some features of the Intel PMDs.
> Why not exposing other optimizations of the Rx/Tx implementations?
> You totally missed the point of generic burst mode description.
>
> > If understand these new experimental APIs from above, then bit options is
> > the best,
> > and we didn't invent new words to describe them, just from the CPU & other
> > *generic*
> > technology. And the application can loop to check which kind of burst is
> > running by
> > just simple bit test.
> >
> > If PMDs missed these, they can update them in future roadmaps to enhance
> > their PMDs,
> > like MLX5 supports ARM NEON, x86 SSE.
>
> I have no word!
> You really think other PMDs should learn from Intel how to "enhance" their
> PMD?
> You talk about mlx5, did you look at its code? Did you see the burst modes
> depending on which specific hardware path is used (MPRQ, EMPW, inline)?
> Or depending on which offloads are handled?
>
> Again, the instruction set used by the function is a small part
> of the burst mode optimization.
>
> So you did not reply to my question:
Re: [dpdk-dev] [PATCH v4 1/4] ethdev: add the API for getting burst mode information
> -Original Message-
> From: Slava Ovsiienko [mailto:viachesl...@mellanox.com]
> Sent: Saturday, October 26, 2019 14:41
> To: Thomas Monjalon ; Jerin Jacob
> Cc: Yigit, Ferruh ; Wang, Haiyue
> ; dpdk-dev
> ; Ye, Xiaolong ; Kinsella, Ray
> ;
> Iremonger, Bernard ; Sun, Chenmin
> ; Andrew
> Rybchenko ; Stephen Hemminger
> ; David Marchand
> ; Jerin Jacob
> Subject: RE: [dpdk-dev] [PATCH v4 1/4] ethdev: add the API for getting burst
> mode information
>
>
>
> > -Original Message-
> > From: Thomas Monjalon
> > Sent: Saturday, October 26, 2019 1:27
> > To: Jerin Jacob
> > Cc: Ferruh Yigit ; Haiyue Wang
> > ; dpdk-dev ;
> > xiaolong...@intel.com; ray.kinse...@intel.com; Bernard Iremonger
> > ; chenmin@intel.com; Andrew
> > Rybchenko ; Slava Ovsiienko
> > ; Stephen Hemminger
> > ; David Marchand
> > ; Jerin Jacob
> > Subject: Re: [dpdk-dev] [PATCH v4 1/4] ethdev: add the API for getting burst
> > mode information
> >
> > 25/10/2019 18:02, Jerin Jacob:
> > > On Fri, Oct 25, 2019 at 9:15 PM Thomas Monjalon
> > wrote:
> > > > 25/10/2019 16:08, Ferruh Yigit:
> > > > > On 10/25/2019 10:36 AM, Thomas Monjalon wrote:
> > > > > > 15/10/2019 09:51, Haiyue Wang:
> > > > > >> Some PMDs have more than one RX/TX burst paths, add the ethdev
> > > > > >> API that allows an application to retrieve the mode information
> > > > > >> about Rx/Tx packet burst such as Scalar or Vector, and Vector
> > > > > >> technology like AVX2.
> > > > > >
> > > > > > I missed this patch. I and Andrew, maintainers of ethdev, were not
> > CC'ed.
> > > > > > Ferruh, I would expect to be Cc'ed and/or get a notification before
> > merging.
> > > > >
> > > > > It has been discussed in the mail list and went through multiple
> > > > > discussions, patch is out since the August, +1 to cc all
> > > > > maintainers I missed that part, but when the patch is reviewed and
> > there is no objection, why block the merge?
> > > >
> > > > I'm not saying blocking the merge.
> > > > My bad is that I missed the patch and I am asking for help with a
> > > > notification in this case. Same for Andrew I guess.
> > > > Note: it is merged in master and I am looking to improve this feature.
> > >
> > > > > >> +/**
> > > > > >> + * Ethernet device RX/TX queue packet burst mode information
> > structure.
> > > > > >> + * Used to retrieve information about packet burst mode setting.
> > > > > >> + */
> > > > > >> +struct rte_eth_burst_mode {
> > > > > >> + uint64_t options;
> > > > > >> +};
> > > > > >
> > > > > > Why a struct for an integer?
> > > > >
> > > > > Again by a request from me, to not need to break the API if we
> > > > > need to add more thing in the future.
> > > >
> > > > I would replace it with a string. This is the most flexible API.
> > >
> > > IMO, Probably, best of both worlds make a good option here, as Haiyue
> > > suggested if we have an additional dev_specific[1] in structure.
> > > and when a pass to the application, let common code make final string
> > > as (options flags to string + dev_specific)
> > >
> > > options flag can be zero if PMD does not have any generic flags nor
> > > interested in such a scheme.
> > > Generic flags will help at least to have some common code.
> > >
> > > [1]
> > > struct rte_eth_burst_mode {
> > > uint64_t options;
> > > char dev_specific[128]; /* PMD has specific burst mode
> > > information */ };
> >
> > I really don't see how we can have generic flags.
> > The flags which are proposed are just matching the functions implemented in
> > Intel PMDs.
> > And this is a complicate solution.
> > Why not just returning a name for the selected Rx/Tx mode?
> >
> +1
> Just an example, mlx5 PMD now has approx. 60 tx_burst routines and most of
> these ones
> are not related to vectorized variations (but to tx offloads). Returning the
> name would be more
> flexible and informative.
>
> It is very common case to ask customer about which tx routine is engaged with
> particular settings,
> now we have to ask to build the debug version and present the log.
>
Yes, this API is from that VPP can't get the static function by default compile
options.
Current design is from CPU's view like vectorized, mbuf bulk allocation. We
think it can
be bit data. Name is not good for this, you have to strcat them for different
combinations.
But for hardware specific, name is a good one. We didn't design this API for
this at
first. ;-)
> With best regards, Slava
Re: [dpdk-dev] [PATCH v4 1/4] ethdev: add the API for getting burst mode information
> -Original Message-
> From: Jerin Jacob [mailto:jerinjac...@gmail.com]
> Sent: Saturday, October 26, 2019 14:58
> To: Thomas Monjalon
> Cc: Yigit, Ferruh ; Wang, Haiyue
> ; dpdk-dev
> ; Ye, Xiaolong ; Kinsella, Ray
> ;
> Iremonger, Bernard ; Sun, Chenmin
> ; Andrew
> Rybchenko ; Slava Ovsiienko
> ; Stephen Hemminger
> ; David Marchand ;
> Jerin Jacob
>
> Subject: Re: [dpdk-dev] [PATCH v4 1/4] ethdev: add the API for getting burst
> mode information
>
> On Sat, Oct 26, 2019 at 3:57 AM Thomas Monjalon wrote:
> >
> > 25/10/2019 18:02, Jerin Jacob:
> > > On Fri, Oct 25, 2019 at 9:15 PM Thomas Monjalon
> > > wrote:
> > > > 25/10/2019 16:08, Ferruh Yigit:
> > > > > On 10/25/2019 10:36 AM, Thomas Monjalon wrote:
> > > > > > 15/10/2019 09:51, Haiyue Wang:
> > > > > >> Some PMDs have more than one RX/TX burst paths, add the ethdev API
> > > > > >> that allows an application to retrieve the mode information about
> > > > > >> Rx/Tx packet burst such as Scalar or Vector, and Vector technology
> > > > > >> like AVX2.
> > > > > >
> > > > > > I missed this patch. I and Andrew, maintainers of ethdev, were not
> > > > > > CC'ed.
> > > > > > Ferruh, I would expect to be Cc'ed and/or get a notification before
> > > > > > merging.
> > > > >
> > > > > It has been discussed in the mail list and went through multiple
> > > > > discussions,
> > > > > patch is out since the August, +1 to cc all maintainers I missed that
> > > > > part,
> > > > > but when the patch is reviewed and there is no objection, why block
> > > > > the merge?
> > > >
> > > > I'm not saying blocking the merge.
> > > > My bad is that I missed the patch and I am asking for help with a
> > > > notification
> > > > in this case. Same for Andrew I guess.
> > > > Note: it is merged in master and I am looking to improve this feature.
> > >
> > > > > >> +/**
> > > > > >> + * Ethernet device RX/TX queue packet burst mode information
> > > > > >> structure.
> > > > > >> + * Used to retrieve information about packet burst mode setting.
> > > > > >> + */
> > > > > >> +struct rte_eth_burst_mode {
> > > > > >> + uint64_t options;
> > > > > >> +};
> > > > > >
> > > > > > Why a struct for an integer?
> > > > >
> > > > > Again by a request from me, to not need to break the API if we need
> > > > > to add more
> > > > > thing in the future.
> > > >
> > > > I would replace it with a string. This is the most flexible API.
> > >
> > > IMO, Probably, best of both worlds make a good option here,
> > > as Haiyue suggested if we have an additional dev_specific[1] in structure.
> > > and when a pass to the application, let common code make final string as
> > > (options flags to string + dev_specific)
> > >
> > > options flag can be zero if PMD does not have any generic flags nor
> > > interested in such a scheme.
> > > Generic flags will help at least to have some common code.
> > >
> > > [1]
> > > struct rte_eth_burst_mode {
> > > uint64_t options;
> > > char dev_specific[128]; /* PMD has specific burst mode
> > > information */
> > > };
> >
> > I really don't see how we can have generic flags.
> > The flags which are proposed are just matching
> > the functions implemented in Intel PMDs.
> > And this is a complicate solution.
> > Why not just returning a name for the selected Rx/Tx mode?
>
> +1 only for the name
>
> Let me clarify my earlier proposal:
>
> 1) The public ethdev API should return only "string" i.e the flags
> SHOULD NOT be exposed as ethdev API
> i.e
> int rte_eth_tx_burst_mode_name(uint16_t port_id, uint16_t queue_id, char
> *name);
>
> 2) The PMD interface to the common code can be following
>
> struct eth_pmd_burst_mode {
> uint64_t options;
> char name[128]; /* PMD specific burst mode information */
> };
>
> typedef int (*eth_burst_mode_get_t)(struct rte_eth_dev *dev,
> uint16_t queue_id, struct eth_burst_mode *mode)
>
> 3) The implementation of rte_eth_tx_burst_mode_name() shall do optons
> flag to string converion(again internal to common code implemetation)
> and concatenate with eth_pmd_burst_mode::name
>
> This would help to reuse some of the flags to name conversion logic
> across all PMDs.
> And PMD are free to return eth_pmd_burst_mode::options as zero in
> that case final
> string only be eth_pmd_burst_mode::name.
>
In fact, 'rte_eth_burst_mode_option_name' for single option, not
for struct eth_pmd_burst_mode::option[s]. Need loop to display them.
static void
burst_mode_options_display(uint64_t options)
{
int offset;
while (options != 0) {
offset = rte_bsf64(options);
printf(" %s",
rte_eth_burst_mode_option_name(1ULL << offset));
options &= ~(1ULL << offset);
}
}
But can change the name show like:
if (rte_eth_tx_burst_mode_get(port_id, queue_id, &mode) == 0) {
printf("\nBurst mode:");
burst_mode_options_display(mode.options);
[dpdk-dev] [PATCH v7 02/10] examples/l2fwd-event: add infra for eventdev
From: Pavan Nikhilesh
Add infra to select event device as a mode to process packets through
command line arguments. Also, allow the user to select the schedule type
to be RTE_SCHED_TYPE_ORDERED, RTE_SCHED_TYPE_ATOMIC or
RTE_SCHED_TYPE_PARALLEL.
Usage:
`--mode="eventdev"` or `--mode="poll"`
`--eventq-sched="ordered"`, `--eventq-sched="atomic"` or
`--event-sched=parallel`
Signed-off-by: Sunil Kumar Kori
Signed-off-by: Pavan Nikhilesh
---
examples/l2fwd-event/Makefile | 1 +
examples/l2fwd-event/l2fwd_common.h | 4 +++
examples/l2fwd-event/l2fwd_event.c | 34 +++
examples/l2fwd-event/l2fwd_event.h | 21
examples/l2fwd-event/main.c | 52 +++--
examples/l2fwd-event/meson.build| 1 +
6 files changed, 111 insertions(+), 2 deletions(-)
create mode 100644 examples/l2fwd-event/l2fwd_event.c
create mode 100644 examples/l2fwd-event/l2fwd_event.h
diff --git a/examples/l2fwd-event/Makefile b/examples/l2fwd-event/Makefile
index 73f02dd3b..08ba1835d 100644
--- a/examples/l2fwd-event/Makefile
+++ b/examples/l2fwd-event/Makefile
@@ -8,6 +8,7 @@ APP = l2fwd-event
# all source are stored in SRCS-y
SRCS-y := main.c
SRCS-y += l2fwd_poll.c
+SRCS-y += l2fwd_event.c
SRCS-y += l2fwd_common.c
# Build using pkg-config variables if possible
diff --git a/examples/l2fwd-event/l2fwd_common.h
b/examples/l2fwd-event/l2fwd_common.h
index 7b74f92b3..a4e17ab97 100644
--- a/examples/l2fwd-event/l2fwd_common.h
+++ b/examples/l2fwd-event/l2fwd_common.h
@@ -65,6 +65,8 @@ struct l2fwd_port_statistics {
struct l2fwd_resources {
volatile uint8_t force_quit;
+ uint8_t event_mode;
+ uint8_t sched_type;
uint8_t mac_updating;
uint8_t rx_queue_per_lcore;
uint16_t nb_rxd;
@@ -75,6 +77,7 @@ struct l2fwd_resources {
uint32_t dst_ports[RTE_MAX_ETHPORTS];
struct rte_ether_addr eth_addr[RTE_MAX_ETHPORTS];
struct l2fwd_port_statistics port_stats[RTE_MAX_ETHPORTS];
+ void *evt_rsrc;
void *poll_rsrc;
} __rte_cache_aligned;
@@ -112,6 +115,7 @@ l2fwd_get_rsrc(void)
memset(rsrc, 0, sizeof(struct l2fwd_resources));
rsrc->mac_updating = true;
rsrc->rx_queue_per_lcore = 1;
+ rsrc->sched_type = RTE_SCHED_TYPE_ATOMIC;
rsrc->timer_period = 10 * rte_get_timer_hz();
return mz->addr;
diff --git a/examples/l2fwd-event/l2fwd_event.c
b/examples/l2fwd-event/l2fwd_event.c
new file mode 100644
index 0..48d32d718
--- /dev/null
+++ b/examples/l2fwd-event/l2fwd_event.c
@@ -0,0 +1,34 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(C) 2019 Marvell International Ltd.
+ */
+
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "l2fwd_event.h"
+
+void
+l2fwd_event_resource_setup(struct l2fwd_resources *rsrc)
+{
+ struct l2fwd_event_resources *evt_rsrc;
+
+ if (!rte_event_dev_count())
+ rte_panic("No Eventdev found\n");
+
+ evt_rsrc = rte_zmalloc("l2fwd_event",
+sizeof(struct l2fwd_event_resources), 0);
+ if (evt_rsrc == NULL)
+ rte_panic("Failed to allocate memory\n");
+
+ rsrc->evt_rsrc = evt_rsrc;
+}
diff --git a/examples/l2fwd-event/l2fwd_event.h
b/examples/l2fwd-event/l2fwd_event.h
new file mode 100644
index 0..9a1bb1612
--- /dev/null
+++ b/examples/l2fwd-event/l2fwd_event.h
@@ -0,0 +1,21 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(C) 2019 Marvell International Ltd.
+ */
+
+#ifndef __L2FWD_EVENT_H__
+#define __L2FWD_EVENT_H__
+
+#include
+#include
+#include
+#include
+#include
+
+#include "l2fwd_common.h"
+
+struct l2fwd_event_resources {
+};
+
+void l2fwd_event_resource_setup(struct l2fwd_resources *rsrc);
+
+#endif /* __L2FWD_EVENT_H__ */
diff --git a/examples/l2fwd-event/main.c b/examples/l2fwd-event/main.c
index a4e41ddb4..2a1fe4e11 100644
--- a/examples/l2fwd-event/main.c
+++ b/examples/l2fwd-event/main.c
@@ -2,6 +2,7 @@
* Copyright(C) 2019 Marvell International Ltd.
*/
+#include "l2fwd_event.h"
#include "l2fwd_poll.h"
/* display usage */
@@ -16,7 +17,12 @@ l2fwd_event_usage(const char *prgname)
" --[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",
+ " - The destination MAC address is replaced by
02:00:00:00:00:TX_PORT_ID\n"
+ " --mode: Packet transfer mode for I/O, poll or eventdev\n"
+ " Default mode = eventdev\n"
+ " --eventq-sched: Event queue schedule type, ordered, atomic or
parallel.\n"
+ " Default:
[dpdk-dev] [PATCH v7 00/10] example/l2fwd-event: introduce l2fwd-event example
From: Pavan Nikhilesh This patchset adds a new application to demonstrate the usage of event mode. The poll mode is also available to help with the transition. The following new command line parameters are added: --mode: Dictates the mode of operation either poll or event. --eventq_sched: Dictates event scheduling mode ordered, atomic or parallel. Based on event device capability the configuration is done as follows: - A single event device is enabled. - The number of event ports is equal to the number of worker cores enabled in the core mask. Additional event ports might be configured based on Rx/Tx adapter capability. - The number of event queues is equal to the number of ethernet ports. If Tx adapter doesn't have internal port capability then an additional single link event queue is used to enqueue events to Tx adapter. - Each event port is linked to all existing event queues. - Dedicated Rx/Tx adapters for each Ethernet port. v7 Changes: - Use master core to print stats. - Remove print stats from worker cores. - Add Rx/Tx adapter stats. v6 Changes: - Shorten the structure name `s/event_rsrc/evt_rsrc` `s/l2fwd_rsrc/rsrc`. - Use rte_panic instead of rte_exit. - Rebase on top of Tx adapter change http://patches.dpdk.org/patch/60971. - Update documentation and fix error, spellcheck. - Fix meson build. - Split functions into smaller functions for redability. - Add parallel mode support. v5 Changes: - Redo poll mode datapath by removing all the static globals. - Fix event queue configuration when required queues are not available. - Fix Rx/Tx adapter creation based on portmask. - Update release notes. - Unroll macro used to generate event mode functions. v4 Changes: - Fix missing eventdev args parsing. v3 Changes: - Remove unwanted change to example/l2fwd. - Fix checkpatch issue http://mails.dpdk.org/archives/test-report/2019-September/098053.html v2 Changes: - Remove global variables. - Split patches to make reviews friendlier. - Split datapath based on eventdev capability. Pavan Nikhilesh (5): examples/l2fwd-event: add default poll mode routines examples/l2fwd-event: add infra for eventdev examples/l2fwd-event: add service core setup examples/l2fwd-event: add eventdev main loop examples/l2fwd-event: add graceful teardown Sunil Kumar Kori (5): examples/l2fwd-event: add infra to split eventdev framework examples/l2fwd-event: add event device setup examples/l2fwd-event: add eventdev queue and port setup examples/l2fwd-event: add event Rx/Tx adapter setup doc: add application usage guide for l2fwd-event MAINTAINERS | 6 + doc/guides/rel_notes/release_19_11.rst| 6 + doc/guides/sample_app_ug/index.rst| 1 + doc/guides/sample_app_ug/intro.rst| 5 + doc/guides/sample_app_ug/l2_forward_event.rst | 698 ++ examples/Makefile | 1 + examples/l2fwd-event/Makefile | 62 ++ examples/l2fwd-event/l2fwd_common.c | 97 +++ examples/l2fwd-event/l2fwd_common.h | 132 examples/l2fwd-event/l2fwd_event.c| 393 ++ examples/l2fwd-event/l2fwd_event.h| 73 ++ examples/l2fwd-event/l2fwd_event_generic.c| 315 .../l2fwd-event/l2fwd_event_internal_port.c | 294 examples/l2fwd-event/l2fwd_poll.c | 177 + examples/l2fwd-event/l2fwd_poll.h | 25 + examples/l2fwd-event/main.c | 579 +++ examples/l2fwd-event/meson.build | 18 + examples/meson.build | 2 +- 18 files changed, 2883 insertions(+), 1 deletion(-) create mode 100644 doc/guides/sample_app_ug/l2_forward_event.rst create mode 100644 examples/l2fwd-event/Makefile create mode 100644 examples/l2fwd-event/l2fwd_common.c create mode 100644 examples/l2fwd-event/l2fwd_common.h create mode 100644 examples/l2fwd-event/l2fwd_event.c create mode 100644 examples/l2fwd-event/l2fwd_event.h create mode 100644 examples/l2fwd-event/l2fwd_event_generic.c create mode 100644 examples/l2fwd-event/l2fwd_event_internal_port.c create mode 100644 examples/l2fwd-event/l2fwd_poll.c create mode 100644 examples/l2fwd-event/l2fwd_poll.h create mode 100644 examples/l2fwd-event/main.c create mode 100644 examples/l2fwd-event/meson.build -- 2.17.1
[dpdk-dev] [PATCH v7 04/10] examples/l2fwd-event: add event device setup
From: Sunil Kumar Kori
Add event device device setup based on event eth Tx adapter
capabilities.
Signed-off-by: Sunil Kumar Kori
Signed-off-by: Pavan Nikhilesh
---
examples/l2fwd-event/l2fwd_event.c| 3 +
examples/l2fwd-event/l2fwd_event.h| 16
examples/l2fwd-event/l2fwd_event_generic.c| 75 +-
.../l2fwd-event/l2fwd_event_internal_port.c | 77 ++-
4 files changed, 169 insertions(+), 2 deletions(-)
diff --git a/examples/l2fwd-event/l2fwd_event.c
b/examples/l2fwd-event/l2fwd_event.c
index 7f90e6311..a5c1c2c40 100644
--- a/examples/l2fwd-event/l2fwd_event.c
+++ b/examples/l2fwd-event/l2fwd_event.c
@@ -57,4 +57,7 @@ l2fwd_event_resource_setup(struct l2fwd_resources *rsrc)
/* Setup eventdev capability callbacks */
l2fwd_event_capability_setup(evt_rsrc);
+
+ /* Event device configuration */
+ evt_rsrc->ops.event_device_setup(rsrc);
}
diff --git a/examples/l2fwd-event/l2fwd_event.h
b/examples/l2fwd-event/l2fwd_event.h
index b7aaa39f9..6b5beb041 100644
--- a/examples/l2fwd-event/l2fwd_event.h
+++ b/examples/l2fwd-event/l2fwd_event.h
@@ -13,11 +13,27 @@
#include "l2fwd_common.h"
+typedef uint32_t (*event_device_setup_cb)(struct l2fwd_resources *rsrc);
+
+struct event_queues {
+ uint8_t nb_queues;
+};
+
+struct event_ports {
+ uint8_t nb_ports;
+};
+
struct event_setup_ops {
+ event_device_setup_cb event_device_setup;
};
struct l2fwd_event_resources {
uint8_t tx_mode_q;
+ uint8_t has_burst;
+ uint8_t event_d_id;
+ uint8_t disable_implicit_release;
+ struct event_ports evp;
+ struct event_queues evq;
struct event_setup_ops ops;
};
diff --git a/examples/l2fwd-event/l2fwd_event_generic.c
b/examples/l2fwd-event/l2fwd_event_generic.c
index 9afade7d2..33e570585 100644
--- a/examples/l2fwd-event/l2fwd_event_generic.c
+++ b/examples/l2fwd-event/l2fwd_event_generic.c
@@ -16,8 +16,81 @@
#include "l2fwd_common.h"
#include "l2fwd_event.h"
+static uint32_t
+l2fwd_event_device_setup_generic(struct l2fwd_resources *rsrc)
+{
+ struct l2fwd_event_resources *evt_rsrc = rsrc->evt_rsrc;
+ struct rte_event_dev_config event_d_conf = {
+ .nb_events_limit = 4096,
+ .nb_event_queue_flows = 1024,
+ .nb_event_port_dequeue_depth = 128,
+ .nb_event_port_enqueue_depth = 128
+ };
+ struct rte_event_dev_info dev_info;
+ const uint8_t event_d_id = 0; /* Always use first event device only */
+ uint32_t event_queue_cfg = 0;
+ uint16_t ethdev_count = 0;
+ uint16_t num_workers = 0;
+ uint16_t port_id;
+ int ret;
+
+ RTE_ETH_FOREACH_DEV(port_id) {
+ if ((rsrc->enabled_port_mask & (1 << port_id)) == 0)
+ continue;
+ ethdev_count++;
+ }
+
+ /* Event device configurtion */
+ rte_event_dev_info_get(event_d_id, &dev_info);
+ evt_rsrc->disable_implicit_release = !!(dev_info.event_dev_cap &
+ RTE_EVENT_DEV_CAP_IMPLICIT_RELEASE_DISABLE);
+
+ if (dev_info.event_dev_cap & RTE_EVENT_DEV_CAP_QUEUE_ALL_TYPES)
+ event_queue_cfg |= RTE_EVENT_QUEUE_CFG_ALL_TYPES;
+
+ /* One queue for each ethdev port + one Tx adapter Single link queue. */
+ event_d_conf.nb_event_queues = ethdev_count + 1;
+ if (dev_info.max_event_queues < event_d_conf.nb_event_queues)
+ event_d_conf.nb_event_queues = dev_info.max_event_queues;
+
+ if (dev_info.max_num_events < event_d_conf.nb_events_limit)
+ event_d_conf.nb_events_limit = dev_info.max_num_events;
+
+ if (dev_info.max_event_queue_flows < event_d_conf.nb_event_queue_flows)
+ event_d_conf.nb_event_queue_flows =
+ dev_info.max_event_queue_flows;
+
+ if (dev_info.max_event_port_dequeue_depth <
+ event_d_conf.nb_event_port_dequeue_depth)
+ event_d_conf.nb_event_port_dequeue_depth =
+ dev_info.max_event_port_dequeue_depth;
+
+ if (dev_info.max_event_port_enqueue_depth <
+ event_d_conf.nb_event_port_enqueue_depth)
+ event_d_conf.nb_event_port_enqueue_depth =
+ dev_info.max_event_port_enqueue_depth;
+
+ num_workers = rte_lcore_count() - rte_service_lcore_count();
+ if (dev_info.max_event_ports < num_workers)
+ num_workers = dev_info.max_event_ports;
+
+ event_d_conf.nb_event_ports = num_workers;
+ evt_rsrc->evp.nb_ports = num_workers;
+ evt_rsrc->evq.nb_queues = event_d_conf.nb_event_queues;
+
+ evt_rsrc->has_burst = !!(dev_info.event_dev_cap &
+ RTE_EVENT_DEV_CAP_BURST_MODE);
+
+ ret = rte_event_dev_configure(event_d_id, &event_d_conf);
+ if (r
[dpdk-dev] [PATCH v7 01/10] examples/l2fwd-event: add default poll mode routines
From: Pavan Nikhilesh
Add the default l2fwd poll mode routines similar to examples/l2fwd.
Signed-off-by: Sunil Kumar Kori
Signed-off-by: Pavan Nikhilesh
---
MAINTAINERS | 5 +
examples/Makefile | 1 +
examples/l2fwd-event/Makefile | 59
examples/l2fwd-event/l2fwd_common.c | 91 ++
examples/l2fwd-event/l2fwd_common.h | 127
examples/l2fwd-event/l2fwd_poll.c | 177 +++
examples/l2fwd-event/l2fwd_poll.h | 25 ++
examples/l2fwd-event/main.c | 446
examples/l2fwd-event/meson.build| 15 +
examples/meson.build| 2 +-
10 files changed, 947 insertions(+), 1 deletion(-)
create mode 100644 examples/l2fwd-event/Makefile
create mode 100644 examples/l2fwd-event/l2fwd_common.c
create mode 100644 examples/l2fwd-event/l2fwd_common.h
create mode 100644 examples/l2fwd-event/l2fwd_poll.c
create mode 100644 examples/l2fwd-event/l2fwd_poll.h
create mode 100644 examples/l2fwd-event/main.c
create mode 100644 examples/l2fwd-event/meson.build
diff --git a/MAINTAINERS b/MAINTAINERS
index f8a56e2e2..6957b2a24 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1475,6 +1475,11 @@ M: Tomasz Kantecki
F: doc/guides/sample_app_ug/l2_forward_cat.rst
F: examples/l2fwd-cat/
+M: Sunil Kumar Kori
+M: Pavan Nikhilesh
+F: examples/l2fwd-event/
+T: git://dpdk.org/next/dpdk-next-eventdev
+
F: examples/l3fwd/
F: doc/guides/sample_app_ug/l3_forward.rst
diff --git a/examples/Makefile b/examples/Makefile
index de11dd487..d18504bd2 100644
--- a/examples/Makefile
+++ b/examples/Makefile
@@ -34,6 +34,7 @@ endif
DIRS-$(CONFIG_RTE_LIBRTE_HASH) += ipv4_multicast
DIRS-$(CONFIG_RTE_LIBRTE_KNI) += kni
DIRS-y += l2fwd
+DIRS-y += l2fwd-event
ifneq ($(PQOS_INSTALL_PATH),)
DIRS-y += l2fwd-cat
endif
diff --git a/examples/l2fwd-event/Makefile b/examples/l2fwd-event/Makefile
new file mode 100644
index 0..73f02dd3b
--- /dev/null
+++ b/examples/l2fwd-event/Makefile
@@ -0,0 +1,59 @@
+# SPDX-License-Identifier: BSD-3-Clause
+# Copyright(C) 2019 Marvell International Ltd.
+#
+
+# binary name
+APP = l2fwd-event
+
+# all source are stored in SRCS-y
+SRCS-y := main.c
+SRCS-y += l2fwd_poll.c
+SRCS-y += l2fwd_common.c
+
+# Build using pkg-config variables if possible
+ifeq ($(shell pkg-config --exists libdpdk && echo 0),0)
+
+all: shared
+.PHONY: shared static
+shared: build/$(APP)-shared
+ ln -sf $(APP)-shared build/$(APP)
+static: build/$(APP)-static
+ ln -sf $(APP)-static build/$(APP)
+
+PKGCONF=pkg-config --define-prefix
+
+PC_FILE := $(shell $(PKGCONF) --path libdpdk)
+CFLAGS += -O3 $(shell $(PKGCONF) --cflags libdpdk)
+LDFLAGS_SHARED = $(shell $(PKGCONF) --libs libdpdk)
+LDFLAGS_STATIC = -Wl,-Bstatic $(shell $(PKGCONF) --static --libs libdpdk)
+
+build/$(APP)-shared: $(SRCS-y) Makefile $(PC_FILE) | build
+ $(CC) $(CFLAGS) $(SRCS-y) -o $@ $(LDFLAGS) $(LDFLAGS_SHARED)
+
+build/$(APP)-static: $(SRCS-y) Makefile $(PC_FILE) | build
+ $(CC) $(CFLAGS) $(SRCS-y) -o $@ $(LDFLAGS) $(LDFLAGS_STATIC)
+
+build:
+ @mkdir -p $@
+
+.PHONY: clean
+clean:
+ rm -f build/$(APP) build/$(APP)-static build/$(APP)-shared
+ test -d build && rmdir -p build || true
+
+else # Build using legacy build system
+
+ifeq ($(RTE_SDK),)
+$(error "Please define RTE_SDK environment variable")
+endif
+
+# Default target, detect a build directory, by looking for a path with a
.config
+RTE_TARGET ?= $(notdir $(abspath $(dir $(firstword $(wildcard
$(RTE_SDK)/*/.config)
+
+include $(RTE_SDK)/mk/rte.vars.mk
+
+CFLAGS += -O3
+CFLAGS += $(WERROR_FLAGS)
+
+include $(RTE_SDK)/mk/rte.extapp.mk
+endif
diff --git a/examples/l2fwd-event/l2fwd_common.c
b/examples/l2fwd-event/l2fwd_common.c
new file mode 100644
index 0..c206415d0
--- /dev/null
+++ b/examples/l2fwd-event/l2fwd_common.c
@@ -0,0 +1,91 @@
+#include "l2fwd_common.h"
+
+int
+l2fwd_event_init_ports(struct l2fwd_resources *rsrc)
+{
+ uint16_t nb_rxd = RTE_TEST_RX_DESC_DEFAULT;
+ uint16_t nb_txd = RTE_TEST_TX_DESC_DEFAULT;
+ struct rte_eth_conf port_conf = {
+ .rxmode = {
+ .max_rx_pkt_len = RTE_ETHER_MAX_LEN,
+ .split_hdr_size = 0,
+ },
+ .txmode = {
+ .mq_mode = ETH_MQ_TX_NONE,
+ },
+ };
+ uint16_t nb_ports_available = 0;
+ uint16_t port_id;
+ int ret;
+
+ /* Initialise each port */
+ RTE_ETH_FOREACH_DEV(port_id) {
+ struct rte_eth_conf local_port_conf = port_conf;
+ struct rte_eth_dev_info dev_info;
+ struct rte_eth_rxconf rxq_conf;
+ struct rte_eth_txconf txq_conf;
+
+ /* skip ports that are not enabled */
+ if ((rsrc->enabled_port_mask & (1 << port_id)) == 0) {
+ printf("Skipping disabled port %u\n", port_id);
+ continue;
+
[dpdk-dev] [PATCH v7 06/10] examples/l2fwd-event: add event Rx/Tx adapter setup
From: Sunil Kumar Kori
Add event eth Rx/Tx adapter setup for both generic and internal port
event device pipelines.
Signed-off-by: Sunil Kumar Kori
Signed-off-by: Pavan Nikhilesh
---
examples/l2fwd-event/l2fwd_event.c| 3 +
examples/l2fwd-event/l2fwd_event.h| 16 +++
examples/l2fwd-event/l2fwd_event_generic.c| 115 ++
.../l2fwd-event/l2fwd_event_internal_port.c | 96 +++
4 files changed, 230 insertions(+)
diff --git a/examples/l2fwd-event/l2fwd_event.c
b/examples/l2fwd-event/l2fwd_event.c
index 8dd00a6d3..33c702739 100644
--- a/examples/l2fwd-event/l2fwd_event.c
+++ b/examples/l2fwd-event/l2fwd_event.c
@@ -67,4 +67,7 @@ l2fwd_event_resource_setup(struct l2fwd_resources *rsrc)
/* Event port configuration */
evt_rsrc->ops.event_port_setup(rsrc);
+
+ /* Rx/Tx adapters configuration */
+ evt_rsrc->ops.adapter_setup(rsrc);
}
diff --git a/examples/l2fwd-event/l2fwd_event.h
b/examples/l2fwd-event/l2fwd_event.h
index fe7857cdf..1d7090ddf 100644
--- a/examples/l2fwd-event/l2fwd_event.h
+++ b/examples/l2fwd-event/l2fwd_event.h
@@ -17,6 +17,7 @@ typedef uint32_t (*event_device_setup_cb)(struct
l2fwd_resources *rsrc);
typedef void (*event_port_setup_cb)(struct l2fwd_resources *rsrc);
typedef void (*event_queue_setup_cb)(struct l2fwd_resources *rsrc,
uint32_t event_queue_cfg);
+typedef void (*adapter_setup_cb)(struct l2fwd_resources *rsrc);
struct event_queues {
uint8_t *event_q_id;
@@ -29,10 +30,23 @@ struct event_ports {
rte_spinlock_t lock;
};
+struct event_rx_adptr {
+ uint32_t service_id;
+ uint8_t nb_rx_adptr;
+ uint8_t *rx_adptr;
+};
+
+struct event_tx_adptr {
+ uint32_t service_id;
+ uint8_t nb_tx_adptr;
+ uint8_t *tx_adptr;
+};
+
struct event_setup_ops {
event_device_setup_cb event_device_setup;
event_queue_setup_cb event_queue_setup;
event_port_setup_cb event_port_setup;
+ adapter_setup_cb adapter_setup;
};
struct l2fwd_event_resources {
@@ -44,6 +58,8 @@ struct l2fwd_event_resources {
struct event_ports evp;
struct event_queues evq;
struct event_setup_ops ops;
+ struct event_rx_adptr rx_adptr;
+ struct event_tx_adptr tx_adptr;
struct rte_event_port_conf def_p_conf;
};
diff --git a/examples/l2fwd-event/l2fwd_event_generic.c
b/examples/l2fwd-event/l2fwd_event_generic.c
index f72d21c0b..f99608173 100644
--- a/examples/l2fwd-event/l2fwd_event_generic.c
+++ b/examples/l2fwd-event/l2fwd_event_generic.c
@@ -191,10 +191,125 @@ l2fwd_event_queue_setup_generic(struct l2fwd_resources
*rsrc,
evt_rsrc->evq.event_q_id[event_q_id] = event_q_id;
}
+static void
+l2fwd_rx_tx_adapter_setup_generic(struct l2fwd_resources *rsrc)
+{
+ struct l2fwd_event_resources *evt_rsrc = rsrc->evt_rsrc;
+ struct rte_event_eth_rx_adapter_queue_conf eth_q_conf = {
+ .rx_queue_flags = 0,
+ .ev = {
+ .queue_id = 0,
+ .priority = RTE_EVENT_DEV_PRIORITY_NORMAL,
+ }
+ };
+ uint8_t event_d_id = evt_rsrc->event_d_id;
+ uint8_t rx_adptr_id = 0;
+ uint8_t tx_adptr_id = 0;
+ uint8_t tx_port_id = 0;
+ uint16_t port_id;
+ uint32_t service_id;
+ int32_t ret, i = 0;
+
+ /* Rx adapter setup */
+ evt_rsrc->rx_adptr.nb_rx_adptr = 1;
+ evt_rsrc->rx_adptr.rx_adptr = (uint8_t *)malloc(sizeof(uint8_t) *
+ evt_rsrc->rx_adptr.nb_rx_adptr);
+ if (!evt_rsrc->rx_adptr.rx_adptr) {
+ free(evt_rsrc->evp.event_p_id);
+ free(evt_rsrc->evq.event_q_id);
+ rte_panic("Failed to allocate memery for Rx adapter\n");
+ }
+
+ ret = rte_event_eth_rx_adapter_create(rx_adptr_id, event_d_id,
+ &evt_rsrc->def_p_conf);
+ if (ret)
+ rte_panic("Failed to create rx adapter\n");
+
+ /* Configure user requested sched type */
+ eth_q_conf.ev.sched_type = rsrc->sched_type;
+ RTE_ETH_FOREACH_DEV(port_id) {
+ if ((rsrc->enabled_port_mask & (1 << port_id)) == 0)
+ continue;
+ eth_q_conf.ev.queue_id = evt_rsrc->evq.event_q_id[i];
+ ret = rte_event_eth_rx_adapter_queue_add(rx_adptr_id, port_id,
+-1, ð_q_conf);
+ if (ret)
+ rte_panic("Failed to add queues to Rx adapter\n");
+ if (i < evt_rsrc->evq.nb_queues)
+ i++;
+ }
+
+ ret = rte_event_eth_rx_adapter_service_id_get(rx_adptr_id, &service_id);
+ if (ret != -ESRCH && ret != 0)
+ rte_panic("Error getting the service ID for rx adptr\n");
+
+ rte_service_runstate_set(service_id, 1);
+ rte_service_
[dpdk-dev] [PATCH v7 08/10] examples/l2fwd-event: add eventdev main loop
From: Pavan Nikhilesh
Add event dev main loop based on enabled l2fwd options and eventdev
capabilities.
Signed-off-by: Pavan Nikhilesh
---
examples/l2fwd-event/l2fwd_common.c | 6 +
examples/l2fwd-event/l2fwd_common.h | 1 +
examples/l2fwd-event/l2fwd_event.c | 238
examples/l2fwd-event/l2fwd_event.h | 2 +
examples/l2fwd-event/main.c | 68 +++-
5 files changed, 307 insertions(+), 8 deletions(-)
diff --git a/examples/l2fwd-event/l2fwd_common.c
b/examples/l2fwd-event/l2fwd_common.c
index c206415d0..4ba788550 100644
--- a/examples/l2fwd-event/l2fwd_common.c
+++ b/examples/l2fwd-event/l2fwd_common.c
@@ -18,6 +18,12 @@ l2fwd_event_init_ports(struct l2fwd_resources *rsrc)
uint16_t port_id;
int ret;
+ if (rsrc->event_mode) {
+ port_conf.rxmode.mq_mode = ETH_MQ_RX_RSS;
+ port_conf.rx_adv_conf.rss_conf.rss_key = NULL;
+ port_conf.rx_adv_conf.rss_conf.rss_hf = ETH_RSS_IP;
+ }
+
/* Initialise each port */
RTE_ETH_FOREACH_DEV(port_id) {
struct rte_eth_conf local_port_conf = port_conf;
diff --git a/examples/l2fwd-event/l2fwd_common.h
b/examples/l2fwd-event/l2fwd_common.h
index a4e17ab97..7e33ee749 100644
--- a/examples/l2fwd-event/l2fwd_common.h
+++ b/examples/l2fwd-event/l2fwd_common.h
@@ -114,6 +114,7 @@ l2fwd_get_rsrc(void)
memset(rsrc, 0, sizeof(struct l2fwd_resources));
rsrc->mac_updating = true;
+ rsrc->event_mode = true;
rsrc->rx_queue_per_lcore = 1;
rsrc->sched_type = RTE_SCHED_TYPE_ATOMIC;
rsrc->timer_period = 10 * rte_get_timer_hz();
diff --git a/examples/l2fwd-event/l2fwd_event.c
b/examples/l2fwd-event/l2fwd_event.c
index 562d61292..c7782cbc5 100644
--- a/examples/l2fwd-event/l2fwd_event.c
+++ b/examples/l2fwd-event/l2fwd_event.c
@@ -17,6 +17,12 @@
#include "l2fwd_event.h"
+#define L2FWD_EVENT_SINGLE 0x1
+#define L2FWD_EVENT_BURST 0x2
+#define L2FWD_EVENT_TX_DIRECT 0x4
+#define L2FWD_EVENT_TX_ENQ 0x8
+#define L2FWD_EVENT_UPDT_MAC 0x10
+
static inline int
l2fwd_event_service_enable(uint32_t service_id)
{
@@ -122,11 +128,233 @@ l2fwd_event_capability_setup(struct
l2fwd_event_resources *evt_rsrc)
l2fwd_event_set_internal_port_ops(&evt_rsrc->ops);
}
+static __rte_noinline int
+l2fwd_get_free_event_port(struct l2fwd_event_resources *evt_rsrc)
+{
+ static int index;
+ int port_id;
+
+ rte_spinlock_lock(&evt_rsrc->evp.lock);
+ if (index >= evt_rsrc->evp.nb_ports) {
+ printf("No free event port is available\n");
+ return -1;
+ }
+
+ port_id = evt_rsrc->evp.event_p_id[index];
+ index++;
+ rte_spinlock_unlock(&evt_rsrc->evp.lock);
+
+ return port_id;
+}
+
+static __rte_always_inline void
+l2fwd_event_fwd(struct l2fwd_resources *rsrc, struct rte_event *ev,
+ const uint8_t tx_q_id, const uint64_t timer_period,
+ const uint32_t flags)
+{
+ struct rte_mbuf *mbuf = ev->mbuf;
+ uint16_t dst_port;
+
+ rte_prefetch0(rte_pktmbuf_mtod(mbuf, void *));
+ dst_port = rsrc->dst_ports[mbuf->port];
+
+ if (timer_period > 0)
+ __atomic_fetch_add(&rsrc->port_stats[mbuf->port].rx,
+ 1, __ATOMIC_RELAXED);
+ mbuf->port = dst_port;
+
+ if (flags & L2FWD_EVENT_UPDT_MAC)
+ l2fwd_mac_updating(mbuf, dst_port, &rsrc->eth_addr[dst_port]);
+
+ if (flags & L2FWD_EVENT_TX_ENQ) {
+ ev->queue_id = tx_q_id;
+ ev->op = RTE_EVENT_OP_FORWARD;
+ }
+
+ if (flags & L2FWD_EVENT_TX_DIRECT)
+ rte_event_eth_tx_adapter_txq_set(mbuf, 0);
+
+ if (timer_period > 0)
+ __atomic_fetch_add(&rsrc->port_stats[mbuf->port].tx,
+ 1, __ATOMIC_RELAXED);
+}
+
+static __rte_always_inline void
+l2fwd_event_loop_single(struct l2fwd_resources *rsrc,
+ const uint32_t flags)
+{
+ struct l2fwd_event_resources *evt_rsrc = rsrc->evt_rsrc;
+ const int port_id = l2fwd_get_free_event_port(evt_rsrc);
+ const uint8_t tx_q_id = evt_rsrc->evq.event_q_id[
+ evt_rsrc->evq.nb_queues - 1];
+ const uint64_t timer_period = rsrc->timer_period;
+ const uint8_t event_d_id = evt_rsrc->event_d_id;
+ struct rte_event ev;
+
+ if (port_id < 0)
+ return;
+
+ printf("%s(): entering eventdev main loop on lcore %u\n", __func__,
+ rte_lcore_id());
+
+ while (!rsrc->force_quit) {
+ /* Read packet from eventdev */
+ if (!rte_event_dequeue_burst(event_d_id, port_id, &ev, 1, 0))
+ continue;
+
+ l2fwd_event_fwd(rsrc, &ev, tx_q_id, timer_period, flags);
+
+ if (flags & L2FWD_EVENT_TX_ENQ)
[dpdk-dev] [PATCH v7 03/10] examples/l2fwd-event: add infra to split eventdev framework
From: Sunil Kumar Kori
Add infra to split eventdev framework based on event Tx adapter
capability.
If event Tx adapter has internal port capability then we use
`rte_event_eth_tx_adapter_enqueue` to transmitting packets else
we use a SINGLE_LINK event queue to enqueue packets to a service
core which is responsible for transmitting packets.
Signed-off-by: Sunil Kumar Kori
Signed-off-by: Pavan Nikhilesh
---
examples/l2fwd-event/Makefile | 2 ++
examples/l2fwd-event/l2fwd_event.c| 26 +++
examples/l2fwd-event/l2fwd_event.h| 7 +
examples/l2fwd-event/l2fwd_event_generic.c| 23
.../l2fwd-event/l2fwd_event_internal_port.c | 23
examples/l2fwd-event/meson.build | 2 ++
6 files changed, 83 insertions(+)
create mode 100644 examples/l2fwd-event/l2fwd_event_generic.c
create mode 100644 examples/l2fwd-event/l2fwd_event_internal_port.c
diff --git a/examples/l2fwd-event/Makefile b/examples/l2fwd-event/Makefile
index 08ba1835d..6f4176882 100644
--- a/examples/l2fwd-event/Makefile
+++ b/examples/l2fwd-event/Makefile
@@ -10,6 +10,8 @@ SRCS-y := main.c
SRCS-y += l2fwd_poll.c
SRCS-y += l2fwd_event.c
SRCS-y += l2fwd_common.c
+SRCS-y += l2fwd_event_generic.c
+SRCS-y += l2fwd_event_internal_port.c
# Build using pkg-config variables if possible
ifeq ($(shell pkg-config --exists libdpdk && echo 0),0)
diff --git a/examples/l2fwd-event/l2fwd_event.c
b/examples/l2fwd-event/l2fwd_event.c
index 48d32d718..7f90e6311 100644
--- a/examples/l2fwd-event/l2fwd_event.c
+++ b/examples/l2fwd-event/l2fwd_event.c
@@ -17,6 +17,29 @@
#include "l2fwd_event.h"
+static void
+l2fwd_event_capability_setup(struct l2fwd_event_resources *evt_rsrc)
+{
+ uint32_t caps = 0;
+ uint16_t i;
+ int ret;
+
+ RTE_ETH_FOREACH_DEV(i) {
+ ret = rte_event_eth_tx_adapter_caps_get(0, i, &caps);
+ if (ret)
+ rte_panic("Invalid capability for Tx adptr port %d\n",
+ i);
+
+ evt_rsrc->tx_mode_q |= !(caps &
+ RTE_EVENT_ETH_TX_ADAPTER_CAP_INTERNAL_PORT);
+ }
+
+ if (evt_rsrc->tx_mode_q)
+ l2fwd_event_set_generic_ops(&evt_rsrc->ops);
+ else
+ l2fwd_event_set_internal_port_ops(&evt_rsrc->ops);
+}
+
void
l2fwd_event_resource_setup(struct l2fwd_resources *rsrc)
{
@@ -31,4 +54,7 @@ l2fwd_event_resource_setup(struct l2fwd_resources *rsrc)
rte_panic("Failed to allocate memory\n");
rsrc->evt_rsrc = evt_rsrc;
+
+ /* Setup eventdev capability callbacks */
+ l2fwd_event_capability_setup(evt_rsrc);
}
diff --git a/examples/l2fwd-event/l2fwd_event.h
b/examples/l2fwd-event/l2fwd_event.h
index 9a1bb1612..b7aaa39f9 100644
--- a/examples/l2fwd-event/l2fwd_event.h
+++ b/examples/l2fwd-event/l2fwd_event.h
@@ -13,9 +13,16 @@
#include "l2fwd_common.h"
+struct event_setup_ops {
+};
+
struct l2fwd_event_resources {
+ uint8_t tx_mode_q;
+ struct event_setup_ops ops;
};
void l2fwd_event_resource_setup(struct l2fwd_resources *rsrc);
+void l2fwd_event_set_generic_ops(struct event_setup_ops *ops);
+void l2fwd_event_set_internal_port_ops(struct event_setup_ops *ops);
#endif /* __L2FWD_EVENT_H__ */
diff --git a/examples/l2fwd-event/l2fwd_event_generic.c
b/examples/l2fwd-event/l2fwd_event_generic.c
new file mode 100644
index 0..9afade7d2
--- /dev/null
+++ b/examples/l2fwd-event/l2fwd_event_generic.c
@@ -0,0 +1,23 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(C) 2019 Marvell International Ltd.
+ */
+
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "l2fwd_common.h"
+#include "l2fwd_event.h"
+
+void
+l2fwd_event_set_generic_ops(struct event_setup_ops *ops)
+{
+ RTE_SET_USED(ops);
+}
diff --git a/examples/l2fwd-event/l2fwd_event_internal_port.c
b/examples/l2fwd-event/l2fwd_event_internal_port.c
new file mode 100644
index 0..ce95b8e6d
--- /dev/null
+++ b/examples/l2fwd-event/l2fwd_event_internal_port.c
@@ -0,0 +1,23 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(C) 2019 Marvell International Ltd.
+ */
+
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "l2fwd_common.h"
+#include "l2fwd_event.h"
+
+void
+l2fwd_event_set_internal_port_ops(struct event_setup_ops *ops)
+{
+ RTE_SET_USED(ops);
+}
diff --git a/examples/l2fwd-event/meson.build b/examples/l2fwd-event/meson.build
index c1ae2037c..4e9a069d6 100644
--- a/examples/l2fwd-event/meson.build
+++ b/examples/l2fwd-event/meson.build
@@ -13,4 +13,6 @@ sources = files(
'l2fwd_poll.c',
'l2fwd_common.c',
'l2fwd_event.c',
+ 'l2fwd_event_internal_port.c',
+ 'l2fwd_event_generic.c'
)
--
2.17.1
[dpdk-dev] [PATCH v7 05/10] examples/l2fwd-event: add eventdev queue and port setup
From: Sunil Kumar Kori
Add event device queue and port setup based on event eth Tx adapter
capabilities.
Signed-off-by: Sunil Kumar Kori
Signed-off-by: Pavan Nikhilesh
---
examples/l2fwd-event/l2fwd_event.c| 9 +-
examples/l2fwd-event/l2fwd_event.h| 10 ++
examples/l2fwd-event/l2fwd_event_generic.c| 104 ++
.../l2fwd-event/l2fwd_event_internal_port.c | 100 +
4 files changed, 222 insertions(+), 1 deletion(-)
diff --git a/examples/l2fwd-event/l2fwd_event.c
b/examples/l2fwd-event/l2fwd_event.c
index a5c1c2c40..8dd00a6d3 100644
--- a/examples/l2fwd-event/l2fwd_event.c
+++ b/examples/l2fwd-event/l2fwd_event.c
@@ -44,6 +44,7 @@ void
l2fwd_event_resource_setup(struct l2fwd_resources *rsrc)
{
struct l2fwd_event_resources *evt_rsrc;
+ uint32_t event_queue_cfg;
if (!rte_event_dev_count())
rte_panic("No Eventdev found\n");
@@ -59,5 +60,11 @@ l2fwd_event_resource_setup(struct l2fwd_resources *rsrc)
l2fwd_event_capability_setup(evt_rsrc);
/* Event device configuration */
- evt_rsrc->ops.event_device_setup(rsrc);
+ event_queue_cfg = evt_rsrc->ops.event_device_setup(rsrc);
+
+ /* Event queue configuration */
+ evt_rsrc->ops.event_queue_setup(rsrc, event_queue_cfg);
+
+ /* Event port configuration */
+ evt_rsrc->ops.event_port_setup(rsrc);
}
diff --git a/examples/l2fwd-event/l2fwd_event.h
b/examples/l2fwd-event/l2fwd_event.h
index 6b5beb041..fe7857cdf 100644
--- a/examples/l2fwd-event/l2fwd_event.h
+++ b/examples/l2fwd-event/l2fwd_event.h
@@ -14,27 +14,37 @@
#include "l2fwd_common.h"
typedef uint32_t (*event_device_setup_cb)(struct l2fwd_resources *rsrc);
+typedef void (*event_port_setup_cb)(struct l2fwd_resources *rsrc);
+typedef void (*event_queue_setup_cb)(struct l2fwd_resources *rsrc,
+uint32_t event_queue_cfg);
struct event_queues {
+ uint8_t *event_q_id;
uint8_t nb_queues;
};
struct event_ports {
+ uint8_t *event_p_id;
uint8_t nb_ports;
+ rte_spinlock_t lock;
};
struct event_setup_ops {
event_device_setup_cb event_device_setup;
+ event_queue_setup_cb event_queue_setup;
+ event_port_setup_cb event_port_setup;
};
struct l2fwd_event_resources {
uint8_t tx_mode_q;
+ uint8_t deq_depth;
uint8_t has_burst;
uint8_t event_d_id;
uint8_t disable_implicit_release;
struct event_ports evp;
struct event_queues evq;
struct event_setup_ops ops;
+ struct rte_event_port_conf def_p_conf;
};
void l2fwd_event_resource_setup(struct l2fwd_resources *rsrc);
diff --git a/examples/l2fwd-event/l2fwd_event_generic.c
b/examples/l2fwd-event/l2fwd_event_generic.c
index 33e570585..f72d21c0b 100644
--- a/examples/l2fwd-event/l2fwd_event_generic.c
+++ b/examples/l2fwd-event/l2fwd_event_generic.c
@@ -89,8 +89,112 @@ l2fwd_event_device_setup_generic(struct l2fwd_resources
*rsrc)
return event_queue_cfg;
}
+static void
+l2fwd_event_port_setup_generic(struct l2fwd_resources *rsrc)
+{
+ struct l2fwd_event_resources *evt_rsrc = rsrc->evt_rsrc;
+ uint8_t event_d_id = evt_rsrc->event_d_id;
+ struct rte_event_port_conf event_p_conf = {
+ .dequeue_depth = 32,
+ .enqueue_depth = 32,
+ .new_event_threshold = 4096
+ };
+ struct rte_event_port_conf def_p_conf;
+ uint8_t event_p_id;
+ int32_t ret;
+
+ evt_rsrc->evp.event_p_id = (uint8_t *)malloc(sizeof(uint8_t) *
+ evt_rsrc->evp.nb_ports);
+ if (!evt_rsrc->evp.event_p_id)
+ rte_panic("No space is available\n");
+
+ memset(&def_p_conf, 0, sizeof(struct rte_event_port_conf));
+ rte_event_port_default_conf_get(event_d_id, 0, &def_p_conf);
+
+ if (def_p_conf.new_event_threshold < event_p_conf.new_event_threshold)
+ event_p_conf.new_event_threshold =
+ def_p_conf.new_event_threshold;
+
+ if (def_p_conf.dequeue_depth < event_p_conf.dequeue_depth)
+ event_p_conf.dequeue_depth = def_p_conf.dequeue_depth;
+
+ if (def_p_conf.enqueue_depth < event_p_conf.enqueue_depth)
+ event_p_conf.enqueue_depth = def_p_conf.enqueue_depth;
+
+ event_p_conf.disable_implicit_release =
+ evt_rsrc->disable_implicit_release;
+ evt_rsrc->deq_depth = def_p_conf.dequeue_depth;
+
+ for (event_p_id = 0; event_p_id < evt_rsrc->evp.nb_ports;
+ event_p_id++) {
+ ret = rte_event_port_setup(event_d_id, event_p_id,
+ &event_p_conf);
+ if (ret < 0)
+ rte_panic("Error in configuring event port %d\n",
+ event_p_id);
+
+ ret = rte_event_p
[dpdk-dev] [PATCH v7 10/10] doc: add application usage guide for l2fwd-event
From: Sunil Kumar Kori Add documentation for l2fwd-event example. Update release notes. Signed-off-by: Sunil Kumar Kori --- MAINTAINERS | 1 + doc/guides/rel_notes/release_19_11.rst| 6 + doc/guides/sample_app_ug/index.rst| 1 + doc/guides/sample_app_ug/intro.rst| 5 + doc/guides/sample_app_ug/l2_forward_event.rst | 698 ++ 5 files changed, 711 insertions(+) create mode 100644 doc/guides/sample_app_ug/l2_forward_event.rst diff --git a/MAINTAINERS b/MAINTAINERS index 6957b2a24..8898ff252 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1478,6 +1478,7 @@ F: examples/l2fwd-cat/ M: Sunil Kumar Kori M: Pavan Nikhilesh F: examples/l2fwd-event/ +F: doc/guides/sample_app_ug/l2_forward_event.rst T: git://dpdk.org/next/dpdk-next-eventdev F: examples/l3fwd/ diff --git a/doc/guides/rel_notes/release_19_11.rst b/doc/guides/rel_notes/release_19_11.rst index 08dafa76f..c8e9158af 100644 --- a/doc/guides/rel_notes/release_19_11.rst +++ b/doc/guides/rel_notes/release_19_11.rst @@ -115,6 +115,12 @@ New Features Added eBPF JIT support for arm64 architecture to improve the eBPF program performance. +* **Added new example l2fwd-event application.** + + Added an example application `l2fwd-event` that adds event device support to + traditional l2fwd example. It demonstrates usage of poll and event mode IO + mechanism under a single application. + Removed Items - diff --git a/doc/guides/sample_app_ug/index.rst b/doc/guides/sample_app_ug/index.rst index f23f8f59e..41388231a 100644 --- a/doc/guides/sample_app_ug/index.rst +++ b/doc/guides/sample_app_ug/index.rst @@ -26,6 +26,7 @@ Sample Applications User Guides l2_forward_crypto l2_forward_job_stats l2_forward_real_virtual +l2_forward_event l2_forward_cat l3_forward l3_forward_power_man diff --git a/doc/guides/sample_app_ug/intro.rst b/doc/guides/sample_app_ug/intro.rst index 90704194a..15bbbec44 100644 --- a/doc/guides/sample_app_ug/intro.rst +++ b/doc/guides/sample_app_ug/intro.rst @@ -87,6 +87,11 @@ examples are highlighted below. forwarding, or ``l2fwd`` application does forwarding based on Ethernet MAC addresses like a simple switch. +* :doc:`Network Layer 2 forwarding`: The Network Layer 2 + forwarding, or ``l2fwd-event`` application does forwarding based on Ethernet MAC + addresses like a simple switch. It demonstrates usage of poll and event mode + IO mechanism under a single application. + * :doc:`Network Layer 3 forwarding`: The Network Layer3 forwarding, or ``l3fwd`` application does forwarding based on Internet Protocol, IPv4 or IPv6 like a simple router. diff --git a/doc/guides/sample_app_ug/l2_forward_event.rst b/doc/guides/sample_app_ug/l2_forward_event.rst new file mode 100644 index 0..52a570b97 --- /dev/null +++ b/doc/guides/sample_app_ug/l2_forward_event.rst @@ -0,0 +1,698 @@ +.. SPDX-License-Identifier: BSD-3-Clause +Copyright(c) 2010-2014 Intel Corporation. + +.. _l2_fwd_event_app: + +L2 Forwarding Eventdev Sample Application += + +The L2 Forwarding eventdev sample application is a simple example of packet +processing using the Data Plane Development Kit (DPDK) to demonstrate usage of +poll and event mode packet I/O mechanism. + +Overview + + +The L2 Forwarding eventdev sample application, performs L2 forwarding for each +packet that is received on an RX_PORT. The destination port is the adjacent port +from the enabled portmask, that is, if the first four ports are enabled (portmask=0x0f), +ports 1 and 2 forward into each other, and ports 3 and 4 forward into each other. +Also, if MAC addresses updating is enabled, the MAC addresses are affected as follows: + +* The source MAC address is replaced by the TX_PORT MAC address + +* The destination MAC address is replaced by 02:00:00:00:00:TX_PORT_ID + +Application receives packets from RX_PORT using below mentioned methods: + +* Poll mode + +* Eventdev mode (default) + +This application can be used to benchmark performance using a traffic-generator, +as shown in the :numref:`figure_l2fwd_event_benchmark_setup`. + +.. _figure_l2fwd_event_benchmark_setup: + +.. figure:: img/l2_fwd_benchmark_setup.* + + Performance Benchmark Setup (Basic Environment) + +Compiling the Application +- + +To compile the sample application see :doc:`compiling`. + +The application is located in the ``l2fwd-event`` sub-directory. + +Running the Application +--- + +The application requires a number of command line options: + +.. code-block:: console + +./build/l2fwd-event [EAL options] -- -p PORTMASK [-q NQ] --[no-]mac-updating --mode=MODE --eventq-sched=SCHED_MODE + +where, + +* p PORTMASK: A hexadecimal bitmask of the ports to configure + +* q NQ: A number of queues (=ports) per lcore (default is 1) + +* --[no-]mac-updating: Ena
[dpdk-dev] [PATCH v7 07/10] examples/l2fwd-event: add service core setup
From: Pavan Nikhilesh
Setup service cores for eventdev and Rx/Tx adapter when they don't have
internal port capability.
Signed-off-by: Pavan Nikhilesh
---
examples/l2fwd-event/l2fwd_event.c | 82 ++
examples/l2fwd-event/l2fwd_event.h | 1 +
examples/l2fwd-event/main.c| 3 ++
3 files changed, 86 insertions(+)
diff --git a/examples/l2fwd-event/l2fwd_event.c
b/examples/l2fwd-event/l2fwd_event.c
index 33c702739..562d61292 100644
--- a/examples/l2fwd-event/l2fwd_event.c
+++ b/examples/l2fwd-event/l2fwd_event.c
@@ -17,6 +17,88 @@
#include "l2fwd_event.h"
+static inline int
+l2fwd_event_service_enable(uint32_t service_id)
+{
+ uint8_t min_service_count = UINT8_MAX;
+ uint32_t slcore_array[RTE_MAX_LCORE];
+ unsigned int slcore = 0;
+ uint8_t service_count;
+ int32_t slcore_count;
+
+ if (!rte_service_lcore_count())
+ return -ENOENT;
+
+ slcore_count = rte_service_lcore_list(slcore_array, RTE_MAX_LCORE);
+ if (slcore_count < 0)
+ return -ENOENT;
+ /* Get the core which has least number of services running. */
+ while (slcore_count--) {
+ /* Reset default mapping */
+ rte_service_map_lcore_set(service_id,
+ slcore_array[slcore_count], 0);
+ service_count = rte_service_lcore_count_services(
+ slcore_array[slcore_count]);
+ if (service_count < min_service_count) {
+ slcore = slcore_array[slcore_count];
+ min_service_count = service_count;
+ }
+ }
+ if (rte_service_map_lcore_set(service_id, slcore, 1))
+ return -ENOENT;
+ rte_service_lcore_start(slcore);
+
+ return 0;
+}
+
+void
+l2fwd_event_service_setup(struct l2fwd_resources *rsrc)
+{
+ struct l2fwd_event_resources *evt_rsrc = rsrc->evt_rsrc;
+ struct rte_event_dev_info evdev_info;
+ uint32_t service_id, caps;
+ int ret, i;
+
+ rte_event_dev_info_get(evt_rsrc->event_d_id, &evdev_info);
+ if (evdev_info.event_dev_cap & RTE_EVENT_DEV_CAP_DISTRIBUTED_SCHED) {
+ ret = rte_event_dev_service_id_get(evt_rsrc->event_d_id,
+ &service_id);
+ if (ret != -ESRCH && ret != 0)
+ rte_panic("Error in starting eventdev service\n");
+ l2fwd_event_service_enable(service_id);
+ }
+
+ for (i = 0; i < evt_rsrc->rx_adptr.nb_rx_adptr; i++) {
+ ret = rte_event_eth_rx_adapter_caps_get(evt_rsrc->event_d_id,
+ evt_rsrc->rx_adptr.rx_adptr[i], &caps);
+ if (ret < 0)
+ rte_panic("Failed to get Rx adapter[%d] caps\n",
+ evt_rsrc->rx_adptr.rx_adptr[i]);
+ ret = rte_event_eth_rx_adapter_service_id_get(
+ evt_rsrc->event_d_id,
+ &service_id);
+ if (ret != -ESRCH && ret != 0)
+ rte_panic("Error in starting Rx adapter[%d] service\n",
+ evt_rsrc->rx_adptr.rx_adptr[i]);
+ l2fwd_event_service_enable(service_id);
+ }
+
+ for (i = 0; i < evt_rsrc->tx_adptr.nb_tx_adptr; i++) {
+ ret = rte_event_eth_tx_adapter_caps_get(evt_rsrc->event_d_id,
+ evt_rsrc->tx_adptr.tx_adptr[i], &caps);
+ if (ret < 0)
+ rte_panic("Failed to get Rx adapter[%d] caps\n",
+ evt_rsrc->tx_adptr.tx_adptr[i]);
+ ret = rte_event_eth_tx_adapter_service_id_get(
+ evt_rsrc->event_d_id,
+ &service_id);
+ if (ret != -ESRCH && ret != 0)
+ rte_panic("Error in starting Rx adapter[%d] service\n",
+ evt_rsrc->tx_adptr.tx_adptr[i]);
+ l2fwd_event_service_enable(service_id);
+ }
+}
+
static void
l2fwd_event_capability_setup(struct l2fwd_event_resources *evt_rsrc)
{
diff --git a/examples/l2fwd-event/l2fwd_event.h
b/examples/l2fwd-event/l2fwd_event.h
index 1d7090ddf..ebfbfe460 100644
--- a/examples/l2fwd-event/l2fwd_event.h
+++ b/examples/l2fwd-event/l2fwd_event.h
@@ -66,5 +66,6 @@ struct l2fwd_event_resources {
void l2fwd_event_resource_setup(struct l2fwd_resources *rsrc);
void l2fwd_event_set_generic_ops(struct event_setup_ops *ops);
void l2fwd_event_set_internal_port_ops(struct event_setup_ops *ops);
+void l2fwd_event_service_setup(struct l2fwd_resources *rsrc);
#endif /* __L2FWD_EVENT_H__ */
diff --git a/examples/l2fwd-event/main.c b/examples/l2fwd-event/main.c
index 2a1fe4e11..1ae18bb51 100644
--- a/examples/l2fwd-event/main.c
+++ b/examples/l2fwd-event/main.c
@@ -471,6 +471,9 @@ main(int argc, char **argv)
[dpdk-dev] [PATCH v7 09/10] examples/l2fwd-event: add graceful teardown
From: Pavan Nikhilesh
Add graceful teardown that addresses both event mode and poll mode.
Signed-off-by: Pavan Nikhilesh
---
examples/l2fwd-event/main.c | 50 +
1 file changed, 40 insertions(+), 10 deletions(-)
diff --git a/examples/l2fwd-event/main.c b/examples/l2fwd-event/main.c
index 01eb19f3e..142c00e8f 100644
--- a/examples/l2fwd-event/main.c
+++ b/examples/l2fwd-event/main.c
@@ -426,7 +426,7 @@ main(int argc, char **argv)
uint16_t port_id, last_port;
uint32_t nb_mbufs;
uint16_t nb_ports;
- int ret;
+ int i, ret;
/* init EAL */
ret = rte_eal_init(argc, argv);
@@ -532,16 +532,46 @@ main(int argc, char **argv)
rte_eal_mp_remote_launch(l2fwd_launch_one_lcore, rsrc,
SKIP_MASTER);
l2fwd_event_print_stats(rsrc);
- rte_eal_mp_wait_lcore();
+ if (rsrc->event_mode) {
+ struct l2fwd_event_resources *evt_rsrc =
+ rsrc->evt_rsrc;
+ for (i = 0; i < evt_rsrc->rx_adptr.nb_rx_adptr; i++)
+ rte_event_eth_rx_adapter_stop(
+ evt_rsrc->rx_adptr.rx_adptr[i]);
+ for (i = 0; i < evt_rsrc->tx_adptr.nb_tx_adptr; i++)
+ rte_event_eth_tx_adapter_stop(
+ evt_rsrc->tx_adptr.tx_adptr[i]);
- RTE_ETH_FOREACH_DEV(port_id) {
- if ((rsrc->enabled_port_mask &
- (1 << port_id)) == 0)
- continue;
- printf("Closing port %d...", port_id);
- rte_eth_dev_stop(port_id);
- rte_eth_dev_close(port_id);
- printf(" Done\n");
+ RTE_ETH_FOREACH_DEV(port_id) {
+ if ((rsrc->enabled_port_mask &
+ (1 << port_id)) == 0)
+ continue;
+ rte_eth_dev_stop(port_id);
+ }
+
+ rte_eal_mp_wait_lcore();
+ RTE_ETH_FOREACH_DEV(port_id) {
+ if ((rsrc->enabled_port_mask &
+ (1 << port_id)) == 0)
+ continue;
+ rte_eth_dev_close(port_id);
+ }
+
+ rte_event_dev_stop(evt_rsrc->event_d_id);
+ rte_event_dev_close(evt_rsrc->event_d_id);
+
+ } else {
+ rte_eal_mp_wait_lcore();
+
+ RTE_ETH_FOREACH_DEV(port_id) {
+ if ((rsrc->enabled_port_mask &
+ (1 << port_id)) == 0)
+ continue;
+ printf("Closing port %d...", port_id);
+ rte_eth_dev_stop(port_id);
+ rte_eth_dev_close(port_id);
+ printf(" Done\n");
+ }
}
printf("Bye...\n");
--
2.17.1
Re: [dpdk-dev] [EXT] Re: [PATCH v11 2/4] eal: add legacy kni option
Hi Jerin, Hi Vamsi, On Fri, Oct 25, 2019 at 09:20:20AM +, Vamsi Krishna Attunuru wrote: > > > > -Original Message- > > From: Jerin Jacob > > Sent: Friday, October 25, 2019 1:01 AM > > To: Olivier Matz > > Cc: Vamsi Krishna Attunuru ; Andrew Rybchenko > > ; Ferruh Yigit ; > > tho...@monjalon.net; Jerin Jacob Kollanukkaran ; Kiran > > Kumar Kokkilagadda ; anatoly.bura...@intel.com; > > step...@networkplumber.org; dev@dpdk.org > > Subject: Re: [dpdk-dev] [EXT] Re: [PATCH v11 2/4] eal: add legacy kni option > > > > On Thu, Oct 24, 2019 at 11:05 PM Olivier Matz > > wrote: > > > > > > Hi, > > > > > > On Wed, Oct 23, 2019 at 08:32:08PM +0530, Jerin Jacob wrote: > > > > On Wed, Oct 23, 2019 at 8:17 PM Olivier Matz > > wrote: > > > > > > > > > > Hi, > > > > > > > > > > On Wed, Oct 23, 2019 at 03:42:39PM +0530, Jerin Jacob wrote: > > > > > > On Tue, Oct 22, 2019 at 7:01 PM Vamsi Krishna Attunuru > > > > > > wrote: > > > > > > > > > > > > > > Hi Ferruh, > > > > > > > > > > > > > > Can you please explain the problems in using kni dedicated mbuf > > > > > > > alloc > > routines while enabling kni iova=va mode. Please see the below discussion > > with > > Andrew. He wanted to know the problems in having newer APIs. > > > > > > > > > > > > > > > > > > While waiting for the Ferruh reply, I would like to summarise > > > > > > the current status > > > > > > > > > > > > # In order to make KNI work with IOVA as VA, We need to make > > > > > > sure mempool pool _object_ should not span across two huge pages > > > > > > > > > > > > # This problem can be fixed by, either of: > > > > > > > > > > > > a) Introduce a flag in mempool to define this constraint, so > > > > > > that, when only needed, this constraint enforced and this is in > > > > > > line with existing semantics of addressing such problems in > > > > > > mempool > > > > > > > > > > > > b) Instead of creating a flag, Make this behavior by default in > > > > > > mempool for IOVA as VA case > > > > > > > > > > > > Upside: > > > > > > b1) There is no need for specific mempool_create for KNI. > > > > > > > > > > > > Downside: > > > > > > b2) Not align with existing mempool API semantics > > > > > > b3) There will be a trivial amount of memory waste as we can not > > > > > > allocate from the edge. Considering the normal huge page memory > > > > > > size is 1G or 512MB this not a real issue. > > > > > > > > > > > > c) Make IOVA as PA when KNI kernel module is loaded > > > > > > > > > > > > Upside: > > > > > > c1) Doing option (a) would call for new KNI specific mempool > > > > > > create API i.e existing KNI applications need a one-line change > > > > > > in application to make it work with release 19.11 or later. > > > > > > > > > > > > Downslide: > > > > > > c2) Driver which needs RTE_PCI_DRV_NEED_IOVA_AS_VA can not work > > > > > > with KNI > > > > > > c3) Need root privilege to run KNI as IOVA as PA need root > > > > > > privilege > > > > > > > > > > > > For the next year, we expect applications to work 19.11 without > > > > > > any code change. My personal opinion to make go with option (a) > > > > > > and update the release notes to document the change any it > > > > > > simple one-line change. > > > > > > > > > > > > The selection of (a) vs (b) is between KNI and Mempool maintainers. > > > > > > Could we please reach a consensus? Or can we discuss this TB > > > > > > meeting? > > > > > > > > > > > > We are going back and forth on this feature on for the last 3 > > > > > > releases. Now that, we solved all the technical problems, please > > > > > > help us to decide (a) vs (b) to make forward progress. > > > > > > > > > > Thank you for the summary. > > > > > What is not clear to me is if (a) or (b) may break an existing > > > > > application, and if yes, in which case. > > > > > > > > Thanks for the reply. > > > > > > > > To be clear we are talking about out of tree KNI tree application. > > > > Which they don't want to > > > > change rte_pktmbuf_pool_create() to rte_kni_pktmbuf_pool_create() > > > > and build for v19.11 > > > > > > > > So in case (b) there is no issue as It will be using > > > > rte_pktmbuf_pool_create (). > > > > But in case of (a) it will create an issue if out of tree KNI > > > > application is using rte_pktmbuf_pool_create() which is not using > > > > the NEW flag. > > > > > > Following yesterday's discussion at techboard, I looked at the mempool > > > code and at my previous RFC patch. It took some time to remind me what > > > was my worries. > > > > Thanks for the review Olivier. > > > > Just to make sure the correct one is reviewed. > > > > 1) v7 had similar issue mentioned > > https://urldefense.proofpoint.com/v2/url?u=http- > > 3A__patches.dpdk.org_patch_56585_&d=DwIBaQ&c=nKjWec2b6R0mOyPaz7xtf > > Q&r=WllrYaumVkxaWjgKto6E_rtDQshhIhik2jkvzFyRhW8&m=MMwAZe76YMVHe > > 8UcHjL4IBnfX5YvtbocwICAZGBY97A&s=mfN_afnyFm65sQYzaAg_- > > uM9o22A5j392TdBZY-bKK4&e= The v7 has the problem I described below: the iova-contiguous all
[dpdk-dev] [PATCH v4] mbuf: support dynamic fields and flags
Many features require to store data inside the mbuf. As the room in mbuf
structure is limited, it is not possible to have a field for each
feature. Also, changing fields in the mbuf structure can break the API
or ABI.
This commit addresses these issues, by enabling the dynamic registration
of fields or flags:
- a dynamic field is a named area in the rte_mbuf structure, with a
given size (>= 1 byte) and alignment constraint.
- a dynamic flag is a named bit in the rte_mbuf structure.
The typical use case is a PMD that registers space for an offload
feature, when the application requests to enable this feature. As
the space in mbuf is limited, the space should only be reserved if it
is going to be used (i.e when the application explicitly asks for it).
The registration can be done at any moment, but it is not possible
to unregister fields or flags.
Signed-off-by: Olivier Matz
Acked-by: Thomas Monjalon
Acked-by: Konstantin Ananyev
---
v4
* rebase and solve conflicts
v3
* define mark_free() macro outside the init_shared_mem() function
(Konstantin)
* better document automatic field placement (Konstantin)
* introduce RTE_SIZEOF_FIELD() to get the size of a field in
a structure (Haiyue)
* fix api doc generation (Slava)
* document dynamic field and flags naming conventions
v2
* Rebase on top of master: solve conflict with Stephen's patchset
(packet copy)
* Add new apis to register a dynamic field/flag at a specific place
* Add a dump function (sugg by David)
* Enhance field registration function to select the best offset, keeping
large aligned zones as much as possible (sugg by Konstantin)
* Use a size_t and unsigned int instead of int when relevant
(sugg by Konstantin)
* Use "uint64_t dynfield1[2]" in mbuf instead of 2 uint64_t fields
(sugg by Konstantin)
* Remove unused argument in private function (sugg by Konstantin)
* Fix and simplify locking (sugg by Konstantin)
* Fix minor typo
rfc -> v1
* Rebase on top of master
* Change registration API to use a structure instead of
variables, getting rid of #defines (Stephen's comment)
* Update flag registration to use a similar API as fields.
* Change max name length from 32 to 64 (sugg. by Thomas)
* Enhance API documentation (Haiyue's and Andrew's comments)
* Add a debug log at registration
* Add some words in release note
* Did some performance tests (sugg. by Andrew):
On my platform, reading a dynamic field takes ~3 cycles more
than a static field, and ~2 cycles more for writing.
app/test/test_mbuf.c | 143 ++
doc/guides/rel_notes/release_19_11.rst | 7 +
lib/librte_eal/common/include/rte_common.h | 12 +
lib/librte_mbuf/Makefile | 2 +
lib/librte_mbuf/meson.build| 6 +-
lib/librte_mbuf/rte_mbuf.h | 15 +
lib/librte_mbuf/rte_mbuf_core.h| 8 +-
lib/librte_mbuf/rte_mbuf_dyn.c | 553 +
lib/librte_mbuf/rte_mbuf_dyn.h | 239 +
lib/librte_mbuf/rte_mbuf_version.map | 7 +
10 files changed, 988 insertions(+), 4 deletions(-)
create mode 100644 lib/librte_mbuf/rte_mbuf_dyn.c
create mode 100644 lib/librte_mbuf/rte_mbuf_dyn.h
diff --git a/app/test/test_mbuf.c b/app/test/test_mbuf.c
index 9fea312c8..854bc26d8 100644
--- a/app/test/test_mbuf.c
+++ b/app/test/test_mbuf.c
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
#include "test.h"
@@ -2411,6 +2412,142 @@ test_pktmbuf_ext_shinfo_init_helper(struct rte_mempool
*pktmbuf_pool)
return -1;
}
+static int
+test_mbuf_dyn(struct rte_mempool *pktmbuf_pool)
+{
+ const struct rte_mbuf_dynfield dynfield = {
+ .name = "test-dynfield",
+ .size = sizeof(uint8_t),
+ .align = __alignof__(uint8_t),
+ .flags = 0,
+ };
+ const struct rte_mbuf_dynfield dynfield2 = {
+ .name = "test-dynfield2",
+ .size = sizeof(uint16_t),
+ .align = __alignof__(uint16_t),
+ .flags = 0,
+ };
+ const struct rte_mbuf_dynfield dynfield3 = {
+ .name = "test-dynfield3",
+ .size = sizeof(uint8_t),
+ .align = __alignof__(uint8_t),
+ .flags = 0,
+ };
+ const struct rte_mbuf_dynfield dynfield_fail_big = {
+ .name = "test-dynfield-fail-big",
+ .size = 256,
+ .align = 1,
+ .flags = 0,
+ };
+ const struct rte_mbuf_dynfield dynfield_fail_align = {
+ .name = "test-dynfield-fail-align",
+ .size = 1,
+ .align = 3,
+ .flags = 0,
+ };
+ const struct rte_mbuf_dynflag dynflag = {
+ .name = "test-dynflag",
+ .flags = 0,
+ };
+ const struct rte_mbuf_dynflag dynflag2 = {
+ .name = "test-dynflag2",
+ .flags = 0,
+ };
+ const struct rte_mbuf_dyn
Re: [dpdk-dev] [EXT] Re: [PATCH v11 2/4] eal: add legacy kni option
Hi Olivier, > -Original Message- > From: Olivier Matz > Sent: Saturday, October 26, 2019 5:55 PM > To: Vamsi Krishna Attunuru > Cc: Jerin Jacob ; Andrew Rybchenko > ; Ferruh Yigit ; > tho...@monjalon.net; Jerin Jacob Kollanukkaran ; > Kiran Kumar Kokkilagadda ; > anatoly.bura...@intel.com; step...@networkplumber.org; dev@dpdk.org > Subject: Re: [dpdk-dev] [EXT] Re: [PATCH v11 2/4] eal: add legacy kni option > > Hi Jerin, Hi Vamsi, > > On Fri, Oct 25, 2019 at 09:20:20AM +, Vamsi Krishna Attunuru wrote: > > > > > > > -Original Message- > > > From: Jerin Jacob > > > Sent: Friday, October 25, 2019 1:01 AM > > > To: Olivier Matz > > > Cc: Vamsi Krishna Attunuru ; Andrew > Rybchenko > > > ; Ferruh Yigit ; > > > tho...@monjalon.net; Jerin Jacob Kollanukkaran ; > > > Kiran Kumar Kokkilagadda ; > > > anatoly.bura...@intel.com; step...@networkplumber.org; > dev@dpdk.org > > > Subject: Re: [dpdk-dev] [EXT] Re: [PATCH v11 2/4] eal: add legacy > > > kni option > > > > > > On Thu, Oct 24, 2019 at 11:05 PM Olivier Matz > > > > > > wrote: > > > > > > > > Hi, > > > > > > > > On Wed, Oct 23, 2019 at 08:32:08PM +0530, Jerin Jacob wrote: > > > > > On Wed, Oct 23, 2019 at 8:17 PM Olivier Matz > > > > > > > > wrote: > > > > > > > > > > > > Hi, > > > > > > > > > > > > On Wed, Oct 23, 2019 at 03:42:39PM +0530, Jerin Jacob wrote: > > > > > > > On Tue, Oct 22, 2019 at 7:01 PM Vamsi Krishna Attunuru > > > > > > > wrote: > > > > > > > > > > > > > > > > Hi Ferruh, > > > > > > > > > > > > > > > > Can you please explain the problems in using kni dedicated > > > > > > > > mbuf alloc > > > routines while enabling kni iova=va mode. Please see the below > > > discussion with Andrew. He wanted to know the problems in having > newer APIs. > > > > > > > > > > > > > > > > > > > > > While waiting for the Ferruh reply, I would like to > > > > > > > summarise the current status > > > > > > > > > > > > > > # In order to make KNI work with IOVA as VA, We need to make > > > > > > > sure mempool pool _object_ should not span across two huge > > > > > > > pages > > > > > > > > > > > > > > # This problem can be fixed by, either of: > > > > > > > > > > > > > > a) Introduce a flag in mempool to define this constraint, so > > > > > > > that, when only needed, this constraint enforced and this is > > > > > > > in line with existing semantics of addressing such problems > > > > > > > in mempool > > > > > > > > > > > > > > b) Instead of creating a flag, Make this behavior by default > > > > > > > in mempool for IOVA as VA case > > > > > > > > > > > > > > Upside: > > > > > > > b1) There is no need for specific mempool_create for KNI. > > > > > > > > > > > > > > Downside: > > > > > > > b2) Not align with existing mempool API semantics > > > > > > > b3) There will be a trivial amount of memory waste as we can > > > > > > > not allocate from the edge. Considering the normal huge page > > > > > > > memory size is 1G or 512MB this not a real issue. > > > > > > > > > > > > > > c) Make IOVA as PA when KNI kernel module is loaded > > > > > > > > > > > > > > Upside: > > > > > > > c1) Doing option (a) would call for new KNI specific mempool > > > > > > > create API i.e existing KNI applications need a one-line > > > > > > > change in application to make it work with release 19.11 or later. > > > > > > > > > > > > > > Downslide: > > > > > > > c2) Driver which needs RTE_PCI_DRV_NEED_IOVA_AS_VA can not > > > > > > > work with KNI > > > > > > > c3) Need root privilege to run KNI as IOVA as PA need root > > > > > > > privilege > > > > > > > > > > > > > > For the next year, we expect applications to work 19.11 > > > > > > > without any code change. My personal opinion to make go with > > > > > > > option (a) and update the release notes to document the > > > > > > > change any it simple one-line change. > > > > > > > > > > > > > > The selection of (a) vs (b) is between KNI and Mempool > maintainers. > > > > > > > Could we please reach a consensus? Or can we discuss this TB > meeting? > > > > > > > > > > > > > > We are going back and forth on this feature on for the last > > > > > > > 3 releases. Now that, we solved all the technical problems, > > > > > > > please help us to decide (a) vs (b) to make forward progress. > > > > > > > > > > > > Thank you for the summary. > > > > > > What is not clear to me is if (a) or (b) may break an existing > > > > > > application, and if yes, in which case. > > > > > > > > > > Thanks for the reply. > > > > > > > > > > To be clear we are talking about out of tree KNI tree application. > > > > > Which they don't want to > > > > > change rte_pktmbuf_pool_create() to > > > > > rte_kni_pktmbuf_pool_create() and build for v19.11 > > > > > > > > > > So in case (b) there is no issue as It will be using > rte_pktmbuf_pool_create (). > > > > > But in case of (a) it will create an issue if out of tree KNI > > > > > application is using rte_pktmbuf_pool_create() which is not > > > > > using the NEW flag. > > > > > > > > Fo
Re: [dpdk-dev] [PATCH] eal/reciprocal: fix off by one when divisor is 32bit
On Tue, Sep 3, 2019 at 9:17 PM wrote:
>
> From: Pavan Nikhilesh
>
> Fix off by one error in 64bit reciprocal division when divisor is 32bit.
Added log from unit test:
RTE>>reciprocal_division
Validating unsigned 32bit division.
Validating unsigned 64bit division.
Validating unsigned 64bit division with 32bit divisor.
Division failed, 16983222950483802557/819 = expected 20736535959076681
result 20736535959076682
Validating division by power of 2.
Test Failed
>
> Fixes: 6d45659eacb8 ("eal: add u64-bit variant for reciprocal divide")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Pavan Nikhilesh
Please continue working on enhancing the functional test so that it
can be part of the standard unit test list.
Thanks.
--
David Marchand
Re: [dpdk-dev] [PATCH v6 00/15] A new net PMD - hinic
On Thu, Jun 27, 2019 at 4:26 PM Ferruh Yigit wrote: > > On 6/27/2019 9:10 AM, Ziyang Xuan wrote: > > This patch set adds support of a new net PMD > > for Huawei Intelligent nic. This patch provides supoort > > for basic RX/TX and the contorl path needed for it. > > Later on new features will be added like VLAN, VFs, etc. > > > > Basic features: > > 1. Basic device operations: probe, initialization, start/stop, > >configure, info get. > > 2. RX/TX queue operations: setup/release, start/stop. > > 3. RX/TX. > > > > Stats: > > 1. statistics and extended statistics. > > > > --- > > v2: > > - Fix arm64 compilation issue. > > - Fix some checkpatch checks issues > > - Fix patches thread issue. > > - Fit to the newest rte_ prefix patch > > > > v3: > > - Remove Rami from hinic pmd maintainers > > - Remove hinic_logs.* files and move log codes to other files > > - Remove the C++ guards within hinic pmd codes > > - Remove variable related errors shields from compilation files > > - Use lib link statu related functions but selfdefined > > - Fix x86_64-native-linuxapp-clang compilation errors > > - Fix i686-native-linuxapp-gcc compilation errors > > > > v4: > > - Update doc hinic.ini and hinic.rst > > - Remove x86-32, i686, BSD, Power8, ARMv7 compilations > > - Fit to newest IPV4 and IPV6 uppercase > > > > v5: > > - Update doc hinic.rst and release_19_08.rst > > - Delete unused codes > > - Optimize arch of codes and delete unnecessary files > > - Remove rte_panic > > - Subdivided patches > > > > v6: > > - Adjust hinic pmd maintainers > > - Use "CONFIG_RTE_ARCH_X86_64" to determine X86_64 for SSE instruction > > - Fix "check-git-log.sh" checking errors > > - Move "hinic_pmd_ethdev.h" to patch 11/15, and > >"hinic_pmd_rx.h"/"hinic_pmd_tx.h" to patch 12/15 > > > > Ziyang Xuan (15): > > net/hinic/base: add HW registers definition > > net/hinic/base: add HW interfaces of bar operation > > net/hinic/base: add API command channel code > > net/hinic/base: add support for cmdq mechanism > > net/hinic/base: add eq mechanism function code > > net/hinic/base: add mgmt module function code > > net/hinic/base: add code about hardware operation > > net/hinic/base: add NIC business configurations > > net/hinic/base: add context and work queue support > > net/hinic/base: add various headers > > net/hinic: add hinic PMD build and doc files > > net/hinic: add device initailization > > net/hinic: add start stop close queue ops > > net/hinic: add Rx/Tx package burst > > net/hinic: add RSS stats promiscuous ops > > For series, > Reviewed-by: Ferruh Yigit > > Series applied to dpdk-next-net/master, thanks. > > > This is first PMD from Huawei, welcome to dpdk, thanks for your efforts. This driver is explicitely disabled for FreeBSD with the make build framework. But I am getting a build error with meson on FreeBSD. ninja -C build-gcc-static ninja: Entering directory `build-gcc-static' [660/1372] Compiling C object 'drivers/net/hinic/base/12a4447@@hinic_base@sta/hinic_pmd_cmdq.c.o'. FAILED: drivers/net/hinic/base/12a4447@@hinic_base@sta/hinic_pmd_cmdq.c.o ccache gcc -Idrivers/net/hinic/base/12a4447@@hinic_base@sta -Idrivers/net/hinic/base -I../drivers/net/hinic/base -I. -I../ -Iconfig -I../config -Ilib/librte_eal/common/include -I../lib/librte_eal/common/include -I../lib/librte_eal/freebsd/eal/include -Ilib/librte_eal/common -I../lib/librte_eal/common -Ilib/librte_eal/common/include/arch/x86 -I../lib/librte_eal/common/include/arch/x86 -Ilib/librte_eal -I../lib/librte_eal -Ilib/librte_kvargs -I../lib/librte_kvargs -Ilib/librte_ethdev -I../lib/librte_ethdev -Ilib/librte_net -I../lib/librte_net -Ilib/librte_mbuf -I../lib/librte_mbuf -Ilib/librte_mempool -I../lib/librte_mempool -Ilib/librte_ring -I../lib/librte_ring -Ilib/librte_meter -I../lib/librte_meter -Idrivers/bus/pci -I../drivers/bus/pci -I../drivers/bus/pci/bsd -Ilib/librte_pci -I../lib/librte_pci -Ilib/librte_hash -I../lib/librte_hash -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Werror -O3 -include rte_config.h -Wextra -Wcast-qual -Wdeprecated -Wformat-nonliteral -Wformat-security -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wold-style-definition -Wpointer-arith -Wsign-compare -Wstrict-prototypes -Wundef -Wwrite-strings -Wno-missing-field-initializers -D_GNU_SOURCE -D__BSD_VISIBLE -fPIC -march=native -Wno-format-truncation -MD -MQ 'drivers/net/hinic/base/12a4447@@hinic_base@sta/hinic_pmd_cmdq.c.o' -MF 'drivers/net/hinic/base/12a4447@@hinic_base@sta/hinic_pmd_cmdq.c.o.d' -o 'drivers/net/hinic/base/12a4447@@hinic_base@sta/hinic_pmd_cmdq.c.o' -c ../drivers/net/hinic/base/hinic_pmd_cmdq.c In file included from ../drivers/net/hinic/base/hinic_pmd_cmdq.c:5:0: ../drivers/net/hinic/base/hinic_compat.h: In function 'hinic_mutex_lock': ../drivers/net/hinic/base/hinic_compat.h:263:9: error: implicit declaration of function 'pthread_mutex_consistent'; did you mean 'pthread_mutex_init'? [-
Re: [dpdk-dev] [PATCH] eal: move rte_cpu definitions to os specific files
On Mon, Sep 30, 2019 at 7:35 PM Pallavi Kadam wrote:
>
> Moving RTE_CPU* definitions from the common code to the
> Linux, FreeBSD rte_os.h file to avoid #ifdef clutter.
>
> Signed-off-by: Pallavi Kadam
> Signed-off-by: Antara Ganesh Kolar
> Reviewed-by: Ranjit Menon
Took into account Jerin suggestion for title.
Reviewed-by: Jerin Jacob
> ---
> lib/librte_eal/common/include/rte_lcore.h | 44 -
> lib/librte_eal/freebsd/eal/include/rte_os.h | 27 +
> lib/librte_eal/linux/eal/include/rte_os.h | 19 +
> 3 files changed, 46 insertions(+), 44 deletions(-)
>
> diff --git a/lib/librte_eal/common/include/rte_lcore.h
> b/lib/librte_eal/common/include/rte_lcore.h
> index c86f72eb1..63ad4af13 100644
> --- a/lib/librte_eal/common/include/rte_lcore.h
> +++ b/lib/librte_eal/common/include/rte_lcore.h
> @@ -22,50 +22,6 @@ extern "C" {
>
> #define LCORE_ID_ANY UINT32_MAX /**< Any lcore. */
>
> -#if defined(__linux__)
> -typedefcpu_set_t rte_cpuset_t;
> -#define RTE_CPU_AND(dst, src1, src2) CPU_AND(dst, src1, src2)
> -#define RTE_CPU_OR(dst, src1, src2) CPU_OR(dst, src1, src2)
> -#define RTE_CPU_FILL(set) do \
> -{ \
> - unsigned int i; \
> - CPU_ZERO(set); \
> - for (i = 0; i < CPU_SETSIZE; i++) \
> - CPU_SET(i, set); \
> -} while (0)
> -#define RTE_CPU_NOT(dst, src) do \
> -{ \
> - cpu_set_t tmp; \
> - RTE_CPU_FILL(&tmp); \
> - CPU_XOR(dst, &tmp, src); \
> -} while (0)
> -#elif defined(__FreeBSD__)
> -#include
> -typedef cpuset_t rte_cpuset_t;
> -#define RTE_CPU_AND(dst, src1, src2) do \
> -{ \
> - cpuset_t tmp; \
> - CPU_COPY(src1, &tmp); \
> - CPU_AND(&tmp, src2); \
> - CPU_COPY(&tmp, dst); \
> -} while (0)
> -#define RTE_CPU_OR(dst, src1, src2) do \
> -{ \
> - cpuset_t tmp; \
> - CPU_COPY(src1, &tmp); \
> - CPU_OR(&tmp, src2); \
> - CPU_COPY(&tmp, dst); \
> -} while (0)
> -#define RTE_CPU_FILL(set) CPU_FILL(set)
> -#define RTE_CPU_NOT(dst, src) do \
> -{ \
> - cpuset_t tmp; \
> - CPU_FILL(&tmp); \
> - CPU_NAND(&tmp, src); \
> - CPU_COPY(&tmp, dst); \
> -} while (0)
> -#endif
> -
> /**
> * Structure storing internal configuration (per-lcore)
> */
> diff --git a/lib/librte_eal/freebsd/eal/include/rte_os.h
> b/lib/librte_eal/freebsd/eal/include/rte_os.h
> index 49cd4d4d9..b414f6989 100644
> --- a/lib/librte_eal/freebsd/eal/include/rte_os.h
> +++ b/lib/librte_eal/freebsd/eal/include/rte_os.h
> @@ -11,4 +11,31 @@
> * freebsd OS. Functions will be added in future releases.
> */
>
> +#include
> +#include
Including pthread_np.h is enough.
> +
> +typedef cpuset_t rte_cpuset_t;
> +#define RTE_CPU_AND(dst, src1, src2) do \
> +{ \
> + cpuset_t tmp; \
> + CPU_COPY(src1, &tmp); \
> + CPU_AND(&tmp, src2); \
> + CPU_COPY(&tmp, dst); \
> +} while (0)
> +#define RTE_CPU_OR(dst, src1, src2) do \
> +{ \
> + cpuset_t tmp; \
> + CPU_COPY(src1, &tmp); \
> + CPU_OR(&tmp, src2); \
> + CPU_COPY(&tmp, dst); \
> +} while (0)
> +#define RTE_CPU_FILL(set) CPU_FILL(set)
> +#define RTE_CPU_NOT(dst, src) do \
> +{ \
> + cpuset_t tmp; \
> + CPU_FILL(&tmp); \
> + CPU_NAND(&tmp, src); \
> + CPU_COPY(&tmp, dst); \
> +} while (0)
> +
> #endif /* _RTE_OS_H_ */
> diff --git a/lib/librte_eal/linux/eal/include/rte_os.h
> b/lib/librte_eal/linux/eal/include/rte_os.h
> index bc6ad14d2..dd487a830 100644
> --- a/lib/librte_eal/linux/eal/include/rte_os.h
> +++ b/lib/librte_eal/linux/eal/include/rte_os.h
> @@ -11,4 +11,23 @@
> * linux OS. Functions will be added in future releases.
> */
>
> +#include
cpu_set_t and the CPU macros come from sched.h.
No need for rte_per_lcore.h.
> +
> +typedefcpu_set_t rte_cpuset_t;
Fixed indent.
> +#define RTE_CPU_AND(dst, src1, src2) CPU_AND(dst, src1, src2)
> +#define RTE_CPU_OR(dst, src1, src2) CPU_OR(dst, src1, src2)
> +#define RTE_CPU_FILL(set) do \
> +{ \
> + unsigned int i; \
> + CPU_ZERO(set); \
> + for (i = 0; i < CPU_SETSIZE; i++) \
> + CPU_SET(i, set); \
> +} while (0)
> +#define RTE_CPU_NOT(dst, src) do \
> +{ \
> + cpu_set_t tmp; \
> + RTE_CPU_FILL(&tmp); \
> + CPU_XOR(dst, &tmp, src); \
> +} while (0)
> +
> #endif /* _RTE_OS_H_ */
> --
> 2.18.0.windows.1
>
Applied, thanks.
--
David Marchand
Re: [dpdk-dev] [dpdk-stable] [PATCH] vfio: fix BAR offset type for 32-bit app
On Fri, Oct 25, 2019 at 5:41 PM Burakov, Anatoly
wrote:
>
> On 24-Oct-19 1:10 PM, Michal Krawczyk wrote:
> > When 32-bit application is built on 64-bit system it is possible that
> > the offset of the resource is outside of the 32-bit value.
> >
> > The problem with the unsigned long is, that it is 32-bit and not 64-bit
> > when using armhf compiler. Although the system is returning u64 value,
> > we are losing it's value if it's higher than 32-bit in the conversion
> > process. It can further cause mmap to fail due to offset being 0 or to
> > map not intended memory region.
> >
> > To make it more portable, the uint64_t value is now being used for
> > storing offset instead of unsigned long. The size of being 32-bit seems
> > to be fine as the 32-bit application won't be able to access bigger
> > memory and it is further converted to size_t anyway. But for better
> > readability and to be consistent, it's type was changed to size_t as
> > well.
> >
> > Fixes: 0205f873557c ("vfio: fix overflow of BAR region offset and size")
> > Cc: sta...@dpdk.org
> >
> > Signed-off-by: Michal Krawczyk
> > ---
>
> Acked-by: Anatoly Burakov
Applied, thanks.
--
David Marchand
Re: [dpdk-dev] [dpdk-stable] [PATCH v5 1/2] eal: make base address hint OS-specific
On Thu, Oct 24, 2019 at 2:37 PM Anatoly Burakov wrote: > > Not all OS's follow Linux's memory layout, which may lead to > problems following the suggested common address hint absent > of a base-virtaddr flag. Make this address hint OS-specific. > > Cc: sta...@dpdk.org > > Signed-off-by: Anatoly Burakov Applied, thanks. -- David Marchand
Re: [dpdk-dev] [dpdk-stable] [PATCH v5 2/2] eal: use base address hint to reserve space for mem config
On Thu, Oct 24, 2019 at 2:37 PM Anatoly Burakov
wrote:
>
> Currently, mem config will be mapped without using the virtual
> area reservation infrastructure, which means it will be mapped
> at an arbitrary location. This may cause failures to map the
> shared config in secondary process due to things like PCI
> whitelist arguments allocating memory in a space where the
> primary has allocated the shared mem config.
>
> Fix this by using virtual area reservation to reserve space for
> the mem config, thereby avoiding the problem and reserving the
> shared config (hopefully) far away from any normal memory
> allocations.
>
> Cc: sta...@dpdk.org
>
> Signed-off-by: Anatoly Burakov
> ---
>
> Notes:
> v4:
> - Fix mem config length to always be page-aligned
>
> v3:
> - Fix alignment issues with base address
>
> v2:
> - Fix issue with unneeded ADDR_IS_HINT flag that broke things
> on 32-bit builds
>
> lib/librte_eal/freebsd/eal/eal.c | 28 +--
> lib/librte_eal/linux/eal/eal.c | 33 +++-
> 2 files changed, 46 insertions(+), 15 deletions(-)
>
> diff --git a/lib/librte_eal/freebsd/eal/eal.c
> b/lib/librte_eal/freebsd/eal/eal.c
> index f86e9aa318..5b869b895a 100644
> --- a/lib/librte_eal/freebsd/eal/eal.c
> +++ b/lib/librte_eal/freebsd/eal/eal.c
> @@ -218,7 +218,10 @@ eal_parse_sysfs_value(const char *filename, unsigned
> long *val)
> static int
> rte_eal_config_create(void)
> {
> - void *rte_mem_cfg_addr;
> + size_t page_sz = sysconf(_SC_PAGE_SIZE);
> + size_t cfg_len = sizeof(*rte_config.mem_config);
> + size_t cfg_len_aligned = RTE_ALIGN(cfg_len, page_sz);
> + void *rte_mem_cfg_addr, *mapped_mem_cfg_addr;
> int retval;
>
> const char *pathname = eal_runtime_config_path();
Updated existing call to sysconf with page_sz variable.
if (internal_config.base_virtaddr != 0)
rte_mem_cfg_addr = (void *)
RTE_ALIGN_FLOOR(internal_config.base_virtaddr -
- sizeof(struct rte_mem_config), sysconf(_SC_PAGE_SIZE));
+ sizeof(struct rte_mem_config), page_sz);
else
rte_mem_cfg_addr = NULL;
> @@ -235,7 +238,7 @@ rte_eal_config_create(void)
> }
> }
>
> - retval = ftruncate(mem_cfg_fd, sizeof(*rte_config.mem_config));
> + retval = ftruncate(mem_cfg_fd, cfg_len);
> if (retval < 0){
> close(mem_cfg_fd);
> mem_cfg_fd = -1;
> @@ -253,15 +256,28 @@ rte_eal_config_create(void)
> return -1;
> }
>
> - rte_mem_cfg_addr = mmap(NULL, sizeof(*rte_config.mem_config),
> - PROT_READ | PROT_WRITE, MAP_SHARED,
> mem_cfg_fd, 0);
> -
> - if (rte_mem_cfg_addr == MAP_FAILED){
> + /* reserve space for config */
> + rte_mem_cfg_addr = eal_get_virtual_area(NULL, &cfg_len_aligned,
> page_sz,
> + 0, 0);
Fixed conflict with base-virtaddr patches.
> + if (rte_mem_cfg_addr == NULL) {
> RTE_LOG(ERR, EAL, "Cannot mmap memory for rte_config\n");
> close(mem_cfg_fd);
> mem_cfg_fd = -1;
> return -1;
> }
Applied, thanks.
--
David Marchand
Re: [dpdk-dev] [PATCH v3] lib/librte_eal/linuxapp: fix runtime configmmap issue
On Fri, Oct 25, 2019 at 2:20 PM Burakov, Anatoly wrote: > > On 25-Oct-19 12:37 PM, han@zte.com.cn wrote: > > it seems your patch is later then mine? > > you rejected mine patch and then committed yours? > > I can't understand > > > > Hi, > > Apologies for the confusion. My patch's v1 was sent in July this year, > much earlier than yours: > > http://patches.dpdk.org/project/dpdk/list/?series=5813&state=%2A&archive=both > > And it's a more general patch, that also fixes the issue for FreeBSD. > This is the patch that got committed - it came in first, and it fixes > the issue in a more general way, for Linux and for FreeBSD. It's just > that for some reason i was under the impression that it was already > accepted, but it was merely deferred till 19.11. > > Again, my apologies for the confusion. I should have looked at your > patch more closely. I took Anatoly patches since his work on the subject preceded your patch. Please, test the current master branch and see if you still have issues. Thanks. -- David Marchand
Re: [dpdk-dev] [PATCH v4 1/1] fbarray: get fbarrays from containerized secondary
On Fri, Oct 25, 2019 at 9:55 PM Yasufumi Ogawa wrote:
> >>
> >> The title does not reflect the observed issue.
> I would like to consider to revise it.
>
> >> I understand that secondary processeses can't be started from a docker
> >> container.
> I've confirmed that secondary process can be started as a container app
> with SPP, and DPDK v18.08 and v19.08. SPP is a multi-process app
> supporting container usecases.
> http://git.dpdk.org/apps/spp/
Sorry, I don't understand.
Do you mean the secondary processes can be run from containers without
this patch?
Or once this patch is applied?
>
> >> The patch title should reflect this.
> >>
> >> On Wed, Jul 24, 2019 at 10:20 AM wrote:
> >>>
> >>> From: Yasufumi Ogawa
> >>>
> >>> In secondary_msl_create_walk(), it creates a file for fbarrays with its
> >>> PID for reserving unique name among secondary processes. However, it
> >>> does not work if secondary is run as app container because each of
> >>> containerized secondary has PID 1. To reserve unique name, use hostname
> >>> instead of PID because hostname is assigned as a short form of 64
> >>> digits full container ID in docker.
> >>>
> >>> Cc: sta...@dpdk.org
> >>
> >> I don't think we want to backport this behavior change.
> This issue was included from DPDK v18.08, and some users of SPP are
> still using stable 18.11. So, I would appreciate if you agree to backport.
This can be discussed later.
Ok to keep stable in CC: then.
>
> >>
> >>>
> >>> Signed-off-by: Yasufumi Ogawa
> >>> ---
> >>> lib/librte_eal/linux/eal/eal_memalloc.c | 28 +++--
> >>> 1 file changed, 26 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/lib/librte_eal/linux/eal/eal_memalloc.c
> >>> b/lib/librte_eal/linux/eal/eal_memalloc.c
> >>> index 1f6a7c18f..356b304a8 100644
> >>> --- a/lib/librte_eal/linux/eal/eal_memalloc.c
> >>> +++ b/lib/librte_eal/linux/eal/eal_memalloc.c
> >>> @@ -1366,6 +1366,7 @@ secondary_msl_create_walk(const struct
> >>> rte_memseg_list *msl,
> >>> struct rte_memseg_list *primary_msl, *local_msl;
> >>> char name[PATH_MAX];
> >>> int msl_idx, ret;
> >>> + char proc_id[33] = { 0 }; /* 32bytes is enough if using hostname
> >>> */
> >>
> >> This variable only makes sense in the if (getpid() == 1) branch,
> >> please move it there, and see below comment about using gethostname().
> Sure. It works correctly in secondary app container and I should replace it.
Great, can you send a new version of this patch?
>
> >>
> >>>
> >>> if (msl->external)
> >>> return 0;
> >>> @@ -1375,8 +1376,31 @@ secondary_msl_create_walk(const struct
> >>> rte_memseg_list *msl,
> >>> local_msl = &local_memsegs[msl_idx];
> >>>
> >>> /* create distinct fbarrays for each secondary */
> >>> - snprintf(name, RTE_FBARRAY_NAME_LEN, "%s_%i",
> >>> - primary_msl->memseg_arr.name, getpid());
> >>> + /* If run secondary in a container, the name of fbarray file
> >>> should
> >>> +* not be decided with pid because getpid() always returns 1.
> >>> +* In docker, hostname is assigned as a short form of full
> >>> container
> >>> +* ID. So use hostname as unique ID among containers instead.
> >>
> >> I understand this is how it works for docker.
> >> Is this the same in other container environments?
> Umm... I've tested on other than docker because I don't have test
> environment. I am not sure which of container runtimes should be
> supported actually. I think it is enough as the first step to fix this
> issue of docker. Moreover, the essential problem is that getpid()
> returns 1 in docker or not.
>
> I am also not sure which of environments other than docker should be
> supported if necessary. What do you think?
No problem if you don't know.
--
David Marchand
Re: [dpdk-dev] [PATCH v4 1/4] ethdev: add the API for getting burst mode information
26/10/2019 11:23, Wang, Haiyue:
> From: Thomas Monjalon [mailto:tho...@monjalon.net]
> > 26/10/2019 06:40, Wang, Haiyue:
> > > From: Thomas Monjalon [mailto:tho...@monjalon.net]
> > > > 25/10/2019 18:02, Jerin Jacob:
> > > > > On Fri, Oct 25, 2019 at 9:15 PM Thomas Monjalon
> > > > > wrote:
> > > > > > 25/10/2019 16:08, Ferruh Yigit:
> > > > > > > On 10/25/2019 10:36 AM, Thomas Monjalon wrote:
> > > > > > > > 15/10/2019 09:51, Haiyue Wang:
> > > > > > > >> Some PMDs have more than one RX/TX burst paths, add the ethdev
> > > > > > > >> API
> > > > > > > >> that allows an application to retrieve the mode information
> > > > > > > >> about
> > > > > > > >> Rx/Tx packet burst such as Scalar or Vector, and Vector
> > > > > > > >> technology
> > > > > > > >> like AVX2.
> > > > > > > >
> > > > > > > > I missed this patch. I and Andrew, maintainers of ethdev, were
> > > > > > > > not CC'ed.
> > > > > > > > Ferruh, I would expect to be Cc'ed and/or get a notification
> > > > > > > > before merging.
> > > > > > >
> > > > > > > It has been discussed in the mail list and went through multiple
> > > > > > > discussions,
> > > > > > > patch is out since the August, +1 to cc all maintainers I missed
> > > > > > > that part,
> > > > > > > but when the patch is reviewed and there is no objection, why
> > > > > > > block the merge?
> > > > > >
> > > > > > I'm not saying blocking the merge.
> > > > > > My bad is that I missed the patch and I am asking for help with a
> > > > > > notification
> > > > > > in this case. Same for Andrew I guess.
> > > > > > Note: it is merged in master and I am looking to improve this
> > > > > > feature.
> > > > >
> > > > > > > >> +/**
> > > > > > > >> + * Ethernet device RX/TX queue packet burst mode information
> > > > > > > >> structure.
> > > > > > > >> + * Used to retrieve information about packet burst mode
> > > > > > > >> setting.
> > > > > > > >> + */
> > > > > > > >> +struct rte_eth_burst_mode {
> > > > > > > >> + uint64_t options;
> > > > > > > >> +};
> > > > > > > >
> > > > > > > > Why a struct for an integer?
> > > > > > >
> > > > > > > Again by a request from me, to not need to break the API if we
> > > > > > > need to add more
> > > > > > > thing in the future.
> > > > > >
> > > > > > I would replace it with a string. This is the most flexible API.
> > > > >
> > > > > IMO, Probably, best of both worlds make a good option here,
> > > > > as Haiyue suggested if we have an additional dev_specific[1] in
> > > > > structure.
> > > > > and when a pass to the application, let common code make final string
> > > > > as
> > > > > (options flags to string + dev_specific)
> > > > >
> > > > > options flag can be zero if PMD does not have any generic flags nor
> > > > > interested in such a scheme.
> > > > > Generic flags will help at least to have some common code.
> > > > >
> > > > > [1]
> > > > > struct rte_eth_burst_mode {
> > > > > uint64_t options;
> > > > > char dev_specific[128]; /* PMD has specific burst mode
> > > > > information */
> > > > > };
> > > >
> > > > I really don't see how we can have generic flags.
> > > > The flags which are proposed are just matching
> > > > the functions implemented in Intel PMDs.
> > > > And this is a complicate solution.
> > > > Why not just returning a name for the selected Rx/Tx mode?
> > >
> > > Intel PMDs use the *generic* methods like x86 SSE, AVX2, ARM NEON, PPC
> > > ALTIVEC,
> > > 'dev->data->scattered_rx' etc for the target : "DPDK is the Data Plane
> > > Development Kit
> > > that consists of libraries to accelerate packet processing workloads
> > > running on a wide
> > > variety of CPU architectures."
> >
> > How RTE_ETH_BURST_SCATTERED and RTE_ETH_BURST_BULK_ALLOC are generic?
> > They just match some features of the Intel PMDs.
> > Why not exposing other optimizations of the Rx/Tx implementations?
> > You totally missed the point of generic burst mode description.
> >
> > > If understand these new experimental APIs from above, then bit options is
> > > the best,
> > > and we didn't invent new words to describe them, just from the CPU &
> > > other *generic*
> > > technology. And the application can loop to check which kind of burst is
> > > running by
> > > just simple bit test.
> > >
> > > If PMDs missed these, they can update them in future roadmaps to enhance
> > > their PMDs,
> > > like MLX5 supports ARM NEON, x86 SSE.
> >
> > I have no word!
> > You really think other PMDs should learn from Intel how to "enhance" their
> > PMD?
> > You talk about mlx5, did you look at its code? Did you see the burst modes
> > depending on which specific hardware path is used (MPRQ, EMPW, inline)?
> > Or depending on which offloads are handled?
> >
> > Again, the instruction set used by the function is a small part
> > of the burst mode optimization.
> >
> > So you did not reply to my question:
> > Why not just returning a name for the selected Rx/Tx mode?
>
> In fact, RFC v1/v2 returns the *name*, b
Re: [dpdk-dev] [RFC v2 1/3] ethdev: add the API for getting trace information
13/08/2019 14:51, Ray Kinsella: > On 13/08/2019 04:24, Stephen Hemminger wrote: > > On Tue, 13 Aug 2019 11:06:10 +0800 > > Haiyue Wang wrote: > > > >> Enhance the PMD to support retrieving trace information like > >> Rx/Tx burst selection etc. > >> > >> Signed-off-by: Haiyue Wang [...] > >> int > >> +rte_eth_trace_info_get(uint16_t port_id, uint16_t queue_id, > >> + enum rte_eth_trace type, char *buf, int sz) [...] > > The bigger problem is that this information is like a log message > > and unstructured, which makes it device specific and useless for automation. > > IMHO - this is much better implemented as a capability bitfield, that > can be queried. Now I see where this idea comes from. Ray, Stephen, structuring shuch information is really a bad idea. The Rx/Tx functions are not like capabilities, they are full of smart tricks written by brillant engineers. Please do not try to put ideas in some categories. We will have more and more new types of optimization and ideas when the hardware will evolve. And, more importantly, there is no need of automation or processing with this information.
Re: [dpdk-dev] [PATCH v4] mbuf: support dynamic fields and flags
26/10/2019 14:39, Olivier Matz: > Many features require to store data inside the mbuf. As the room in mbuf > structure is limited, it is not possible to have a field for each > feature. Also, changing fields in the mbuf structure can break the API > or ABI. > > This commit addresses these issues, by enabling the dynamic registration > of fields or flags: > > - a dynamic field is a named area in the rte_mbuf structure, with a > given size (>= 1 byte) and alignment constraint. > - a dynamic flag is a named bit in the rte_mbuf structure. > > The typical use case is a PMD that registers space for an offload > feature, when the application requests to enable this feature. As > the space in mbuf is limited, the space should only be reserved if it > is going to be used (i.e when the application explicitly asks for it). > > The registration can be done at any moment, but it is not possible > to unregister fields or flags. > > Signed-off-by: Olivier Matz > Acked-by: Thomas Monjalon > Acked-by: Konstantin Ananyev Applied, thanks, this is a new major feature.
Re: [dpdk-dev] [PATCH v6] app/testpmd: enable GTP header parse and Tx checksum offload
26/10/2019 00:43, Thomas Monjalon: > 23/10/2019 19:23, Ferruh Yigit: > > On 10/22/2019 4:45 PM, Ferruh Yigit wrote: > > > On 10/22/2019 5:26 PM, Ting Xu wrote: > > >> This patch enables testpmd to forward GTP packet in csum fwd mode. > > >> A GTP header structure (without optional fields and extension header) > > >> is defined in new rte_gtp.h. A parser function in testpmd is added. > > >> GTPU and GTPC packets are both supported, with respective UDP > > >> destination port and GTP message type. > > >> > > >> Signed-off-by: Ting Xu > > >> > > >> --- > > >> v6: complete doxygen documentation. > > >> v5: create rte_gtp.h and move GTP header definition > > >> to it. > > >> v4: move GTP header definition to rte_ether.h > > >> v3: correct coding style issue. > > >> v2: modify commit log > > >> > > >> depend on patch: lib/mbuf: add GTP tunnel type flag. > > > > > > Reviewed-by: Ferruh Yigit > > > > > > Will wait mbuf patch to be applied to get the patch. > > > > > > > Applied to dpdk-next-net/master, thanks. > > Sorry, dropped from pull in master. > An update of meson.build is missing and it makes me feel > something else may be missing. Changed my mind: I pull it in the master branch with few fixes.
[dpdk-dev] [PATCH v1] net/ice: use dynamic mbuf API to handle protocol extraction
The original design is to occupy rte_mbuf::udata64 to save the metadata
which combines the network protocol fields and related type, then use
private API to decode this metadata. It is no so generic.
Use the new dynamic mbuf field and flags to handle protocol extraction.
Now the new metadata is very clean, just network protocol fields in the
specified offset, and its type will be indicated by related ol_flags.
Signed-off-by: Haiyue Wang
---
doc/guides/nics/ice.rst | 22 +++--
drivers/net/ice/Makefile | 3 -
drivers/net/ice/ice_ethdev.c | 62 +-
drivers/net/ice/ice_ethdev.h | 18
drivers/net/ice/ice_rxtx.c| 82 +++---
drivers/net/ice/ice_rxtx.h| 1 -
drivers/net/ice/meson.build | 2 -
drivers/net/ice/rte_pmd_ice.h | 152 --
8 files changed, 147 insertions(+), 195 deletions(-)
delete mode 100644 drivers/net/ice/rte_pmd_ice.h
diff --git a/doc/guides/nics/ice.rst b/doc/guides/nics/ice.rst
index 933f63480..f460d1cfd 100644
--- a/doc/guides/nics/ice.rst
+++ b/doc/guides/nics/ice.rst
@@ -82,8 +82,8 @@ Runtime Config Options
- ``Protocol extraction for per queue``
- Configure the RX queues to do protocol extraction into ``rte_mbuf::udata64``
- for protocol handling acceleration, like checking the TCP SYN packets
quickly.
+ Configure the RX queues to do protocol extraction into mbuf for protocol
+ handling acceleration, like checking the TCP SYN packets quickly.
The argument format is::
@@ -111,7 +111,9 @@ Runtime Config Options
This setting means queues 1, 2-3, 8-9 are TCP extraction, queues 10-23 are
IPv6 extraction, other queues use the default VLAN extraction.
- The extraction will be copied into the lower 32 bit of ``rte_mbuf::udata64``.
+ The extraction metadata will be copied into the registered dynamic mbuf field
+ with name: "proto-xtr-metadata", size: 4B, align: __alignof__(uint32_t), and
+ the related dynamic mbuf flags in ``rte_mbuf::ol_flags`` will be set.
.. table:: Protocol extraction : ``vlan``
@@ -125,6 +127,8 @@ Runtime Config Options
VLAN2 - C-VLAN (second for QinQ).
+ Dynamic mbuf flag : "proto-xtr-ol-vlan"
+
.. table:: Protocol extraction : ``ipv4``
+++
@@ -137,6 +141,8 @@ Runtime Config Options
IPHDR2 - IPv4 header word 0, "Ver", "Hdr Len" and "Type of Service" fields.
+ Dynamic mbuf flag : "proto-xtr-ol-ipv4"
+
.. table:: Protocol extraction : ``ipv6``
+++
@@ -150,6 +156,8 @@ Runtime Config Options
IPHDR2 - IPv6 header word 0, "Ver", "Traffic class" and high 4 bits of
"Flow Label" fields.
+ Dynamic mbuf flag : "proto-xtr-ol-ipv6"
+
.. table:: Protocol extraction : ``ipv6_flow``
+++
@@ -163,6 +171,8 @@ Runtime Config Options
IPHDR2 - IPv6 header word 0, "Ver", "Traffic class" and high 4 bits of
"Flow Label" fields.
+ Dynamic mbuf flag : "proto-xtr-ol-ipv6-flow"
+
.. table:: Protocol extraction : ``tcp``
+++
@@ -175,11 +185,7 @@ Runtime Config Options
TCPHDR2 - Reserved
- Use ``get_proto_xtr_flds(struct rte_mbuf *mb)`` to access the protocol
- extraction, do not use ``rte_mbuf::udata64`` directly.
-
- The ``dump_proto_xtr_flds(struct rte_mbuf *mb)`` routine shows how to
- access the protocol extraction result in ``struct rte_mbuf``.
+ Dynamic mbuf flag : "proto-xtr-ol-tcp"
Driver compilation and testing
--
diff --git a/drivers/net/ice/Makefile b/drivers/net/ice/Makefile
index 7c3b6a7ff..a1817e14c 100644
--- a/drivers/net/ice/Makefile
+++ b/drivers/net/ice/Makefile
@@ -84,7 +84,4 @@ ifeq ($(CC_AVX2_SUPPORT), 1)
endif
SRCS-$(CONFIG_RTE_LIBRTE_ICE_PMD) += ice_generic_flow.c
-# install this header file
-SYMLINK-$(CONFIG_RTE_LIBRTE_ICE_PMD)-include := rte_pmd_ice.h
-
include $(RTE_SDK)/mk/rte.lib.mk
diff --git a/drivers/net/ice/ice_ethdev.c b/drivers/net/ice/ice_ethdev.c
index d74675842..fc0124cf4 100644
--- a/drivers/net/ice/ice_ethdev.c
+++ b/drivers/net/ice/ice_ethdev.c
@@ -30,6 +30,26 @@ static const char * const ice_valid_args[] = {
NULL
};
+static const struct rte_mbuf_dynfield proto_xtr_metadata_param = {
+ .name = "proto-xtr-metadata",
+ .size = sizeof(uint32_t),
+ .align = __alignof__(uint32_t),
+ .flags = 0,
+};
+
+struct proto_xtr_ol_flag {
+ const struct rte_mbuf_dynflag param;
+ uint64_t *flag;
+};
+
+static const struct proto_xtr_ol_flag proto_xtr_ol_flag_params[] = {
+ { { "proto-xtr-ol-vlan", 0 }, &proto_xtr_ol_vlan },
+ { { "proto-xtr-ol-ipv4", 0 }, &proto_xtr_ol_ipv4 },
+ { { "proto-xtr-ol-ipv6", 0 }, &proto_xtr_ol_ipv6 },
+ { { "proto-xtr-ol-ipv6-flow", 0 }, &proto_xtr_ol_ipv6_flow },
+ { { "proto-xtr-ol-tcp", 0 },
Re: [dpdk-dev] [PATCH v4 1/1] fbarray: get fbarrays from containerized secondary
On 2019/10/27 1:15, David Marchand wrote:
On Fri, Oct 25, 2019 at 9:55 PM Yasufumi Ogawa wrote:
The title does not reflect the observed issue.
I would like to consider to revise it.
I understand that secondary processeses can't be started from a docker
container.
I've confirmed that secondary process can be started as a container app
with SPP, and DPDK v18.08 and v19.08. SPP is a multi-process app
supporting container usecases.
http://git.dpdk.org/apps/spp/
Sorry, I don't understand.
Do you mean the secondary processes can be run from containers without
this patch?
Or once this patch is applied?
Secondary processes can be run from a container. The problem is we
cannot run two or more secondary app containers. It is because each of
secondary app container tries to create its metadata file and the name
is decided with PID, and PID is 1 in all of containers. It means that
all of secondaries try to have the same name of metadata file, and
failed to create the same file. The first container app can create
metadata file with PID 1, but failed to create second one with the same
PID 1.
This patch is to change creating metadata file from using PID 1 to
hostname which is unique in each of secondary containers.
To summarize, we can run just one secondary app container without this
patch, but cannot two or more secondary app containers.
The patch title should reflect this.
On Wed, Jul 24, 2019 at 10:20 AM wrote:
From: Yasufumi Ogawa
In secondary_msl_create_walk(), it creates a file for fbarrays with its
PID for reserving unique name among secondary processes. However, it
does not work if secondary is run as app container because each of
containerized secondary has PID 1. To reserve unique name, use hostname
instead of PID because hostname is assigned as a short form of 64
digits full container ID in docker.
Cc: sta...@dpdk.org
I don't think we want to backport this behavior change.
This issue was included from DPDK v18.08, and some users of SPP are
still using stable 18.11. So, I would appreciate if you agree to backport.
This can be discussed later.
Ok to keep stable in CC: then.
Thanks.
Signed-off-by: Yasufumi Ogawa
---
lib/librte_eal/linux/eal/eal_memalloc.c | 28 +++--
1 file changed, 26 insertions(+), 2 deletions(-)
diff --git a/lib/librte_eal/linux/eal/eal_memalloc.c
b/lib/librte_eal/linux/eal/eal_memalloc.c
index 1f6a7c18f..356b304a8 100644
--- a/lib/librte_eal/linux/eal/eal_memalloc.c
+++ b/lib/librte_eal/linux/eal/eal_memalloc.c
@@ -1366,6 +1366,7 @@ secondary_msl_create_walk(const struct rte_memseg_list
*msl,
struct rte_memseg_list *primary_msl, *local_msl;
char name[PATH_MAX];
int msl_idx, ret;
+ char proc_id[33] = { 0 }; /* 32bytes is enough if using hostname */
This variable only makes sense in the if (getpid() == 1) branch,
please move it there, and see below comment about using gethostname().
Sure. It works correctly in secondary app container and I should replace it.
Great, can you send a new version of this patch?
Yes, I will fix it soon.
if (msl->external)
return 0;
@@ -1375,8 +1376,31 @@ secondary_msl_create_walk(const struct rte_memseg_list
*msl,
local_msl = &local_memsegs[msl_idx];
/* create distinct fbarrays for each secondary */
- snprintf(name, RTE_FBARRAY_NAME_LEN, "%s_%i",
- primary_msl->memseg_arr.name, getpid());
+ /* If run secondary in a container, the name of fbarray file should
+* not be decided with pid because getpid() always returns 1.
+* In docker, hostname is assigned as a short form of full container
+* ID. So use hostname as unique ID among containers instead.
I understand this is how it works for docker.
Is this the same in other container environments?
Umm... I've tested on other than docker because I don't have test
environment. I am not sure which of container runtimes should be
supported actually. I think it is enough as the first step to fix this
issue of docker. Moreover, the essential problem is that getpid()
returns 1 in docker or not.
I am also not sure which of environments other than docker should be
supported if necessary. What do you think?
No problem if you don't know.
Thanks.
Yasufumi
--
David Marchand
Re: [dpdk-dev] [PATCH v3 12/12] doc: announce global logs struct removal from ABI
On 25/10/2019 14:56, David Marchand wrote: > New accessor has been introduced to provide the hidden information. > This symbol can now be kept internal. > > Signed-off-by: David Marchand > --- > doc/guides/rel_notes/deprecation.rst | 4 > 1 file changed, 4 insertions(+) > > diff --git a/doc/guides/rel_notes/deprecation.rst > b/doc/guides/rel_notes/deprecation.rst > index cf7744e..3aa1634 100644 > --- a/doc/guides/rel_notes/deprecation.rst > +++ b/doc/guides/rel_notes/deprecation.rst > @@ -34,6 +34,10 @@ Deprecation Notices > > + ``rte_eal_devargs_type_count`` > > +* eal: The ``rte_logs`` struct and global symbol will be made private to > + remove it from the externally visible ABI and allow it to be updated in the > + future. > + > * vfio: removal of ``rte_vfio_dma_map`` and ``rte_vfio_dma_unmap`` APIs which >have been replaced with ``rte_dev_dma_map`` and ``rte_dev_dma_unmap`` >functions. The due date for the removal targets DPDK 20.02. > Acked-by: Kevin Traynor
Re: [dpdk-dev] [PATCH v3 12/12] doc: announce global logs struct removal from ABI
On Sat, Oct 26, 2019 at 8:14 PM Kevin Traynor wrote: > > On 25/10/2019 14:56, David Marchand wrote: > > New accessor has been introduced to provide the hidden information. > > This symbol can now be kept internal. > > > Signed-off-by: David Marchand > > --- > > doc/guides/rel_notes/deprecation.rst | 4 > > 1 file changed, 4 insertions(+) > > > > diff --git a/doc/guides/rel_notes/deprecation.rst > > b/doc/guides/rel_notes/deprecation.rst > > index cf7744e..3aa1634 100644 > > --- a/doc/guides/rel_notes/deprecation.rst > > +++ b/doc/guides/rel_notes/deprecation.rst > > @@ -34,6 +34,10 @@ Deprecation Notices > > > > + ``rte_eal_devargs_type_count`` > > > > +* eal: The ``rte_logs`` struct and global symbol will be made private to > > + remove it from the externally visible ABI and allow it to be updated in > > the > > + future. > > + > > * vfio: removal of ``rte_vfio_dma_map`` and ``rte_vfio_dma_unmap`` APIs > > which > >have been replaced with ``rte_dev_dma_map`` and ``rte_dev_dma_unmap`` > >functions. The due date for the removal targets DPDK 20.02. > > > > Acked-by: Kevin Traynor Thanks Kevin for catching that contrail vrouter relies on rte_logs. Something to study by 20.11. -- David Marchand
Re: [dpdk-dev] [PATCH v3 00/12] EAL and PCI ABI changes for 19.11
On Fri, Oct 25, 2019 at 3:56 PM David Marchand wrote: > > Let's prepare for the ABI freeze. > > The first patches are about changes that had been announced before. > > The malloc_heap structure from the memory subsystem can be hidden. > The PCI library had some forgotten deprecated APIs that are removed with > this series. > > rte_logs could be hidden, but I left it exposed for now. > I added an accessor to rte_logs.file, and added a deprecation notice > announcing its removal from the public ABI. > > Changelog since v2: > - dropped patch 8 and added a deprecation notice on rte_logs instead, > > Changelog since v1: > - I went a step further, hiding rte_config after de-inlining non critical > functions > > > -- > David Marchand > > David Marchand (11): > eal: remove deprecated CPU flags check function > eal: remove deprecated malloc virt2phys function > mem: hide internal heap header > net/bonding: use non deprecated PCI API > pci: remove deprecated functions > log: add log stream accessor > test/mem: remove dependency on EAL internals > eal: deinline lcore APIs > eal: factorize lcore role code > eal: make the global configuration private > doc: announce global logs struct removal from ABI > > Stephen Hemminger (1): > eal: make lcore config private Thanks for the reviews/acks. Series applied. -- David Marchand
Re: [dpdk-dev] [PATCH v3 0/6] remove a few example applications
On Fri, Oct 25, 2019 at 11:59 AM Ciara Power wrote: > > As discussed by the DPDK technical board e.g. [1][2] and on the DPDK > mailing list [3], we have a lot of example applications shipped with > DPDK - a number which increases with each DPDK release, and not all of > which are probably needed any more. Therefore, this set removes 5 > example applications from the repository. > > v3: > - Document removed applications in release notes. > - Removed "from DPDK" in patch titles. > > v2: Remove the table listing sample applications > > [1] https://mails.dpdk.org/archives/dev/2019-May/132288.html > [2] https://mails.dpdk.org/archives/dev/2019-June/135847.html > [3] https://mails.dpdk.org/archives/dev/2019-July/138676.html > > > Bruce Richardson (2): > examples/exception_path: remove example > examples/l3fwd-vf: remove example > > Ciara Power (4): > doc: remove unnecessary sample app guide table > examples/quota-watermark: remove example > examples/netmap-compat: remove example > examples/load_balancer: remove example > > MAINTAINERS | 15 - > doc/guides/rel_notes/release_19_11.rst| 12 + > doc/guides/sample_app_ug/exception_path.rst | 281 - > doc/guides/sample_app_ug/index.rst|5 - > doc/guides/sample_app_ug/intro.rst| 44 +- > .../sample_app_ug/l3_forward_virtual.rst | 98 -- > doc/guides/sample_app_ug/load_balancer.rst| 201 --- > .../sample_app_ug/netmap_compatibility.rst| 130 -- > doc/guides/sample_app_ug/quota_watermark.rst | 465 --- > examples/Makefile |5 - > examples/exception_path/Makefile | 57 - > examples/exception_path/main.c| 605 - > examples/exception_path/meson.build | 11 - > examples/l3fwd-vf/Makefile| 62 - > examples/l3fwd-vf/main.c | 1077 - > examples/l3fwd-vf/meson.build | 12 - > examples/load_balancer/Makefile | 62 - > examples/load_balancer/config.c | 1030 > examples/load_balancer/init.c | 537 > examples/load_balancer/main.c | 76 -- > examples/load_balancer/main.h | 351 -- > examples/load_balancer/meson.build| 12 - > examples/load_balancer/runtime.c | 642 -- > examples/meson.build |9 +- > examples/netmap_compat/Makefile | 22 - > examples/netmap_compat/bridge/Makefile| 35 - > examples/netmap_compat/bridge/bridge.c| 347 -- > examples/netmap_compat/lib/compat_netmap.c| 906 -- > examples/netmap_compat/lib/compat_netmap.h| 51 - > examples/netmap_compat/meson.build| 10 - > examples/netmap_compat/netmap/netmap.h| 289 - > examples/netmap_compat/netmap/netmap_user.h | 95 -- > examples/quota_watermark/Makefile | 16 - > examples/quota_watermark/include/conf.h | 19 - > examples/quota_watermark/meson.build | 10 - > examples/quota_watermark/qw/Makefile | 22 - > examples/quota_watermark/qw/args.c| 78 -- > examples/quota_watermark/qw/args.h| 12 - > examples/quota_watermark/qw/init.c| 168 --- > examples/quota_watermark/qw/init.h| 14 - > examples/quota_watermark/qw/main.c| 373 -- > examples/quota_watermark/qw/main.h| 31 - > examples/quota_watermark/qwctl/Makefile | 22 - > examples/quota_watermark/qwctl/commands.c | 196 --- > examples/quota_watermark/qwctl/commands.h | 12 - > examples/quota_watermark/qwctl/qwctl.c| 67 - > examples/quota_watermark/qwctl/qwctl.h| 12 - > 47 files changed, 17 insertions(+), 8589 deletions(-) > delete mode 100644 doc/guides/sample_app_ug/exception_path.rst > delete mode 100644 doc/guides/sample_app_ug/l3_forward_virtual.rst > delete mode 100644 doc/guides/sample_app_ug/load_balancer.rst > delete mode 100644 doc/guides/sample_app_ug/netmap_compatibility.rst > delete mode 100644 doc/guides/sample_app_ug/quota_watermark.rst > delete mode 100644 examples/exception_path/Makefile > delete mode 100644 examples/exception_path/main.c > delete mode 100644 examples/exception_path/meson.build > delete mode 100644 examples/l3fwd-vf/Makefile > delete mode 100644 examples/l3fwd-vf/main.c > delete mode 100644 examples/l3fwd-vf/meson.build > delete mode 100644 examples/load_balancer/Makefile > delete mode 100644 examples/load_balancer/config.c > delete mode 100644 examples/load_balancer/init.c > delete mode 100644 examples/load_balancer/main.c > delete mode 100644 examples/load_balancer/main.h > delete mode 100644 examples/load_balancer/meson.build > delete mode 100644 examples/load_balancer/runtime.c > delete mode 100644 exampl
Re: [dpdk-dev] [RFC v2 1/3] ethdev: add the API for getting trace information
> -Original Message- > From: Thomas Monjalon [mailto:tho...@monjalon.net] > Sent: Sunday, October 27, 2019 00:46 > To: Ray Kinsella ; step...@networkplumber.org; Wang, Haiyue > > Cc: dev@dpdk.org; Yigit, Ferruh ; > viachesl...@mellanox.com; Verplanke, Edwin > > Subject: Re: [dpdk-dev] [RFC v2 1/3] ethdev: add the API for getting trace > information > > 13/08/2019 14:51, Ray Kinsella: > > On 13/08/2019 04:24, Stephen Hemminger wrote: > > > On Tue, 13 Aug 2019 11:06:10 +0800 > > > Haiyue Wang wrote: > > > > > >> Enhance the PMD to support retrieving trace information like > > >> Rx/Tx burst selection etc. > > >> > > >> Signed-off-by: Haiyue Wang > [...] > > >> int > > >> +rte_eth_trace_info_get(uint16_t port_id, uint16_t queue_id, > > >> + enum rte_eth_trace type, char *buf, int sz) > [...] > > > The bigger problem is that this information is like a log message > > > and unstructured, which makes it device specific and useless for > > > automation. > > > > IMHO - this is much better implemented as a capability bitfield, that > > can be queried. > > Now I see where this idea comes from. > Ray, Stephen, structuring shuch information is really a bad idea. > The Rx/Tx functions are not like capabilities, they are full of smart > tricks written by brillant engineers. Please do not try to put ideas > in some categories. We will have more and more new types of optimization > and ideas when the hardware will evolve. > > And, more importantly, there is no need of automation or processing > with this information. > The real requirement is from VPP CLI practice in production: http://www.jimmdenton.com/vpp-1810-mellanox/ tx burst function: xxx rx burst function: xxx Their implementation requires *non static* rx/tx burst. Yes, MLX uses an template compile for extreme performance. * @param olx * Configured offloads mask, presents the bits of MLX5_TXOFF_CONFIG_xxx * values. Should be static to take compile time static configuration * advantages. * * @return * Number of packets successfully transmitted (<= pkts_n). */ static __rte_always_inline uint16_t mlx5_tx_burst_tmpl(struct mlx5_txq_data *restrict txq, struct rte_mbuf **restrict pkts, uint16_t pkts_n, unsigned int olx) What we design is from another kind of thinking from CPU's point view: commit 2e542da709371ee51d61d74c9a1b357ad34ae13e Author: David Christensen Date: Fri Aug 16 12:56:04 2019 -0500 net/mlx5: add Altivec Rx Added mlx5_rxtx_vec_altivec.h which supports vectorized RX using Altivec vector code. Modified associated build files to use the new code. Signed-off-by: David Christensen Acked-by: Viacheslav Ovsiienko Tested-by: Raslan Darawsheh
[dpdk-dev] [PATCH] ethdev: bump library version
Let's stick to the current model of per library ABI version until the
new model is in place.
Fixes: 4f25d7d2252f ("ethdev: add return code to device info get function")
Signed-off-by: David Marchand
---
lib/librte_ethdev/Makefile| 2 +-
lib/librte_ethdev/meson.build | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/librte_ethdev/Makefile b/lib/librte_ethdev/Makefile
index 60bcc22..0efcdfa 100644
--- a/lib/librte_ethdev/Makefile
+++ b/lib/librte_ethdev/Makefile
@@ -16,7 +16,7 @@ LDLIBS += -lrte_mbuf -lrte_kvargs -lrte_meter
EXPORT_MAP := rte_ethdev_version.map
-LIBABIVER := 12
+LIBABIVER := 13
SRCS-y += ethdev_private.c
SRCS-y += rte_ethdev.c
diff --git a/lib/librte_ethdev/meson.build b/lib/librte_ethdev/meson.build
index f75d428..c22cf81 100644
--- a/lib/librte_ethdev/meson.build
+++ b/lib/librte_ethdev/meson.build
@@ -2,7 +2,7 @@
# Copyright(c) 2017 Intel Corporation
name = 'ethdev'
-version = 12
+version = 13
allow_experimental_apis = true
sources = files('ethdev_private.c',
'ethdev_profile.c',
--
1.8.3.1
Re: [dpdk-dev] [PATCH v3 00/12] EAL and PCI ABI changes for 19.11
On Sat, Oct 26, 2019 at 9:18 PM David Marchand wrote: > > On Fri, Oct 25, 2019 at 3:56 PM David Marchand > wrote: > > > > Let's prepare for the ABI freeze. > > > > The first patches are about changes that had been announced before. > > > > The malloc_heap structure from the memory subsystem can be hidden. > > The PCI library had some forgotten deprecated APIs that are removed with > > this series. > > > > rte_logs could be hidden, but I left it exposed for now. > > I added an accessor to rte_logs.file, and added a deprecation notice > > announcing its removal from the public ABI. > > > > Changelog since v2: > > - dropped patch 8 and added a deprecation notice on rte_logs instead, > > > > Changelog since v1: > > - I went a step further, hiding rte_config after de-inlining non critical > > functions > > > > > > -- > > David Marchand > > > > David Marchand (11): > > eal: remove deprecated CPU flags check function > > eal: remove deprecated malloc virt2phys function > > mem: hide internal heap header > > net/bonding: use non deprecated PCI API > > pci: remove deprecated functions > > log: add log stream accessor > > test/mem: remove dependency on EAL internals > > eal: deinline lcore APIs > > eal: factorize lcore role code > > eal: make the global configuration private > > doc: announce global logs struct removal from ABI > > > > Stephen Hemminger (1): > > eal: make lcore config private > > Thanks for the reviews/acks. > Series applied. I held back before pushing as I caught an issue on ethdev abiver. Since the ABI changes are not in place, we should still bump it and the same would apply on eal and pci libraries in this series. Waiting a bit if anyone is looking at this, else I will go with this for rc1. Thanks. -- David Marchand
