[dpdk-dev,v2,2/4] eal: add function to release internal resources
Checks
Commit Message
This commit adds a new function rte_eal_finalize().
The function serves as a hook to allow DPDK to release
internal resources (e.g.: hugepage allocations).
This function allows DPDK to become more like an ordinary
library, where the library context itself can be initialized
and finalized by the application.
The rte_exit() and rte_panic() functions must be considered,
particularly if they should call finalize() to cleanup any
resources or not. This patch adds the cleanup to rte_exit(),
but does not clean up on rte_panic(). The reason to not clean
up on panicing is that the developer may wish to inspect the
exact internal state of EAL.
Signed-off-by: Harry van Haaren <harry.van.haaren@intel.com>
---
v2:
- Add eal_common.c file to commit, fixing build (Vipin)
[OT] Meson/ninja has a nice feature to avoid this error: ninja dist
Cc: thomas@monjalon.net
Cc: vipin.varghese@intel.com
---
doc/guides/prog_guide/env_abstraction_layer.rst | 8 ++++++++
doc/guides/rel_notes/release_18_02.rst | 9 +++++++++
lib/librte_eal/bsdapp/eal/Makefile | 1 +
lib/librte_eal/bsdapp/eal/eal_debug.c | 5 +++++
lib/librte_eal/common/eal_common.c | 11 +++++++++++
lib/librte_eal/common/include/rte_eal.h | 15 +++++++++++++++
lib/librte_eal/linuxapp/eal/Makefile | 1 +
lib/librte_eal/linuxapp/eal/eal_debug.c | 5 +++++
lib/librte_eal/rte_eal_version.map | 1 +
9 files changed, 56 insertions(+)
create mode 100644 lib/librte_eal/common/eal_common.c
Comments
29/01/2018 11:45, Harry van Haaren:
> --- a/doc/guides/prog_guide/env_abstraction_layer.rst
> +++ b/doc/guides/prog_guide/env_abstraction_layer.rst
> +Finalizing and Cleanup
> +~~~~~~~~~~~~~~~~~~~~~~
> +
> +During the initialization of EAL resources such as hugepage backed memory can be
> +allocated by core components. The memory allocated during ``rte_eal_init()``
> +can be released by calling the ``rte_eal_finalize()`` function. Refer to the
> +API documentation for details.
About naming, what is better between
rte_eal_finalize() and
rte_eal_cleanup() ?
I tend to think that "cleanup" is more descriptive.
> From: Thomas Monjalon [mailto:thomas@monjalon.net]
> Sent: Monday, January 29, 2018 10:56 AM
> To: Van Haaren, Harry <harry.van.haaren@intel.com>
> Cc: dev@dpdk.org; Varghese, Vipin <vipin.varghese@intel.com>
> Subject: Re: [PATCH v2 2/4] eal: add function to release internal resources
>
> 29/01/2018 11:45, Harry van Haaren:
> > --- a/doc/guides/prog_guide/env_abstraction_layer.rst
> > +++ b/doc/guides/prog_guide/env_abstraction_layer.rst
> > +Finalizing and Cleanup
> > +~~~~~~~~~~~~~~~~~~~~~~
> > +
> > +During the initialization of EAL resources such as hugepage backed memory
> can be
> > +allocated by core components. The memory allocated during
> ``rte_eal_init()``
> > +can be released by calling the ``rte_eal_finalize()`` function. Refer to
> the
> > +API documentation for details.
>
> About naming, what is better between
> rte_eal_finalize() and
> rte_eal_cleanup() ?
> I tend to think that "cleanup" is more descriptive.
Sure cleanup() is fine for me, I'll spin a v3 with the function name change.
29/01/2018 12:10, Van Haaren, Harry:
> > From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > Sent: Monday, January 29, 2018 10:56 AM
> > To: Van Haaren, Harry <harry.van.haaren@intel.com>
> > Cc: dev@dpdk.org; Varghese, Vipin <vipin.varghese@intel.com>
> > Subject: Re: [PATCH v2 2/4] eal: add function to release internal resources
> >
> > 29/01/2018 11:45, Harry van Haaren:
> > > --- a/doc/guides/prog_guide/env_abstraction_layer.rst
> > > +++ b/doc/guides/prog_guide/env_abstraction_layer.rst
> > > +Finalizing and Cleanup
> > > +~~~~~~~~~~~~~~~~~~~~~~
> > > +
> > > +During the initialization of EAL resources such as hugepage backed memory
> > can be
> > > +allocated by core components. The memory allocated during
> > ``rte_eal_init()``
> > > +can be released by calling the ``rte_eal_finalize()`` function. Refer to
> > the
> > > +API documentation for details.
> >
> > About naming, what is better between
> > rte_eal_finalize() and
> > rte_eal_cleanup() ?
> > I tend to think that "cleanup" is more descriptive.
>
> Sure cleanup() is fine for me, I'll spin a v3 with the function name change.
Harry, it is a real question!
If someone thinks "finalize" is better, I would like to hear it
because we may use the same wording in more DPDK functions.
On Mon, Jan 29, 2018 at 12:55:35PM +0100, Thomas Monjalon wrote:
> 29/01/2018 12:10, Van Haaren, Harry:
> > > From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > > Sent: Monday, January 29, 2018 10:56 AM
> > > To: Van Haaren, Harry <harry.van.haaren@intel.com>
> > > Cc: dev@dpdk.org; Varghese, Vipin <vipin.varghese@intel.com>
> > > Subject: Re: [PATCH v2 2/4] eal: add function to release internal resources
> > >
> > > 29/01/2018 11:45, Harry van Haaren:
> > > > --- a/doc/guides/prog_guide/env_abstraction_layer.rst
> > > > +++ b/doc/guides/prog_guide/env_abstraction_layer.rst
> > > > +Finalizing and Cleanup
> > > > +~~~~~~~~~~~~~~~~~~~~~~
> > > > +
> > > > +During the initialization of EAL resources such as hugepage backed memory
> > > can be
> > > > +allocated by core components. The memory allocated during
> > > ``rte_eal_init()``
> > > > +can be released by calling the ``rte_eal_finalize()`` function. Refer to
> > > the
> > > > +API documentation for details.
> > >
> > > About naming, what is better between
> > > rte_eal_finalize() and
> > > rte_eal_cleanup() ?
> > > I tend to think that "cleanup" is more descriptive.
> >
> > Sure cleanup() is fine for me, I'll spin a v3 with the function name change.
>
> Harry, it is a real question!
> If someone thinks "finalize" is better, I would like to hear it
> because we may use the same wording in more DPDK functions.
>
I like finalize better.
1) Both initialize and finalize sound similar as both end in "ize" so
sound like they are a pair
2) The use of .init and .fini elf sessions are precedent for the naming
/Bruce
> From: Thomas Monjalon [mailto:thomas@monjalon.net]
> Sent: Monday, January 29, 2018 11:56 AM
> To: Van Haaren, Harry <harry.van.haaren@intel.com>
> Cc: dev@dpdk.org; Varghese, Vipin <vipin.varghese@intel.com>
> Subject: Re: [PATCH v2 2/4] eal: add function to release internal resources
>
> 29/01/2018 12:10, Van Haaren, Harry:
> > > From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > > Sent: Monday, January 29, 2018 10:56 AM
> > > To: Van Haaren, Harry <harry.van.haaren@intel.com>
> > > Cc: dev@dpdk.org; Varghese, Vipin <vipin.varghese@intel.com>
> > > Subject: Re: [PATCH v2 2/4] eal: add function to release internal
> resources
> > >
> > > 29/01/2018 11:45, Harry van Haaren:
> > > > --- a/doc/guides/prog_guide/env_abstraction_layer.rst
> > > > +++ b/doc/guides/prog_guide/env_abstraction_layer.rst
> > > > +Finalizing and Cleanup
> > > > +~~~~~~~~~~~~~~~~~~~~~~
> > > > +
> > > > +During the initialization of EAL resources such as hugepage backed
> memory
> > > can be
> > > > +allocated by core components. The memory allocated during
> > > ``rte_eal_init()``
> > > > +can be released by calling the ``rte_eal_finalize()`` function. Refer
> to
> > > the
> > > > +API documentation for details.
> > >
> > > About naming, what is better between
> > > rte_eal_finalize() and
> > > rte_eal_cleanup() ?
> > > I tend to think that "cleanup" is more descriptive.
> >
> > Sure cleanup() is fine for me, I'll spin a v3 with the function name
> change.
>
> Harry, it is a real question!
Yup,
> If someone thinks "finalize" is better, I would like to hear it
> because we may use the same wording in more DPDK functions.
To me, finalize() and cleanup() mean the same thing.
I think cleanup() is a simpler term (and I like simple :)
Hence, v3 sent with cleanup()
@@ -99,6 +99,14 @@ It consist of calls to the pthread library (more specifically, pthread_self(), p
The creation and initialization functions for these objects are not multi-thread safe.
However, once initialized, the objects themselves can safely be used in multiple threads simultaneously.
+Finalizing and Cleanup
+~~~~~~~~~~~~~~~~~~~~~~
+
+During the initialization of EAL resources such as hugepage backed memory can be
+allocated by core components. The memory allocated during ``rte_eal_init()``
+can be released by calling the ``rte_eal_finalize()`` function. Refer to the
+API documentation for details.
+
Multi-process Support
~~~~~~~~~~~~~~~~~~~~~
@@ -41,6 +41,15 @@ New Features
Also, make sure to start the actual text at the margin.
=========================================================
+* **Add function to allow releasing internal EAL resources on exit**
+
+ During ``rte_eal_init()`` EAL allocates memory from hugepages to enable its
+ core libraries to perform their tasks. The ``rte_eal_finalize()`` function
+ releases these resources, ensuring that no hugepage memory is leaked. It is
+ expected that all DPDK applications call ``rte_eal_finalize()`` before
+ exiting. Not calling this function could result in leaking hugepages, leading
+ to failure during initialization of secondary processes.
+
* **Added the ixgbe ethernet driver to support RSS with flow API.**
Rte_flow actually defined to include RSS, but till now, RSS is out of
@@ -34,6 +34,7 @@ SRCS-$(CONFIG_RTE_EXEC_ENV_BSDAPP) += eal_interrupts.c
SRCS-$(CONFIG_RTE_EXEC_ENV_BSDAPP) += eal_alarm.c
# from common dir
+SRCS-$(CONFIG_RTE_EXEC_ENV_BSDAPP) += eal_common.c
SRCS-$(CONFIG_RTE_EXEC_ENV_BSDAPP) += eal_common_lcore.c
SRCS-$(CONFIG_RTE_EXEC_ENV_BSDAPP) += eal_common_timer.c
SRCS-$(CONFIG_RTE_EXEC_ENV_BSDAPP) += eal_common_memzone.c
@@ -14,6 +14,7 @@
#include <rte_log.h>
#include <rte_debug.h>
#include <rte_common.h>
+#include <rte_eal.h>
#define BACKTRACE_SIZE 256
@@ -79,6 +80,10 @@ rte_exit(int exit_code, const char *format, ...)
va_end(ap);
#ifndef RTE_EAL_ALWAYS_PANIC_ON_ERROR
+ int ret = rte_eal_finalize();
+ if (ret)
+ RTE_LOG(CRIT, EAL,
+ "EAL could not release all resources, code %d\n", ret);
exit(exit_code);
#else
rte_dump_stack();
new file mode 100644
@@ -0,0 +1,11 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2018 Intel Corporation
+ */
+
+#include <rte_service_component.h>
+
+int rte_eal_finalize(void)
+{
+ rte_service_finalize();
+ return 0;
+}
@@ -170,6 +170,21 @@ int rte_eal_iopl_init(void);
int rte_eal_init(int argc, char **argv);
/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice
+ * Finalize the Environment Abstraction Layer (EAL)
+ *
+ * This function must be called to release any internal resources that EAL has
+ * allocated during rte_eal_init(). After this call, no DPDK function calls may
+ * be made. It is expected that common usage of this function is to call it
+ * just before terminating the process.
+ *
+ * @return 0 Successfully released all internal EAL resources
+ * @return -EFAULT There was an error in releasing all resources.
+ */
+int rte_eal_finalize(void);
+
+/**
* Check if a primary process is currently alive
*
* This function returns true when a primary process is currently
@@ -41,6 +41,7 @@ SRCS-$(CONFIG_RTE_EXEC_ENV_LINUXAPP) += eal_interrupts.c
SRCS-$(CONFIG_RTE_EXEC_ENV_LINUXAPP) += eal_alarm.c
# from common dir
+SRCS-$(CONFIG_RTE_EXEC_ENV_LINUXAPP) += eal_common.c
SRCS-$(CONFIG_RTE_EXEC_ENV_LINUXAPP) += eal_common_lcore.c
SRCS-$(CONFIG_RTE_EXEC_ENV_LINUXAPP) += eal_common_timer.c
SRCS-$(CONFIG_RTE_EXEC_ENV_LINUXAPP) += eal_common_memzone.c
@@ -14,6 +14,7 @@
#include <rte_log.h>
#include <rte_debug.h>
#include <rte_common.h>
+#include <rte_eal.h>
#define BACKTRACE_SIZE 256
@@ -79,6 +80,10 @@ rte_exit(int exit_code, const char *format, ...)
va_end(ap);
#ifndef RTE_EAL_ALWAYS_PANIC_ON_ERROR
+ int ret = rte_eal_finalize();
+ if (ret)
+ RTE_LOG(CRIT, EAL,
+ "EAL could not release all resources, code %d\n", ret);
exit(exit_code);
#else
rte_dump_stack();
@@ -215,6 +215,7 @@ EXPERIMENTAL {
rte_eal_devargs_insert;
rte_eal_devargs_parse;
rte_eal_devargs_remove;
+ rte_eal_finalize;
rte_eal_hotplug_add;
rte_eal_hotplug_remove;
rte_service_attr_get;