[dpdk-dev] [PATCH v6] eal: add function to check if primary proc alive
On Tue, Mar 8, 2016 at 2:57 PM, Van Haaren, Harry wrote: >> From: David Marchand [mailto:david.marchand at 6wind.com] >> >> The issue is that if a secondary process is initialized, it holds a read >> >> lock on /var/run/.rte_config and this prevents a primary from starting. >> > >> > The new function is advertised as a monitoring feature. >> > But it seems to be also a workaround for an ordering issue when starting >> > primary and secondary processes concurrently, right? >> >> +1 > > You are correct, the function rte_eal_primary_proc_alive() added here is > for monitoring if there is a primary process alive. > > The rte_eal_mcfg_complete() function call in rte_eal_init() is delayed > to avoid a race-condition between secondary and primary processes. > This race-condition occurs when two processes probe the PCI devices > at the same time. > > Delaying the rte_eal_mcfg_complete() call until after the primary has > finished rte_eal_pci_probe() ensures that this race condition is avoided. Then, those are two different things. Can you split this into two patches: one for the fix and one for the new function ? CCing sergio, who is the multi process maintainer. Thanks. -- David Marchand
[dpdk-dev] [PATCH v6] eal: add function to check if primary proc alive
> From: David Marchand [mailto:david.marchand at 6wind.com] > >> The issue is that if a secondary process is initialized, it holds a read > >> lock on /var/run/.rte_config and this prevents a primary from starting. > > > > The new function is advertised as a monitoring feature. > > But it seems to be also a workaround for an ordering issue when starting > > primary and secondary processes concurrently, right? > > +1 You are correct, the function rte_eal_primary_proc_alive() added here is for monitoring if there is a primary process alive. The rte_eal_mcfg_complete() function call in rte_eal_init() is delayed to avoid a race-condition between secondary and primary processes. This race-condition occurs when two processes probe the PCI devices at the same time. Delaying the rte_eal_mcfg_complete() call until after the primary has finished rte_eal_pci_probe() ensures that this race condition is avoided. -Harry
[dpdk-dev] [PATCH v6] eal: add function to check if primary proc alive
On Tue, Mar 8, 2016 at 12:13 PM, Thomas Monjalon wrote: > 2016-03-08 09:58, Van Haaren, Harry: >> From: David Marchand [mailto:david.marchand at 6wind.com] >> > When I look at this new api, I am under the impression that you are >> > supposed to check for primary liveliness once dpdk init has finished >> > (from your secondary process point of view), not before and not while >> > it is initialising. >> >> The issue is that if a secondary process is initialized, it holds a read >> lock on /var/run/.rte_config and this prevents a primary from starting. > > The new function is advertised as a monitoring feature. > But it seems to be also a workaround for an ordering issue when starting > primary and secondary processes concurrently, right? +1 -- David Marchand
[dpdk-dev] [PATCH v6] eal: add function to check if primary proc alive
2016-03-08 09:58, Van Haaren, Harry: > From: David Marchand [mailto:david.marchand at 6wind.com] > > When I look at this new api, I am under the impression that you are > > supposed to check for primary liveliness once dpdk init has finished > > (from your secondary process point of view), not before and not while > > it is initialising. > > The issue is that if a secondary process is initialized, it holds a read > lock on /var/run/.rte_config and this prevents a primary from starting. The new function is advertised as a monitoring feature. But it seems to be also a workaround for an ordering issue when starting primary and secondary processes concurrently, right?
[dpdk-dev] [PATCH v6] eal: add function to check if primary proc alive
Hi David,
> From: David Marchand [mailto:david.marchand at 6wind.com]
> Subject: Re: [PATCH v6] eal: add function to check if primary proc alive
> When I look at this new api, I am under the impression that you are
> supposed to check for primary liveliness once dpdk init has finished
> (from your secondary process point of view), not before and not while
> it is initialising.
The issue is that if a secondary process is initialized, it holds a read
lock on /var/run/.rte_config and this prevents a primary from starting.
So we *must* detect a primary process being ready to attach to, *without*
having called rte_eal_init() in the secondary process.
> Why do you need to move this ?
Issues arise when a primary and secondary process both scan the PCI devices
at the same time. Moving rte_eal_mcfg_complete() solves this race-cond
because the secondary process will wait until the primary is finished.
> > + if (config_file_path)
> > + config_fd = open(config_file_path, O_RDONLY);
> > + else {
> > + char default_path[PATH_MAX+1];
> > + snprintf(default_path, PATH_MAX, RUNTIME_CONFIG_FMT,
> > +default_config_dir, "rte");
> > + config_fd = open(default_path, O_RDONLY);
>
> Can't you reuse eal_runtime_config_path() here ?
No, as rte_eal_init() has not been called, for the same reason as above.
As rte_eal_init() has not been called, the shared config that is read by
eal_runtime_config_path() has not been initialized.
-Harry
[dpdk-dev] [PATCH v6] eal: add function to check if primary proc alive
This patch adds a new function to the EAL API:
int rte_eal_primary_proc_alive(const char *path);
The function indicates if a primary process is alive right now.
This functionality is implemented by testing for a write-
lock on the config file, and the function tests for a lock.
The use case for this functionality is that a secondary
process can wait until a primary process starts by polling
the function and waiting. When the primary is running, the
secondary continues to poll to detect if the primary process
has quit unexpectedly, the secondary process can detect this.
The RTE_MAGIC number is written to the shared config by the
primary process, this is the signal to the secondary process
that the EAL is set up, and ready to be used. The function
rte_eal_mcfg_complete() writes RTE_MAGIC. This has been
delayed in the EAL init proceedure, as the PCI probing in
the primary process can interfere with the secondary running.
Signed-off-by: Harry van Haaren
Acked-by: Maryam Tahhan
---
v6:
- Fix license header
v5:
- Renamed returns in doc from words to digits
- Fixed line spacing in docs
- Fixed line spacing in EAL header
- Rebased to master (Makefile conflicts)
v4:
- Rebased to git head (2.3 -> 16.04 changes)
v3:
- Fixed Copyright years
v2:
- Passing NULL as const char* uses default /var/run/.rte_config
- Moved code into /common/ instead of /linuxapp/, should work on BSD now
---
doc/guides/rel_notes/release_16_04.rst | 8
lib/librte_eal/bsdapp/eal/Makefile | 1 +
lib/librte_eal/bsdapp/eal/rte_eal_version.map | 1 +
lib/librte_eal/common/eal_common_proc.c | 61 +
lib/librte_eal/common/include/rte_eal.h | 20 +++-
lib/librte_eal/linuxapp/eal/Makefile| 3 +-
lib/librte_eal/linuxapp/eal/eal.c | 6 +--
lib/librte_eal/linuxapp/eal/rte_eal_version.map | 1 +
8 files changed, 96 insertions(+), 5 deletions(-)
create mode 100644 lib/librte_eal/common/eal_common_proc.c
diff --git a/doc/guides/rel_notes/release_16_04.rst
b/doc/guides/rel_notes/release_16_04.rst
index 24f15bf..7d5000f 100644
--- a/doc/guides/rel_notes/release_16_04.rst
+++ b/doc/guides/rel_notes/release_16_04.rst
@@ -74,6 +74,14 @@ EAL
~~~
+* **Added rte_eal_primary_proc_alive() function**
+
+ A new function ``rte_eal_primary_proc_alive()`` has been added
+ to allow the user to detect if a primary process is running.
+ Use cases for this feature include fault detection, and monitoring
+ using secondary processes.
+
+
Drivers
~~~
diff --git a/lib/librte_eal/bsdapp/eal/Makefile
b/lib/librte_eal/bsdapp/eal/Makefile
index 9015516..9ecf429 100644
--- a/lib/librte_eal/bsdapp/eal/Makefile
+++ b/lib/librte_eal/bsdapp/eal/Makefile
@@ -79,6 +79,7 @@ SRCS-$(CONFIG_RTE_EXEC_ENV_BSDAPP) += eal_common_devargs.c
SRCS-$(CONFIG_RTE_EXEC_ENV_BSDAPP) += eal_common_dev.c
SRCS-$(CONFIG_RTE_EXEC_ENV_BSDAPP) += eal_common_options.c
SRCS-$(CONFIG_RTE_EXEC_ENV_BSDAPP) += eal_common_thread.c
+SRCS-$(CONFIG_RTE_EXEC_ENV_BSDAPP) += eal_common_proc.c
SRCS-$(CONFIG_RTE_EXEC_ENV_BSDAPP) += rte_malloc.c
SRCS-$(CONFIG_RTE_EXEC_ENV_BSDAPP) += malloc_elem.c
SRCS-$(CONFIG_RTE_EXEC_ENV_BSDAPP) += malloc_heap.c
diff --git a/lib/librte_eal/bsdapp/eal/rte_eal_version.map
b/lib/librte_eal/bsdapp/eal/rte_eal_version.map
index 0c24223..58c2951 100644
--- a/lib/librte_eal/bsdapp/eal/rte_eal_version.map
+++ b/lib/librte_eal/bsdapp/eal/rte_eal_version.map
@@ -148,5 +148,6 @@ DPDK_16.04 {
rte_eal_pci_ioport_write;
rte_eal_pci_map_device;
rte_eal_pci_unmap_device;
+ rte_eal_primary_proc_alive;
} DPDK_2.2;
diff --git a/lib/librte_eal/common/eal_common_proc.c
b/lib/librte_eal/common/eal_common_proc.c
new file mode 100644
index 000..12e0fca
--- /dev/null
+++ b/lib/librte_eal/common/eal_common_proc.c
@@ -0,0 +1,61 @@
+/*-
+ * BSD LICENSE
+ *
+ * Copyright(c) 2016 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
