From: "Burakov, Anatoly" <anatoly.burakov@intel.com>
To: Jianfeng Tan <jianfeng.tan@intel.com>, dev@dpdk.org
Cc: bruce.richardson@intel.com, konstantin.ananyev@intel.com,
thomas@monjalon.net
Subject: Re: [PATCH 2/3] eal: add synchronous multi-process communication
Date: Mon, 11 Dec 2017 11:39:22 +0000 [thread overview]
Message-ID: <2a72864d-2592-43c5-58d8-4ab016739ebe@intel.com> (raw)
In-Reply-To: <1512067450-59203-3-git-send-email-jianfeng.tan@intel.com>
On 30-Nov-17 6:44 PM, Jianfeng Tan wrote:
> We need the synchronous way for multi-process communication, that
> is to say we need an immediate response after we send a message
> to the other side.
>
> We will stop the mp_handler thread, and after sending message,
> the send thread will wait there for reponse and process the
> respond.
>
> Suggested-by: Anatoly Burakov <anatoly.burakov@intel.com>
> Signed-off-by: Jianfeng Tan <jianfeng.tan@intel.com>
> ---
> lib/librte_eal/common/eal_common_proc.c | 53 +++++++++++++++++++++++++++++++--
> lib/librte_eal/common/include/rte_eal.h | 5 +++-
> 2 files changed, 55 insertions(+), 3 deletions(-)
>
> diff --git a/lib/librte_eal/common/eal_common_proc.c b/lib/librte_eal/common/eal_common_proc.c
> index 5d0a095..65ebaf2 100644
> --- a/lib/librte_eal/common/eal_common_proc.c
> +++ b/lib/librte_eal/common/eal_common_proc.c
> @@ -30,6 +30,8 @@
> * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> */
>
> +#define _GNU_SOURCE
> +
shouldn't this be in Makefile flags?
> #include <stdio.h>
> #include <fcntl.h>
> #include <stdlib.h>
> @@ -41,6 +43,8 @@
> #include <sys/un.h>
> #include <errno.h>
> #include <pthread.h>
> +#include <sys/eventfd.h>
> +#include <signal.h>
>
> #include <rte_log.h>
> #include <rte_eal.h>
> @@ -134,6 +138,7 @@ rte_eal_mp_action_unregister(const char *name)
>
> struct mp_fds {
> int efd;
> + int evfd; /* eventfd used for pausing mp_handler thread */
>
> union {
> /* fds for primary process */
> @@ -331,6 +336,13 @@ mp_handler(void *arg __rte_unused)
> exit(EXIT_FAILURE);
> }
>
> + ev.data.fd = mp_fds.evfd;
> + if (epoll_ctl(mp_fds.efd, EPOLL_CTL_ADD, ev.data.fd, &ev) < 0) {
> + RTE_LOG(ERR, EAL, "epoll_ctl failed: %s\n",
> + strerror(errno));
> + exit(EXIT_FAILURE);
here and in other places - rte_exit?
> + }
> +
> events = calloc(20, sizeof ev);
>
> while (1) {
> @@ -348,6 +360,14 @@ mp_handler(void *arg __rte_unused)
> continue;
> }
>
> + if (events[i].data.fd == mp_fds.evfd) {
> + RTE_LOG(INFO, EAL, "mp_handler thread will pause\n");
> + pause();
> + RTE_LOG(INFO, EAL, "mp_handler thread stops pausing\n");
> +
> + continue;
> + }
> +
> fd = events[i].data.fd;
>
> if ((events[i].events & EPOLLIN)) {
> @@ -377,13 +397,14 @@ mp_handler(void *arg __rte_unused)
> return NULL;
> }
>
> +static pthread_t tid;
> +
> int
> rte_eal_mp_channel_init(void)
> {
> int i, fd, ret;
> const char *path;
> struct sockaddr_un un;
> - pthread_t tid;
> char thread_name[RTE_MAX_THREAD_NAME_LEN];
>
> mp_fds.efd = epoll_create1(0);
> @@ -462,6 +483,8 @@ rte_eal_mp_channel_init(void)
> return -1;
> }
>
> + mp_fds.evfd = eventfd(0, 0);
> +
> return 0;
> }
>
> @@ -485,7 +508,8 @@ rte_eal_mp_sendmsg(const char *action_name,
> const void *params,
> int len_params,
> int fds[],
> - int fds_num)
> + int fds_num,
> + int need_ack)
I think "need_ack" is a misnomer because what we really want is not
"ack" but a response.
More importantly, i think for clarity's sake, this should be a separate
function - something like rte_eal_mp_sendreq() or maybe a better name
(reqdata? communicate?). Also, i don't think reusing send parameters is
a good idea - a user is expecting a response, so a user allocates data
for a response separately from requests, and passes it explicitly.
> {
> int i;
> int ret = 0;
> @@ -511,6 +535,11 @@ rte_eal_mp_sendmsg(const char *action_name,
>
> RTE_LOG(INFO, EAL, "send msg: %s, %d\n", action_name, len_msg);
>
> + if (need_ack) {
> + // stop mp_handler thread.
Do we accept C++-style comments?
> + eventfd_write(mp_fds.evfd, (eventfd_t)1);
> + }
> +
> msg = malloc(len_msg);
> if (!msg) {
> RTE_LOG(ERR, EAL, "Cannot alloc memory for msg\n");
> @@ -547,12 +576,32 @@ rte_eal_mp_sendmsg(const char *action_name,
> ret = send_msg(mp_fds.secondaries[i], &msgh);
> if (ret < 0)
> break;
> +
> + if (need_ack) {
> + /* We will hang there until the other side
> + * responses and what if other side is sending
> + * msg at the same time?
> + */
> + process_msg(mp_fds.secondaries[i]);
> + }
> }
> } else {
> ret = send_msg(mp_fds.primary, &msgh);
> +
> + if (ret > 0 && need_ack) {
> + // We will hang there until the other side responses
> + ret = process_msg(mp_fds.primary);
> + }
> }
>
> free(msg);
>
> + if (need_ack) {
> + // start mp_handler thread.
> + union sigval value;
it's not used, but still, maybe zero-initialize it?
> +
> + pthread_sigqueue(tid, 0, value);
> + }
> +
> return ret;
> }
> diff --git a/lib/librte_eal/common/include/rte_eal.h b/lib/librte_eal/common/include/rte_eal.h
> index 8776bcf..9875cae 100644
> --- a/lib/librte_eal/common/include/rte_eal.h
> +++ b/lib/librte_eal/common/include/rte_eal.h
> @@ -274,13 +274,16 @@ void rte_eal_mp_action_unregister(const char *name);
> * @param fds_num
> * The fds_num argument is number of fds to be sent with sendmsg.
> *
> + * @param need_ack
> + * The fds_num argument is number of fds to be sent with sendmsg.
> + *
> * @return
> * - (>=0) on success.
> * - (<0) on failure.
> */
> int
> rte_eal_mp_sendmsg(const char *action_name, const void *params,
> - int len_params, int fds[], int fds_num);
> + int len_params, int fds[], int fds_num, int need_ack);
>
> /**
> * Usage function typedef used by the application usage function.
>
--
Thanks,
Anatoly
next prev parent reply other threads:[~2017-12-11 11:39 UTC|newest]
Thread overview: 88+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-30 18:44 [PATCH 0/3] generic channel for multi-process communication Jianfeng Tan
2017-11-30 18:44 ` [PATCH 1/3] eal: add " Jianfeng Tan
2017-12-11 11:04 ` Burakov, Anatoly
2017-12-11 16:43 ` Ananyev, Konstantin
2017-11-30 18:44 ` [PATCH 2/3] eal: add synchronous " Jianfeng Tan
2017-12-11 11:39 ` Burakov, Anatoly [this message]
2017-12-11 16:49 ` Ananyev, Konstantin
2017-11-30 18:44 ` [PATCH 3/3] vfio: use the generic multi-process channel Jianfeng Tan
2017-12-11 12:01 ` Burakov, Anatoly
2017-12-11 9:59 ` [PATCH 0/3] generic channel for multi-process communication Burakov, Anatoly
2017-12-12 7:34 ` Tan, Jianfeng
2017-12-12 16:18 ` Burakov, Anatoly
2018-01-11 4:07 ` [PATCH v2 0/4] " Jianfeng Tan
2018-01-11 4:07 ` [PATCH v2 1/4] eal: add " Jianfeng Tan
2018-01-13 12:57 ` Burakov, Anatoly
2018-01-15 19:52 ` Ananyev, Konstantin
2018-01-11 4:07 ` [PATCH v2 2/4] eal: add and del secondary processes in the primary Jianfeng Tan
2018-01-13 13:11 ` Burakov, Anatoly
2018-01-15 21:45 ` Ananyev, Konstantin
2018-01-11 4:07 ` [PATCH v2 3/4] eal: add synchronous multi-process communication Jianfeng Tan
2018-01-13 13:41 ` Burakov, Anatoly
2018-01-16 0:00 ` Ananyev, Konstantin
2018-01-16 8:10 ` Tan, Jianfeng
2018-01-16 11:12 ` Ananyev, Konstantin
2018-01-16 16:47 ` Tan, Jianfeng
2018-01-17 10:50 ` Ananyev, Konstantin
2018-01-17 13:09 ` Tan, Jianfeng
2018-01-17 13:15 ` Tan, Jianfeng
2018-01-17 17:20 ` Ananyev, Konstantin
2018-01-11 4:07 ` [PATCH v2 4/4] vfio: use the generic multi-process channel Jianfeng Tan
2018-01-13 14:03 ` Burakov, Anatoly
2018-03-04 14:57 ` [PATCH v5] vfio: change to use " Jianfeng Tan
2018-03-14 13:27 ` Burakov, Anatoly
2018-03-19 6:53 ` Tan, Jianfeng
2018-03-20 10:33 ` Burakov, Anatoly
2018-03-20 10:56 ` Burakov, Anatoly
2018-03-20 8:50 ` [PATCH v6] " Jianfeng Tan
2018-04-05 14:26 ` Tan, Jianfeng
2018-04-05 14:39 ` Burakov, Anatoly
2018-04-12 23:27 ` Thomas Monjalon
2018-04-12 15:26 ` Burakov, Anatoly
2018-04-15 15:06 ` [PATCH v7] " Jianfeng Tan
2018-04-15 15:10 ` Tan, Jianfeng
2018-04-17 23:04 ` Thomas Monjalon
2018-01-25 4:16 ` [PATCH v3 0/3] generic channel for multi-process communication Jianfeng Tan
2018-01-25 4:16 ` [PATCH v3 1/3] eal: add " Jianfeng Tan
2018-01-25 10:41 ` Thomas Monjalon
2018-01-25 11:27 ` Burakov, Anatoly
2018-01-25 11:34 ` Thomas Monjalon
2018-01-25 12:21 ` Ananyev, Konstantin
2018-01-25 4:16 ` [PATCH v3 2/3] eal: add synchronous " Jianfeng Tan
2018-01-25 12:00 ` Burakov, Anatoly
2018-01-25 12:19 ` Burakov, Anatoly
2018-01-25 12:19 ` Ananyev, Konstantin
2018-01-25 12:25 ` Burakov, Anatoly
2018-01-25 13:00 ` Ananyev, Konstantin
2018-01-25 13:05 ` Burakov, Anatoly
2018-01-25 13:10 ` Burakov, Anatoly
2018-01-25 15:03 ` Ananyev, Konstantin
2018-01-25 16:22 ` Burakov, Anatoly
2018-01-25 17:10 ` Tan, Jianfeng
2018-01-25 18:02 ` Burakov, Anatoly
2018-01-25 12:22 ` Ananyev, Konstantin
2018-01-25 4:16 ` [PATCH v3 3/3] vfio: use the generic multi-process channel Jianfeng Tan
2018-01-25 10:47 ` Thomas Monjalon
2018-01-25 10:52 ` Burakov, Anatoly
2018-01-25 10:57 ` Thomas Monjalon
2018-01-25 12:15 ` Burakov, Anatoly
2018-01-25 19:14 ` [PATCH v4 0/2] generic channel for multi-process communication Jianfeng Tan
2018-01-25 19:14 ` [PATCH v4 1/2] eal: add synchronous " Jianfeng Tan
2018-01-25 19:14 ` [PATCH v4 2/2] vfio: use the generic multi-process channel Jianfeng Tan
2018-01-25 19:15 ` [PATCH v4 0/2] generic channel for multi-process communication Tan, Jianfeng
2018-01-25 19:21 ` [PATCH v5 " Jianfeng Tan
2018-01-25 19:21 ` [PATCH v5 1/2] eal: add " Jianfeng Tan
2018-01-25 19:21 ` [PATCH v5 2/2] eal: add synchronous " Jianfeng Tan
2018-01-25 21:23 ` [PATCH v5 0/2] generic channel for " Thomas Monjalon
2018-01-26 3:41 ` [PATCH v6 " Jianfeng Tan
2018-01-26 3:41 ` [PATCH v6 1/2] eal: add " Jianfeng Tan
2018-01-26 10:25 ` Burakov, Anatoly
2018-01-29 6:37 ` Tan, Jianfeng
2018-01-29 9:37 ` Burakov, Anatoly
2018-01-26 3:41 ` [PATCH v6 2/2] eal: add synchronous " Jianfeng Tan
2018-01-26 10:31 ` Burakov, Anatoly
2018-01-29 23:52 ` [PATCH v6 0/2] generic channel for " Thomas Monjalon
2018-01-30 6:58 ` [PATCH v7 " Jianfeng Tan
2018-01-30 6:58 ` [PATCH v7 1/2] eal: add " Jianfeng Tan
2018-01-30 6:58 ` [PATCH v7 2/2] eal: add synchronous " Jianfeng Tan
2018-01-30 14:46 ` [PATCH v7 0/2] generic channel for " Thomas Monjalon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2a72864d-2592-43c5-58d8-4ab016739ebe@intel.com \
--to=anatoly.burakov@intel.com \
--cc=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=jianfeng.tan@intel.com \
--cc=konstantin.ananyev@intel.com \
--cc=thomas@monjalon.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).