From: Stephen Hemminger <stephen@networkplumber.org>
To: <erezf@nvidia.com>
Cc: <dev@dpdk.org>, <viacheslavo@nvidia.com>, <matan@nvidia.com>,
<rasland@nvidia.com>, <stable@dpdk.org>
Subject: Re: [PATCH] common/mlx5: adjust fork call with the new kernel API
Date: Wed, 24 May 2023 07:50:13 -0700 [thread overview]
Message-ID: <20230524075013.3c2f7b6e@hermes.local> (raw)
In-Reply-To: <20230524120140.416144-1-erezf@nvidia.com>
On Wed, 24 May 2023 15:01:40 +0300
<erezf@nvidia.com> wrote:
> From: Erez Ferber <erezf@nvidia.com>
>
> While doing process fork() the operating system remaps all the parent
> process's memory to the address space of the child process and activates
> the Copy-on-Write mechanics - it duplicates physical pages once memory
> writing happens in the child process. Sometimes memory duplication is
> not allowed - for example, if the page contains hardware queue
> descriptors. To handle similar issues the rdma-core library should be
> prepared for forking.
>
> The ibv_fork_init() prepares the library to track all the related memory
> and prevent it from forking using madvise() system API. This approach
> allows fork, but not all the memory is forked to the child process and,
> application should care not to touch pages where the parent application
> allocated the rdma-core objects.
>
> The newer kernels propose an option of copy-on-fork for DMA pages and
> tracking all the memory and disabling it for the forking is no longer
> needed. The new API routine ibv_is_fork_initialized() should be involved
> to decide if library initialization for forking is required.
>
> Fixes: 0e83b8e536 ("net/mlx5: move rdma-core calls to separate file")
> Cc: stable@dpdk.org
> Signed-off-by: Erez Ferber <erezf@nvidia.com>
I don't think DPDK applications should fork(), and lots other
parts of the shared huge pages will break if an application does this.
next prev parent reply other threads:[~2023-05-24 14:50 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-24 12:01 [PATCH] common/mlx5: adjust fork call with the new kernel API erezf
2023-05-24 14:50 ` Stephen Hemminger [this message]
2023-05-25 8:10 ` Slava Ovsiienko
2023-05-25 15:27 ` Stephen Hemminger
2023-05-26 8:05 ` Slava Ovsiienko
2023-05-24 16:05 ` Slava Ovsiienko
2023-06-22 12:19 ` Raslan Darawsheh
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=20230524075013.3c2f7b6e@hermes.local \
--to=stephen@networkplumber.org \
--cc=dev@dpdk.org \
--cc=erezf@nvidia.com \
--cc=matan@nvidia.com \
--cc=rasland@nvidia.com \
--cc=stable@dpdk.org \
--cc=viacheslavo@nvidia.com \
/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.