All of lore.kernel.org
 help / color / mirror / Atom feed
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 v2 2/4] eal: add and del secondary processes in the primary
Date: Sat, 13 Jan 2018 13:11:59 +0000	[thread overview]
Message-ID: <86c760cb-d679-4b19-df35-7b21387586d8@intel.com> (raw)
In-Reply-To: <1515643654-129489-3-git-send-email-jianfeng.tan@intel.com>

On 11-Jan-18 4:07 AM, Jianfeng Tan wrote:
> By the multi-process channel, we add an mp action named "proc".
> 
> As a secondary process starts, it sends a "proc add" message to
> the primary.
> 
> As the primary finds a failure in sending message to a specific
> secondary process, that secondary process is treated as exited;
> and we remove it from the secondary array by sending a "proc del"
> message to the primary itself.
> 
> Test:
>    1. Start the primary and the secondary process
>      $ (testpmd) -c 0x3 -n 4 -- -i
>      $ (helloworld) -c 0xc -n 4 --proc-type=auto --
> 
>    2. Check the log of testpmd:
>      ...
>      EAL: bind to /var/run/.rte_unix
>      ...
>      EAL: add secondary: /var/run/.testpmd_unix_(xxx)
>      ...
> 
>    3. Check the log of helloworld:
>      ...
>      EAL: bind to /var/run/.testpmd_unix_xxx
>      EAL: bind to /var/run/.testpmd_unix_c_xxx
>      ...

it says "unix" all over the place, but that's an internal implementation 
detail. "mp_socket" or similar should do, no?

> 
> Signed-off-by: Jianfeng Tan <jianfeng.tan@intel.com>
> ---
>   lib/librte_eal/common/eal_common_proc.c | 88 ++++++++++++++++++++++++++++++++-
>   1 file changed, 86 insertions(+), 2 deletions(-)
> 
> diff --git a/lib/librte_eal/common/eal_common_proc.c b/lib/librte_eal/common/eal_common_proc.c
> index d700e9e..70519cc 100644
> --- a/lib/librte_eal/common/eal_common_proc.c
> +++ b/lib/librte_eal/common/eal_common_proc.c
> @@ -54,6 +54,13 @@ struct mp_msghdr {
>   	char params[0];
>   } __rte_packed;
>   
> +struct proc_request {
> +#define MP_PROC_ADD	0
> +#define MP_PROC_DEL	1
> +	int type;
> +	char path[MAX_UNIX_PATH_LEN];
> +};
> +
>   int
>   rte_eal_primary_proc_alive(const char *config_file_path)
>   {
> @@ -214,6 +221,58 @@ mp_handle(void *arg __rte_unused)
>   	return NULL;
>   }
>   
> +static int
> +add_sec_proc(const char *path)
> +{
> +	int i;
> +
> +	for (i = 0; i < MAX_SECONDARY_PROCS; ++i)
> +		if (mp_sec_sockets[i] == NULL)
> +			break;
> +	if (i < MAX_SECONDARY_PROCS)
> +		mp_sec_sockets[i] = strdup(path);
> +
> +	return i < MAX_SECONDARY_PROCS;
> +}

While it's equivalent, the intent behind this isn't clear, it's 
needlessly complicating the more common idiom of

for (i = 0; i < MAX; i++) {}
if (i == MAX)
    return error;
do_something;
return success;

> +
> +static int
> +del_sec_proc(const char *path)
> +{
> +	int i;
> +
> +	for (i = 0; i < MAX_SECONDARY_PROCS; ++i) {
> +		if (!strcmp(mp_sec_sockets[i], path)) {
> +			free(mp_sec_sockets[i]);
> +			mp_sec_sockets[i] = NULL;
> +			break;
> +		}
> +	}
> +
> +	return i < MAX_SECONDARY_PROCS;
> +}

Same as above - maybe rewrite it as a more commonly used idiom. Also, 
you probably want to use strncmp(), and check for NULL pointers, IIRC 
strncmp(NULL) is undefined behavior.

> +
> +static int
> +mp_primary_proc(const void *params,
> +		int len __rte_unused,
> +		int fds[] __rte_unused,
> +		int fds_num __rte_unused)
> +{
> +	const struct proc_request *r = (const struct proc_request *)params;
> +
> +	switch (r->type) {
> +	case MP_PROC_ADD:
> +		RTE_LOG(INFO, EAL, "add secondary: %s\n", r->path);
> +		return add_sec_proc(r->path);
> +	case MP_PROC_DEL:
> +		RTE_LOG(INFO, EAL, "del secondary: %s\n", r->path);
> +		return del_sec_proc(r->path);
> +	default:
> +		RTE_LOG(ERR, EAL, "invalid type: %d\n", r->type);
> +	}
> +
> +	return -1;
> +}
> +
>   static inline const char *
>   get_unix_path(int is_server)
>   {
> @@ -267,6 +326,22 @@ rte_eal_mp_channel_init(void)
>   	if (mp_fd < 0)
>   		return -1;
>   
> +	if (rte_eal_process_type() == RTE_PROC_PRIMARY) {
> +		if (rte_eal_mp_action_register("proc", mp_primary_proc) < 0) {
> +			RTE_LOG(ERR, EAL, "failed to register handler\n");
> +			goto error;
> +		}
> +	} else {
> +		struct proc_request r;
> +
> +		r.type = MP_PROC_ADD;
> +		snprintf(r.path, MAX_UNIX_PATH_LEN, "%s", get_unix_path(1));

Nitpicking, but maybe just send PID instead of the whole path? 
Primary/secondary share their prefix and most of their socket path 
anyway, so the real difference is the PID. This would also eliminate the 
need for using strings in many places.

> +		if (rte_eal_mp_sendmsg("proc", &r, sizeof(r), NULL, 0) < 0) {
> +			RTE_LOG(ERR, EAL, "failed to add into primary\n");
> +			goto error;
> +		}
> +	}
> +
>   	if (pthread_create(&tid, NULL, mp_handle, NULL) < 0) {
>   		RTE_LOG(ERR, EAL, "failed to create mp handle thead: %s\n",
>   			strerror(errno));
> @@ -354,10 +429,19 @@ send_msg(int fd, const char *dst_path, struct mp_msghdr *msg, int fds[])
>   	if (ret < 0) {
>   		RTE_LOG(ERR, EAL, "failed to send msg: %s\n", strerror(errno));
>   
> -		if (rte_eal_process_type() == RTE_PROC_PRIMARY)
> +		if (rte_eal_process_type() == RTE_PROC_PRIMARY) {
> +			struct proc_request r;
> +
>   			RTE_LOG(ERR, EAL, "secondary process (%s) exited\n",
>   				dst_path);
> -		else if (!rte_eal_primary_proc_alive(NULL))
> +			r.type = MP_PROC_DEL;
> +			snprintf(r.path, MAX_UNIX_PATH_LEN, "%s", dst_path);
> +			if (rte_eal_mp_sendmsg("proc", &r,
> +						sizeof(r), NULL, 0) < 0)
> +				RTE_LOG(ERR, EAL,
> +					"failed to del secondary %s\n",
> +					dst_path);
> +		} else if (!rte_eal_primary_proc_alive(NULL))
>   			RTE_LOG(ERR, EAL, "primary process exited\n");
>   
>   		return 0;
> 


-- 
Thanks,
Anatoly

  reply	other threads:[~2018-01-13 13:12 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
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 [this message]
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=86c760cb-d679-4b19-df35-7b21387586d8@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.