DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Burakov, Anatoly" <anatoly.burakov@intel.com>
To: oulijun <oulijun@huawei.com>, Thomas Monjalon <thomas@monjalon.net>
Cc: Ferruh Yigit <ferruh.yigit@intel.com>, dev <dev@dpdk.org>,
	linuxarm@openeuler.org
Subject: Re: [dpdk-dev]  【Some Questions About Multi-Process Resource Cleaning】
Date: Wed, 10 Feb 2021 15:59:13 +0000	[thread overview]
Message-ID: <d72f10c3-8c2d-be85-4c9c-8eace33c7a81@intel.com> (raw)
In-Reply-To: <0aacfa1e-2191-c196-ac73-fad99c016aec@huawei.com>

On 04-Feb-21 11:47 AM, oulijun wrote:
> 
> 
>> Hi,
>>
>> Sorry your questions are quite confused.
>> Please start explaining what is the problem you are trying to solve.
> Start the master and slave processes at the same time, and then run the 
> kill -9 command to kill the slave processes.
> The slave process should call rte_eal_cleanup to release resources. But 
> I find that there is no release from the process,
> and I think there is a resource leak.

To add to others, not only there will be a resource leak whenever you're 
killing processes with SIGKILL, the cleanup is up to individual 
applications to perform. It is not the responsibility of the DPDK 
library itself to install signal handlers and handle SIGINT or others.

So, if the application leaks resources, it's up to the application to 
catch termination signals and clean up after itself. Unfortunately, 
there's also no way to recover any leaked memory that has gone out this 
way: there is no garbage collection or any similar mechanism in DPDK. 
Therefore, while primary-secondary process model is slightly more 
resilient than single-process model, there are no mechanisms to reclaim 
memory from a crashed process, and crashing secondary process still 
leads to undefined behavior.

For example, a crashing secondary process may crash while holding a 
lock, and there's no way to release the lock without reinitializing the 
lock (which often means restart). The secondary process may also crash 
while processing buffers, and those in-flight buffers will be lost. 
There's nothing we can do about it, at least for now.

-- 
Thanks,
Anatoly

  parent reply	other threads:[~2021-02-10 15:59 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-04  6:56 oulijun
2021-02-04  9:25 ` Thomas Monjalon
2021-02-04 11:47   ` oulijun
2021-02-04 12:29     ` Bruce Richardson
2021-02-04 12:30     ` Thomas Monjalon
2021-02-10 15:59     ` Burakov, Anatoly [this message]
2021-03-08  8:56       ` oulijun

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=d72f10c3-8c2d-be85-4c9c-8eace33c7a81@intel.com \
    --to=anatoly.burakov@intel.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=linuxarm@openeuler.org \
    --cc=oulijun@huawei.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).