DPDK patches and discussions
 help / color / mirror / Atom feed
* [dpdk-dev] [PATCH] example: add new service cores sample application
@ 2017-09-25 13:23 Harry van Haaren
  2017-10-13 22:20 ` Thomas Monjalon
  2017-10-19 10:31 ` [dpdk-dev] [PATCH v2] " Harry van Haaren
  0 siblings, 2 replies; 9+ messages in thread
From: Harry van Haaren @ 2017-09-25 13:23 UTC (permalink / raw)
  To: dev; +Cc: Harry van Haaren

This commit adds a new sample app, which showcases the value
of running services. In particular it allows the application
to dynamically schedule services to service-cores.

The sample app itself registers a number of dummy services,
and applies different profiles to them at runtime. Note that
this sample application does not forward any traffic - it
demonstrates advanced usage of the service cores API.

Signed-off-by: Harry van Haaren <harry.van.haaren@intel.com>
---
 examples/service_cores/Makefile |  54 +++++++++
 examples/service_cores/main.c   | 245 ++++++++++++++++++++++++++++++++++++++++
 2 files changed, 299 insertions(+)
 create mode 100644 examples/service_cores/Makefile
 create mode 100644 examples/service_cores/main.c

diff --git a/examples/service_cores/Makefile b/examples/service_cores/Makefile
new file mode 100644
index 0000000..bd4a345
--- /dev/null
+++ b/examples/service_cores/Makefile
@@ -0,0 +1,54 @@
+#   BSD LICENSE
+#
+#   Copyright(c) 2017 Intel Corporation. All rights reserved.
+#
+#   Redistribution and use in source and binary forms, with or without
+#   modification, are permitted provided that the following conditions
+#   are met:
+#
+#     * Redistributions of source code must retain the above copyright
+#       notice, this list of conditions and the following disclaimer.
+#     * Redistributions in binary form must reproduce the above copyright
+#       notice, this list of conditions and the following disclaimer in
+#       the documentation and/or other materials provided with the
+#       distribution.
+#     * Neither the name of Intel Corporation nor the names of its
+#       contributors may be used to endorse or promote products derived
+#       from this software without specific prior written permission.
+#
+#   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+#   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+#   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+#   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+#   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+#   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+#   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+#   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+#   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+#   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+#   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+ifeq ($(RTE_SDK),)
+$(error "Please define RTE_SDK environment variable")
+endif
+
+# Default target, can be overridden by command line or environment
+RTE_TARGET ?= x86_64-native-linuxapp-gcc
+
+include $(RTE_SDK)/mk/rte.vars.mk
+
+# binary name
+APP = service_cores
+
+# all source are stored in SRCS-y
+SRCS-y := main.c
+
+CFLAGS += $(WERROR_FLAGS)
+
+# workaround for a gcc bug with noreturn attribute
+# http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12603
+ifeq ($(CONFIG_RTE_TOOLCHAIN_GCC),y)
+CFLAGS_main.o += -Wno-return-type
+endif
+
+include $(RTE_SDK)/mk/rte.extapp.mk
diff --git a/examples/service_cores/main.c b/examples/service_cores/main.c
new file mode 100644
index 0000000..c1f125a
--- /dev/null
+++ b/examples/service_cores/main.c
@@ -0,0 +1,245 @@
+/*
+ *   BSD LICENSE
+ *
+ *   Copyright(c) 2017 Intel Corporation. All rights reserved.
+ *
+ *   Redistribution and use in source and binary forms, with or without
+ *   modification, are permitted provided that the following conditions
+ *   are met:
+ *
+ *     * Redistributions of source code must retain the above copyright
+ *       notice, this list of conditions and the following disclaimer.
+ *     * Redistributions in binary form must reproduce the above copyright
+ *       notice, this list of conditions and the following disclaimer in
+ *       the documentation and/or other materials provided with the
+ *       distribution.
+ *     * Neither the name of Intel Corporation nor the names of its
+ *       contributors may be used to endorse or promote products derived
+ *       from this software without specific prior written permission.
+ *
+ *   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ *   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ *   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ *   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ *   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ *   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ *   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ *   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ *   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ *   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#include <unistd.h>
+#include <stdio.h>
+#include <string.h>
+#include <stdint.h>
+#include <errno.h>
+#include <sys/queue.h>
+
+#include <rte_memory.h>
+#include <rte_memzone.h>
+#include <rte_launch.h>
+#include <rte_eal.h>
+#include <rte_debug.h>
+#include <rte_cycles.h>
+
+/* allow application scheduling of the services */
+#include <rte_service.h>
+
+/* Allow application registration of its own services. An application does not
+ * have to register services, but it can be useful if it wishes to run a
+ * function on a core that is otherwise in use as a service core. In this
+ * example, all services are dummy services registered by the sample app itself.
+ */
+#include <rte_service_component.h>
+
+#define PROFILE_CORES_MAX 8
+#define PROFILE_SERVICE_PER_CORE 8
+
+/* dummy function to do "work" */
+static int32_t service_func(void *args)
+{
+	RTE_SET_USED(args);
+	rte_delay_us(2000);
+	return 0;
+}
+
+static struct rte_service_spec services[] = {
+	{"service_1", service_func, NULL, 0, 0},
+	{"service_2", service_func, NULL, 0, 0},
+	{"service_3", service_func, NULL, 0, 0},
+	{"service_4", service_func, NULL, 0, 0},
+	{"service_5", service_func, NULL, 0, 0},
+};
+#define NUM_SERVICES RTE_DIM(services)
+
+/* this struct holds the mapping of a particular core to all services */
+struct profile_for_core {
+	uint32_t mapped_services[PROFILE_SERVICE_PER_CORE];
+};
+
+/* struct that can be applied as the service core mapping. Items in this
+ * struct will be passed to the ordinary rte_service_* APIs to configure the
+ * service cores at runtime, based on the requirements.
+ *
+ * These profiles can be considered a "configuration" for the service cores,
+ * where switching profile just changes the number of cores and the mappings
+ * for each of them. As a result, the core requirements and performance of the
+ * application scales.
+ */
+struct profile {
+	char name[64];
+	uint32_t num_cores;
+	struct profile_for_core cores[PROFILE_CORES_MAX];
+};
+
+static struct profile profiles[] = {
+	/* profile 0: high performance */
+	{
+		.name = "High Performance",
+		.num_cores = 5,
+		.cores[0] = {.mapped_services = {1, 0, 0, 0, 0, 0, 0, 0} },
+		.cores[1] = {.mapped_services = {0, 1, 0, 0, 0, 0, 0, 0} },
+		.cores[2] = {.mapped_services = {0, 0, 1, 0, 0, 0, 0, 0} },
+		.cores[3] = {.mapped_services = {0, 0, 0, 1, 0, 0, 0, 0} },
+		.cores[4] = {.mapped_services = {0, 0, 0, 0, 1, 0, 0, 0} },
+	},
+	/* profile 1: mid performance with single service priority */
+	{
+		.name = "Mid-High Performance",
+		.num_cores = 3,
+		.cores[0] = {.mapped_services = {1, 1, 0, 0, 0, 0, 0, 0} },
+		.cores[1] = {.mapped_services = {0, 0, 1, 1, 0, 0, 0, 0} },
+		.cores[2] = {.mapped_services = {0, 0, 0, 0, 1, 0, 0, 0} },
+		.cores[3] = {.mapped_services = {0, 0, 0, 0, 0, 0, 0, 0} },
+		.cores[4] = {.mapped_services = {0, 0, 0, 0, 0, 0, 0, 0} },
+	},
+	/* profile 2: mid performance with single service priority */
+	{
+		.name = "Mid-Low Performance",
+		.num_cores = 2,
+		.cores[0] = {.mapped_services = {1, 1, 1, 0, 0, 0, 0, 0} },
+		.cores[1] = {.mapped_services = {1, 1, 0, 1, 1, 0, 0, 0} },
+		.cores[2] = {.mapped_services = {0, 0, 0, 0, 0, 0, 0, 0} },
+		.cores[3] = {.mapped_services = {0, 0, 0, 0, 0, 0, 0, 0} },
+		.cores[4] = {.mapped_services = {0, 0, 0, 0, 0, 0, 0, 0} },
+	},
+	/* profile 3: scale down performance on single core */
+	{
+		.name = "Scale down performance",
+		.num_cores = 1,
+		.cores[0] = {.mapped_services = {1, 1, 1, 1, 1, 0, 0, 0} },
+		.cores[1] = {.mapped_services = {0, 0, 0, 0, 0, 0, 0, 0} },
+		.cores[2] = {.mapped_services = {0, 0, 0, 0, 0, 0, 0, 0} },
+		.cores[3] = {.mapped_services = {0, 0, 0, 0, 0, 0, 0, 0} },
+		.cores[4] = {.mapped_services = {0, 0, 0, 0, 0, 0, 0, 0} },
+	},
+};
+#define NUM_PROFILES RTE_DIM(profiles)
+
+static int
+apply_profile(int profile_id)
+{
+	uint32_t i;
+	uint32_t s;
+	int ret;
+	struct profile *p = &profiles[profile_id];
+	const uint8_t core_off = 1;
+
+	for (i = 0; i < p->num_cores; i++) {
+		ret = rte_service_lcore_add(i + core_off);
+		if (ret && ret != -EALREADY)
+			printf("core %d added ret %d\n", i + core_off, ret);
+
+		ret = rte_service_lcore_start(i + core_off);
+		if (ret && ret != -EALREADY)
+			printf("core %d start ret %d\n", i + core_off, ret);
+
+		for (s = 0; s < NUM_SERVICES; s++) {
+			if (rte_service_map_lcore_set(s, i + core_off,
+					p->cores[i].mapped_services[s]))
+				rte_panic("failed to map lcore to 1\n");
+		}
+	}
+
+	for ( ; i < PROFILE_CORES_MAX; i++) {
+		for (s = 0; s < NUM_SERVICES; s++) {
+			ret = rte_service_map_lcore_set(s, i + core_off, 0);
+			if (ret && ret != -EINVAL) {
+				printf("%s %d: map lcore set = %d\n", __func__,
+						__LINE__, ret);
+			}
+		}
+		ret = rte_service_lcore_stop(i + core_off);
+		if (ret && ret != -EALREADY) {
+			printf("%s %d: lcore stop = %d\n", __func__,
+					__LINE__, ret);
+		}
+		ret = rte_service_lcore_del(i + core_off);
+		if (ret && ret != -EINVAL) {
+			printf("%s %d: lcore del = %d\n", __func__,
+					__LINE__, ret);
+		}
+	}
+}
+
+int
+main(int argc, char **argv)
+{
+	int ret;
+
+	ret = rte_eal_init(argc, argv);
+	if (ret < 0)
+		rte_panic("Cannot init EAL\n");
+
+	uint32_t i;
+	for (i = 0; i < NUM_SERVICES; i++) {
+		services[i].callback_userdata = 0;
+		uint32_t id;
+		ret = rte_service_component_register(&services[i], &id);
+		if (ret)
+			rte_exit(-1, "service register() failed");
+
+		/* set the service itself to be ready to run. In the case of
+		 * ethdev, eventdev etc PMDs, this will be set when the
+		 * appropriate configure or setup function is called.
+		 */
+		rte_service_component_runstate_set(id, 1);
+
+		/* Collect statistics for the service */
+		rte_service_set_stats_enable(id, 1);
+
+		/* the application sets the service to be active. Note that the
+		 * previous component_runstate_set() is the PMD indicating
+		 * ready, while this function is the application setting the
+		 * service to run. Applications can choose to not run a service
+		 * by setting runstate to 0 at any time.
+		 */
+		ret = rte_service_runstate_set(id, 1);
+		if (ret)
+			return -ENOEXEC;
+	}
+
+	i = 0;
+	while (1) {
+		const char clr[] = { 27, '[', '2', 'J', '\0' };
+		const char topLeft[] = { 27, '[', '1', ';', '1', 'H', '\0' };
+		printf("%s%s", clr, topLeft);
+
+		apply_profile(i);
+		printf("\n==> Profile: %s\n\n", profiles[i].name);
+
+		sleep(1);
+		rte_service_dump(stdout, UINT32_MAX);
+
+		sleep(5);
+		rte_service_dump(stdout, UINT32_MAX);
+
+		i++;
+		if (i >= NUM_PROFILES)
+			i = 0;
+	}
+
+	return 0;
+}
-- 
2.7.4

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [dpdk-dev] [PATCH] example: add new service cores sample application
  2017-09-25 13:23 [dpdk-dev] [PATCH] example: add new service cores sample application Harry van Haaren
@ 2017-10-13 22:20 ` Thomas Monjalon
  2017-10-13 22:24   ` Thomas Monjalon
  2017-10-19 10:31 ` [dpdk-dev] [PATCH v2] " Harry van Haaren
  1 sibling, 1 reply; 9+ messages in thread
From: Thomas Monjalon @ 2017-10-13 22:20 UTC (permalink / raw)
  To: Harry van Haaren; +Cc: dev

25/09/2017 15:23, Harry van Haaren:
> This commit adds a new sample app, which showcases the value
> of running services. In particular it allows the application
> to dynamically schedule services to service-cores.
> 
> The sample app itself registers a number of dummy services,
> and applies different profiles to them at runtime. Note that
> this sample application does not forward any traffic - it
> demonstrates advanced usage of the service cores API.
> 
> Signed-off-by: Harry van Haaren <harry.van.haaren@intel.com>
> ---
>  examples/service_cores/Makefile |  54 +++++++++
>  examples/service_cores/main.c   | 245 ++++++++++++++++++++++++++++++++++++++++
>  2 files changed, 299 insertions(+)

Please add this example in the global examples Makefile.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [dpdk-dev] [PATCH] example: add new service cores sample application
  2017-10-13 22:20 ` Thomas Monjalon
@ 2017-10-13 22:24   ` Thomas Monjalon
  2017-10-19 10:04     ` Van Haaren, Harry
  0 siblings, 1 reply; 9+ messages in thread
From: Thomas Monjalon @ 2017-10-13 22:24 UTC (permalink / raw)
  To: Harry van Haaren; +Cc: dev, john.mcnamara

14/10/2017 00:20, Thomas Monjalon:
> 25/09/2017 15:23, Harry van Haaren:
> > This commit adds a new sample app, which showcases the value
> > of running services. In particular it allows the application
> > to dynamically schedule services to service-cores.
> > 
> > The sample app itself registers a number of dummy services,
> > and applies different profiles to them at runtime. Note that
> > this sample application does not forward any traffic - it
> > demonstrates advanced usage of the service cores API.
> > 
> > Signed-off-by: Harry van Haaren <harry.van.haaren@intel.com>
> > ---
> >  examples/service_cores/Makefile |  54 +++++++++
> >  examples/service_cores/main.c   | 245 ++++++++++++++++++++++++++++++++++++++++
> >  2 files changed, 299 insertions(+)
> 
> Please add this example in the global examples Makefile.

And you need to add it also in MAINTAINERS.

I guess an entry in the doc is maybe required, too?

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [dpdk-dev] [PATCH] example: add new service cores sample application
  2017-10-13 22:24   ` Thomas Monjalon
@ 2017-10-19 10:04     ` Van Haaren, Harry
  0 siblings, 0 replies; 9+ messages in thread
From: Van Haaren, Harry @ 2017-10-19 10:04 UTC (permalink / raw)
  To: Thomas Monjalon; +Cc: dev, Mcnamara, John

> From: Thomas Monjalon [mailto:thomas@monjalon.net]
> Sent: Friday, October 13, 2017 11:24 PM
> To: Van Haaren, Harry <harry.van.haaren@intel.com>
> Cc: dev@dpdk.org; Mcnamara, John <john.mcnamara@intel.com>
> Subject: Re: [dpdk-dev] [PATCH] example: add new service cores sample
> application
> 
> 14/10/2017 00:20, Thomas Monjalon:
> > 25/09/2017 15:23, Harry van Haaren:
> > > This commit adds a new sample app, which showcases the value
> > > of running services. In particular it allows the application
> > > to dynamically schedule services to service-cores.
> > >
> > > The sample app itself registers a number of dummy services,
> > > and applies different profiles to them at runtime. Note that
> > > this sample application does not forward any traffic - it
> > > demonstrates advanced usage of the service cores API.
> > >
> > > Signed-off-by: Harry van Haaren <harry.van.haaren@intel.com>
> > > ---
> > >  examples/service_cores/Makefile |  54 +++++++++
> > >  examples/service_cores/main.c   | 245
> ++++++++++++++++++++++++++++++++++++++++
> > >  2 files changed, 299 insertions(+)
> >
> > Please add this example in the global examples Makefile.
> 
> And you need to add it also in MAINTAINERS.
> 
> I guess an entry in the doc is maybe required, too?

Yes, yes, and yes. Will all be fixed in v2! -Harry

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [dpdk-dev] [PATCH v2] example: add new service cores sample application
  2017-09-25 13:23 [dpdk-dev] [PATCH] example: add new service cores sample application Harry van Haaren
  2017-10-13 22:20 ` Thomas Monjalon
@ 2017-10-19 10:31 ` Harry van Haaren
  2017-10-23 14:58   ` Eads, Gage
  2017-10-24 21:02   ` Thomas Monjalon
  1 sibling, 2 replies; 9+ messages in thread
From: Harry van Haaren @ 2017-10-19 10:31 UTC (permalink / raw)
  To: dev; +Cc: thomas, john.mcnamara, gage.eads, Harry van Haaren

This commit adds a new sample app, which showcases the value
of running services. In particular it allows the application
to dynamically schedule services to service-cores.

The sample app itself registers a number of dummy services,
and applies different profiles to them at runtime. Note that
this sample application does not forward any traffic - it
demonstrates advanced usage of the service cores API.

Signed-off-by: Harry van Haaren <harry.van.haaren@intel.com>

---

v2 feedback http://dpdk.org/dev/patchwork/patch/29169/
- Add to examples Makefile (Thomas)
- Add new files to MAINTAINERS (Thomas)
- Added documentation to sample app user guides (Thomas)
- Reduce service-per-core define to 5, removes extra zeros (Gage)
- Improve error handling if service mapping fails (Gage)


---
 MAINTAINERS                                |   4 +
 doc/guides/sample_app_ug/index.rst         |   1 +
 doc/guides/sample_app_ug/service_cores.rst | 172 ++++++++++++++++++++
 examples/Makefile                          |   1 +
 examples/service_cores/Makefile            |  54 +++++++
 examples/service_cores/main.c              | 247 +++++++++++++++++++++++++++++
 6 files changed, 479 insertions(+)
 create mode 100644 doc/guides/sample_app_ug/service_cores.rst
 create mode 100644 examples/service_cores/Makefile
 create mode 100644 examples/service_cores/main.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 8df2a7f..44a8c38 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -903,6 +903,10 @@ M: John McNamara <john.mcnamara@intel.com>
 F: examples/rxtx_callbacks/
 F: doc/guides/sample_app_ug/rxtx_callbacks.rst
 
+M: Harry van Haaren <harry.van.haaren@intel.com>
+F: examples/service_cores/
+F: doc/guides/sample_app_ug/service_cores.rst
+
 M: Bruce Richardson <bruce.richardson@intel.com>
 M: John McNamara <john.mcnamara@intel.com>
 F: examples/skeleton/
diff --git a/doc/guides/sample_app_ug/index.rst b/doc/guides/sample_app_ug/index.rst
index 069d4f1..0c17ebb 100644
--- a/doc/guides/sample_app_ug/index.rst
+++ b/doc/guides/sample_app_ug/index.rst
@@ -58,6 +58,7 @@ Sample Applications User Guides
     link_status_intr
     load_balancer
     server_node_efd
+    service_cores
     multi_process
     qos_metering
     qos_scheduler
diff --git a/doc/guides/sample_app_ug/service_cores.rst b/doc/guides/sample_app_ug/service_cores.rst
new file mode 100644
index 0000000..07e3929
--- /dev/null
+++ b/doc/guides/sample_app_ug/service_cores.rst
@@ -0,0 +1,172 @@
+..  BSD LICENSE
+    Copyright(c) 2017 Intel Corporation. All rights reserved.
+    All rights reserved.
+
+    Redistribution and use in source and binary forms, with or without
+    modification, are permitted provided that the following conditions
+    are met:
+
+    * Redistributions of source code must retain the above copyright
+    notice, this list of conditions and the following disclaimer.
+    * Redistributions in binary form must reproduce the above copyright
+    notice, this list of conditions and the following disclaimer in
+    the documentation and/or other materials provided with the
+    distribution.
+    * Neither the name of Intel Corporation nor the names of its
+    contributors may be used to endorse or promote products derived
+    from this software without specific prior written permission.
+
+    THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+    "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+    LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+    A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+    OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+    SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+    LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+    DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+    THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+    (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+    OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+Service Cores Sample Application
+================================
+
+The service cores sample application demonstrates the service cores capabilities
+of DPDK. The service cores infrastructure is part of the DPDK EAL, and allows
+any DPDK component to register a service. A service is a work item or task, that
+requires CPU time to perform its duty.
+
+This sample application registers 5 dummy services. These 5 services are used
+to show how the service_cores API can be used to orchestrate these services to
+run on different service lcores. This orchestration is done by calling the
+service cores APIs, however the sample application introduces a "profile"
+concept to contain the service mapping details. Note that the profile concept
+is application specific, and not a part of the service cores API.
+
+
+Compiling the Application
+-------------------------
+
+#.  Go to the example directory:
+
+    .. code-block:: console
+
+        export RTE_SDK=/path/to/rte_sdk
+        cd ${RTE_SDK}/examples/service_cores
+
+#.  Set the target (a default target is used if not specified). For example:
+
+    .. code-block:: console
+
+        export RTE_TARGET=x86_64-native-linuxapp-gcc
+
+    See the *DPDK Getting Started* Guide for possible RTE_TARGET values.
+
+#.  Build the application:
+
+    .. code-block:: console
+
+        make
+
+Running the Application
+-----------------------
+
+To run the example, just execute the binary. Since the application dynamically
+adds service cores in the application code itself, there is no requirement to
+pass a service core-mask as an EAL argument at startup time.
+
+.. code-block:: console
+
+    $ ./build/service_cores
+
+
+Explanation
+-----------
+
+The following sections provide some explanation of code focusing on
+registering applications from an applications point of view, and modifying the
+service core counts and mappings at runtime.
+
+
+Registering a Service
+~~~~~~~~~~~~~~~~~~~~~
+
+The following code section shows how to register a service as an application.
+Note that the service component header must be included by the application in
+order to register services: ``rte_service_component.h``, in addition
+to the ordinary service cores header ``rte_service.h`` which provides
+the runtime functions to add, remove and remap service cores.
+
+.. code-block:: c
+
+        struct rte_service_spec service = {
+                .name = "service_name",
+        };
+        int ret = rte_service_component_register(services, &id);
+        if (ret)
+                return -1;
+
+        /* set the service itself to be ready to run. In the case of
+        * ethdev, eventdev etc PMDs, this will be set when the
+        * appropriate configure or setup function is called.
+        */
+        rte_service_component_runstate_set(id, 1);
+
+        /* Collect statistics for the service */
+        rte_service_set_stats_enable(id, 1);
+
+        /* The application sets the service to running state. Note that this
+         * function enables the service to run - while the 'component' version
+         * of this function (as above) marks the service itself as ready */
+        ret = rte_service_runstate_set(id, 1);
+
+
+Controlling A Service Core
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+This section demonstrates how to add a service core. The ``rte_service.h``
+header file provides the functions for dynamically adding and removing cores.
+The APIs to add and remove cores use lcore IDs similar to existing DPDK
+functions.
+
+These are the functions to start a service core, and have it run a service:
+
+.. code-block:: c
+
+        /* the lcore ID to use as a service core */
+        uint32_t service_core_id = 7;
+        ret = rte_service_lcore_add(service_core_id);
+        if(ret)
+                return -1;
+
+        /* service cores are in "stopped" state when added, so start it */
+        ret = rte_service_lcore_start(service_core_id);
+        if(ret)
+                return -1;
+
+        /* map a service to the service core, causing it to run the service */
+        uint32_t service_id; /* ID of a registered service */
+        uint32_t enable = 1; /* 1 maps the service, 0 unmaps */
+        ret = rte_service_map_lcore_set(service_id, service_core_id, enable);
+        if(ret)
+                return -1;
+
+
+Removing A Service Core
+~~~~~~~~~~~~~~~~~~~~~~~
+
+To remove a service core, the steps are similar to adding but in reverse order.
+Note that it is not allowed to remove a service core if the service is running,
+and the service-core is the only core running that service (see documentation
+for ``rte_service_lcore_stop`` function for details).
+
+
+Conclusion
+~~~~~~~~~~
+
+The service cores infrastructure provides DPDK with two main features. The first
+is to abstract away hardware differences: the service core can CPU cycles to
+a software fallback implementation, allowing the application to be abstracted
+from the difference in HW / SW availability. The second feature is a flexible
+method of registering functions to be run, allowing the running of the
+functions to be scaled across multiple CPUs. 
diff --git a/examples/Makefile b/examples/Makefile
index 28354ff..266451f 100644
--- a/examples/Makefile
+++ b/examples/Makefile
@@ -83,6 +83,7 @@ DIRS-$(CONFIG_RTE_LIBRTE_METER) += qos_meter
 DIRS-$(CONFIG_RTE_LIBRTE_SCHED) += qos_sched
 DIRS-y += quota_watermark
 DIRS-$(CONFIG_RTE_ETHDEV_RXTX_CALLBACKS) += rxtx_callbacks
+DIRS-y += service_cores
 DIRS-y += skeleton
 ifeq ($(CONFIG_RTE_LIBRTE_HASH),y)
 DIRS-$(CONFIG_RTE_LIBRTE_VHOST) += tep_termination
diff --git a/examples/service_cores/Makefile b/examples/service_cores/Makefile
new file mode 100644
index 0000000..bd4a345
--- /dev/null
+++ b/examples/service_cores/Makefile
@@ -0,0 +1,54 @@
+#   BSD LICENSE
+#
+#   Copyright(c) 2017 Intel Corporation. All rights reserved.
+#
+#   Redistribution and use in source and binary forms, with or without
+#   modification, are permitted provided that the following conditions
+#   are met:
+#
+#     * Redistributions of source code must retain the above copyright
+#       notice, this list of conditions and the following disclaimer.
+#     * Redistributions in binary form must reproduce the above copyright
+#       notice, this list of conditions and the following disclaimer in
+#       the documentation and/or other materials provided with the
+#       distribution.
+#     * Neither the name of Intel Corporation nor the names of its
+#       contributors may be used to endorse or promote products derived
+#       from this software without specific prior written permission.
+#
+#   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+#   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+#   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+#   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+#   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+#   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+#   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+#   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+#   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+#   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+#   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+ifeq ($(RTE_SDK),)
+$(error "Please define RTE_SDK environment variable")
+endif
+
+# Default target, can be overridden by command line or environment
+RTE_TARGET ?= x86_64-native-linuxapp-gcc
+
+include $(RTE_SDK)/mk/rte.vars.mk
+
+# binary name
+APP = service_cores
+
+# all source are stored in SRCS-y
+SRCS-y := main.c
+
+CFLAGS += $(WERROR_FLAGS)
+
+# workaround for a gcc bug with noreturn attribute
+# http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12603
+ifeq ($(CONFIG_RTE_TOOLCHAIN_GCC),y)
+CFLAGS_main.o += -Wno-return-type
+endif
+
+include $(RTE_SDK)/mk/rte.extapp.mk
diff --git a/examples/service_cores/main.c b/examples/service_cores/main.c
new file mode 100644
index 0000000..8a8f5bd
--- /dev/null
+++ b/examples/service_cores/main.c
@@ -0,0 +1,247 @@
+/*
+ *   BSD LICENSE
+ *
+ *   Copyright(c) 2017 Intel Corporation. All rights reserved.
+ *
+ *   Redistribution and use in source and binary forms, with or without
+ *   modification, are permitted provided that the following conditions
+ *   are met:
+ *
+ *     * Redistributions of source code must retain the above copyright
+ *       notice, this list of conditions and the following disclaimer.
+ *     * Redistributions in binary form must reproduce the above copyright
+ *       notice, this list of conditions and the following disclaimer in
+ *       the documentation and/or other materials provided with the
+ *       distribution.
+ *     * Neither the name of Intel Corporation nor the names of its
+ *       contributors may be used to endorse or promote products derived
+ *       from this software without specific prior written permission.
+ *
+ *   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ *   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ *   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ *   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ *   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ *   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ *   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ *   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ *   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ *   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#include <unistd.h>
+#include <stdio.h>
+#include <string.h>
+#include <stdint.h>
+#include <errno.h>
+#include <sys/queue.h>
+
+#include <rte_memory.h>
+#include <rte_memzone.h>
+#include <rte_launch.h>
+#include <rte_eal.h>
+#include <rte_debug.h>
+#include <rte_cycles.h>
+
+/* allow application scheduling of the services */
+#include <rte_service.h>
+
+/* Allow application registration of its own services. An application does not
+ * have to register services, but it can be useful if it wishes to run a
+ * function on a core that is otherwise in use as a service core. In this
+ * example, all services are dummy services registered by the sample app itself.
+ */
+#include <rte_service_component.h>
+
+#define PROFILE_CORES_MAX 8
+#define PROFILE_SERVICE_PER_CORE 5
+
+/* dummy function to do "work" */
+static int32_t service_func(void *args)
+{
+	RTE_SET_USED(args);
+	rte_delay_us(2000);
+	return 0;
+}
+
+static struct rte_service_spec services[] = {
+	{"service_1", service_func, NULL, 0, 0},
+	{"service_2", service_func, NULL, 0, 0},
+	{"service_3", service_func, NULL, 0, 0},
+	{"service_4", service_func, NULL, 0, 0},
+	{"service_5", service_func, NULL, 0, 0},
+};
+#define NUM_SERVICES RTE_DIM(services)
+
+/* this struct holds the mapping of a particular core to all services */
+struct profile_for_core {
+	uint32_t mapped_services[PROFILE_SERVICE_PER_CORE];
+};
+
+/* struct that can be applied as the service core mapping. Items in this
+ * struct will be passed to the ordinary rte_service_* APIs to configure the
+ * service cores at runtime, based on the requirements.
+ *
+ * These profiles can be considered a "configuration" for the service cores,
+ * where switching profile just changes the number of cores and the mappings
+ * for each of them. As a result, the core requirements and performance of the
+ * application scales.
+ */
+struct profile {
+	char name[64];
+	uint32_t num_cores;
+	struct profile_for_core cores[PROFILE_CORES_MAX];
+};
+
+static struct profile profiles[] = {
+	/* profile 0: high performance */
+	{
+		.name = "High Performance",
+		.num_cores = 5,
+		.cores[0] = {.mapped_services = {1, 0, 0, 0, 0} },
+		.cores[1] = {.mapped_services = {0, 1, 0, 0, 0} },
+		.cores[2] = {.mapped_services = {0, 0, 1, 0, 0} },
+		.cores[3] = {.mapped_services = {0, 0, 0, 1, 0} },
+		.cores[4] = {.mapped_services = {0, 0, 0, 0, 1} },
+	},
+	/* profile 1: mid performance with single service priority */
+	{
+		.name = "Mid-High Performance",
+		.num_cores = 3,
+		.cores[0] = {.mapped_services = {1, 1, 0, 0, 0} },
+		.cores[1] = {.mapped_services = {0, 0, 1, 1, 0} },
+		.cores[2] = {.mapped_services = {0, 0, 0, 0, 1} },
+		.cores[3] = {.mapped_services = {0, 0, 0, 0, 0} },
+		.cores[4] = {.mapped_services = {0, 0, 0, 0, 0} },
+	},
+	/* profile 2: mid performance with single service priority */
+	{
+		.name = "Mid-Low Performance",
+		.num_cores = 2,
+		.cores[0] = {.mapped_services = {1, 1, 1, 0, 0} },
+		.cores[1] = {.mapped_services = {1, 1, 0, 1, 1} },
+		.cores[2] = {.mapped_services = {0, 0, 0, 0, 0} },
+		.cores[3] = {.mapped_services = {0, 0, 0, 0, 0} },
+		.cores[4] = {.mapped_services = {0, 0, 0, 0, 0} },
+	},
+	/* profile 3: scale down performance on single core */
+	{
+		.name = "Scale down performance",
+		.num_cores = 1,
+		.cores[0] = {.mapped_services = {1, 1, 1, 1, 1} },
+		.cores[1] = {.mapped_services = {0, 0, 0, 0, 0} },
+		.cores[2] = {.mapped_services = {0, 0, 0, 0, 0} },
+		.cores[3] = {.mapped_services = {0, 0, 0, 0, 0} },
+		.cores[4] = {.mapped_services = {0, 0, 0, 0, 0} },
+	},
+};
+#define NUM_PROFILES RTE_DIM(profiles)
+
+static int
+apply_profile(int profile_id)
+{
+	uint32_t i;
+	uint32_t s;
+	int ret;
+	struct profile *p = &profiles[profile_id];
+	const uint8_t core_off = 1;
+
+	for (i = 0; i < p->num_cores; i++) {
+		uint32_t core = i + core_off;
+		ret = rte_service_lcore_add(core);
+		if (ret && ret != -EALREADY)
+			printf("core %d added ret %d\n", core, ret);
+
+		ret = rte_service_lcore_start(core);
+		if (ret && ret != -EALREADY)
+			printf("core %d start ret %d\n", core, ret);
+
+		for (s = 0; s < NUM_SERVICES; s++) {
+			if (rte_service_map_lcore_set(s, core,
+					p->cores[i].mapped_services[s]))
+				printf("failed to map lcore %d\n", core);
+		}
+	}
+
+	for ( ; i < PROFILE_CORES_MAX; i++) {
+		uint32_t core = i + core_off;
+		for (s = 0; s < NUM_SERVICES; s++) {
+			ret = rte_service_map_lcore_set(s, core, 0);
+			if (ret && ret != -EINVAL) {
+				printf("%s %d: map lcore set = %d\n", __func__,
+						__LINE__, ret);
+			}
+		}
+		ret = rte_service_lcore_stop(core);
+		if (ret && ret != -EALREADY) {
+			printf("%s %d: lcore stop = %d\n", __func__,
+					__LINE__, ret);
+		}
+		ret = rte_service_lcore_del(core);
+		if (ret && ret != -EINVAL) {
+			printf("%s %d: lcore del = %d\n", __func__,
+					__LINE__, ret);
+		}
+	}
+}
+
+int
+main(int argc, char **argv)
+{
+	int ret;
+
+	ret = rte_eal_init(argc, argv);
+	if (ret < 0)
+		rte_panic("Cannot init EAL\n");
+
+	uint32_t i;
+	for (i = 0; i < NUM_SERVICES; i++) {
+		services[i].callback_userdata = 0;
+		uint32_t id;
+		ret = rte_service_component_register(&services[i], &id);
+		if (ret)
+			rte_exit(-1, "service register() failed");
+
+		/* set the service itself to be ready to run. In the case of
+		 * ethdev, eventdev etc PMDs, this will be set when the
+		 * appropriate configure or setup function is called.
+		 */
+		rte_service_component_runstate_set(id, 1);
+
+		/* Collect statistics for the service */
+		rte_service_set_stats_enable(id, 1);
+
+		/* the application sets the service to be active. Note that the
+		 * previous component_runstate_set() is the PMD indicating
+		 * ready, while this function is the application setting the
+		 * service to run. Applications can choose to not run a service
+		 * by setting runstate to 0 at any time.
+		 */
+		ret = rte_service_runstate_set(id, 1);
+		if (ret)
+			return -ENOEXEC;
+	}
+
+	i = 0;
+	while (1) {
+		const char clr[] = { 27, '[', '2', 'J', '\0' };
+		const char topLeft[] = { 27, '[', '1', ';', '1', 'H', '\0' };
+		printf("%s%s", clr, topLeft);
+
+		apply_profile(i);
+		printf("\n==> Profile: %s\n\n", profiles[i].name);
+
+		sleep(1);
+		rte_service_dump(stdout, UINT32_MAX);
+
+		sleep(5);
+		rte_service_dump(stdout, UINT32_MAX);
+
+		i++;
+		if (i >= NUM_PROFILES)
+			i = 0;
+	}
+
+	return 0;
+}
-- 
2.7.4

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [dpdk-dev] [PATCH v2] example: add new service cores sample application
  2017-10-19 10:31 ` [dpdk-dev] [PATCH v2] " Harry van Haaren
@ 2017-10-23 14:58   ` Eads, Gage
  2017-10-24 21:02   ` Thomas Monjalon
  1 sibling, 0 replies; 9+ messages in thread
From: Eads, Gage @ 2017-10-23 14:58 UTC (permalink / raw)
  To: Van Haaren, Harry, dev; +Cc: thomas, Mcnamara, John



> -----Original Message-----
> From: Van Haaren, Harry
> Sent: Thursday, October 19, 2017 5:31 AM
> To: dev@dpdk.org
> Cc: thomas@monjalon.net; Mcnamara, John <john.mcnamara@intel.com>;
> Eads, Gage <gage.eads@intel.com>; Van Haaren, Harry
> <harry.van.haaren@intel.com>
> Subject: [PATCH v2] example: add new service cores sample application
> 
> This commit adds a new sample app, which showcases the value of running
> services. In particular it allows the application to dynamically schedule services
> to service-cores.
> 
> The sample app itself registers a number of dummy services, and applies
> different profiles to them at runtime. Note that this sample application does not
> forward any traffic - it demonstrates advanced usage of the service cores API.
> 
> Signed-off-by: Harry van Haaren <harry.van.haaren@intel.com>
> 

Acked-by: Gage Eads <gage.eads@intel.com>

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [dpdk-dev] [PATCH v2] example: add new service cores sample application
  2017-10-19 10:31 ` [dpdk-dev] [PATCH v2] " Harry van Haaren
  2017-10-23 14:58   ` Eads, Gage
@ 2017-10-24 21:02   ` Thomas Monjalon
  1 sibling, 0 replies; 9+ messages in thread
From: Thomas Monjalon @ 2017-10-24 21:02 UTC (permalink / raw)
  To: Harry van Haaren; +Cc: dev, john.mcnamara, gage.eads

19/10/2017 12:31, Harry van Haaren:
> This commit adds a new sample app, which showcases the value
> of running services. In particular it allows the application
> to dynamically schedule services to service-cores.
> 
> The sample app itself registers a number of dummy services,
> and applies different profiles to them at runtime. Note that
> this sample application does not forward any traffic - it
> demonstrates advanced usage of the service cores API.
> 
> Signed-off-by: Harry van Haaren <harry.van.haaren@intel.com>

Compilation error with clang:
	examples/service_cores/main.c:187:1: error:
		control reaches end of non-void function
Fixed by declaring function return as void.

Applied, thanks

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [dpdk-dev] [PATCH] example: add new service cores sample application
  2017-09-25 16:32 [dpdk-dev] [PATCH] " Eads, Gage
@ 2017-10-19 10:02 ` Van Haaren, Harry
  0 siblings, 0 replies; 9+ messages in thread
From: Van Haaren, Harry @ 2017-10-19 10:02 UTC (permalink / raw)
  To: Eads, Gage; +Cc: dev

> From: Eads, Gage 
> Sent: Monday, September 25, 2017 5:32 PM
> To: Van Haaren, Harry <harry.van.haaren@intel.com>
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] example: add new service cores sample application
> 
> Neat example. Looks good overall, I just have a few questions.
> 
> > +#define PROFILE_SERVICE_PER_CORE 8
> 
> Any reason not to use 5 here? That would remove a few zeroes from the profiles[] initializers.

Nope - good suggestion, Fixed in v2.


> > +static int
> > +apply_profile(int profile_id)
> > +{
> > +          uint32_t i;
> > +          uint32_t s;
> > +          int ret;
> > +          struct profile *p = &profiles[profile_id];
> > +          const uint8_t core_off = 1;
> > +
> > +          for (i = 0; i < p->num_cores; i++) {
> > +                         ret = rte_service_lcore_add(i + core_off);
> > +                         if (ret && ret != -EALREADY)
> > +                                        printf("core %d added ret %d\n", i + core_off, ret);
> 
> I'm wondering if this and the other printfs in this function should be rte_panics? These seem like fatal errors.

They're not fatal, they shouldn't (and don't) occur in the sample app. The error handling is there to be a good example - panic() doesn't seem a good suggestion to handle and error.. I'll leave as is.

> 
> > +
> > +                         ret = rte_service_lcore_start(i + core_off);
> > +                         if (ret && ret != -EALREADY)
> > +                                        printf("core %d start ret %d\n", i + core_off, ret);
> > +
> > +                         for (s = 0; s < NUM_SERVICES; s++) {
> > +                                        if (rte_service_map_lcore_set(s, i + core_off,
> > +                                                                      p->cores[i].mapped_services[s]))
> > +                                                       rte_panic("failed to map lcore to 1\n");
> 
> What does '1' refer to here? Perhaps it should be: rte_panic("failed to map lcore %d to %s\n", i + core_off, services[s].name);

Good catch, fixed in v2.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [dpdk-dev] [PATCH] example: add new service cores sample application
@ 2017-09-25 16:32 Eads, Gage
  2017-10-19 10:02 ` Van Haaren, Harry
  0 siblings, 1 reply; 9+ messages in thread
From: Eads, Gage @ 2017-09-25 16:32 UTC (permalink / raw)
  To: Van Haaren, Harry; +Cc: dev

Neat example. Looks good overall, I just have a few questions.

> +#define PROFILE_SERVICE_PER_CORE 8

Any reason not to use 5 here? That would remove a few zeroes from the profiles[] initializers.

> +static int
> +apply_profile(int profile_id)
> +{
> +          uint32_t i;
> +          uint32_t s;
> +          int ret;
> +          struct profile *p = &profiles[profile_id];
> +          const uint8_t core_off = 1;
> +
> +          for (i = 0; i < p->num_cores; i++) {
> +                         ret = rte_service_lcore_add(i + core_off);
> +                         if (ret && ret != -EALREADY)
> +                                        printf("core %d added ret %d\n", i + core_off, ret);

I'm wondering if this and the other printfs in this function should be rte_panics? These seem like fatal errors.

> +
> +                         ret = rte_service_lcore_start(i + core_off);
> +                         if (ret && ret != -EALREADY)
> +                                        printf("core %d start ret %d\n", i + core_off, ret);
> +
> +                         for (s = 0; s < NUM_SERVICES; s++) {
> +                                        if (rte_service_map_lcore_set(s, i + core_off,
> +                                                                      p->cores[i].mapped_services[s]))
> +                                                       rte_panic("failed to map lcore to 1\n");

What does '1' refer to here? Perhaps it should be: rte_panic("failed to map lcore %d to %s\n", i + core_off, services[s].name);

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2017-10-24 21:02 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-09-25 13:23 [dpdk-dev] [PATCH] example: add new service cores sample application Harry van Haaren
2017-10-13 22:20 ` Thomas Monjalon
2017-10-13 22:24   ` Thomas Monjalon
2017-10-19 10:04     ` Van Haaren, Harry
2017-10-19 10:31 ` [dpdk-dev] [PATCH v2] " Harry van Haaren
2017-10-23 14:58   ` Eads, Gage
2017-10-24 21:02   ` Thomas Monjalon
2017-09-25 16:32 [dpdk-dev] [PATCH] " Eads, Gage
2017-10-19 10:02 ` Van Haaren, Harry

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).