From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 4AA2BA054F; Wed, 10 Feb 2021 16:59:21 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id B3AA840693; Wed, 10 Feb 2021 16:59:20 +0100 (CET) Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by mails.dpdk.org (Postfix) with ESMTP id 1B94E40142 for ; Wed, 10 Feb 2021 16:59:18 +0100 (CET) IronPort-SDR: jQWvnFAx4AqdqGpdxFqZXrMd4qf6xHRMH00Xw0qx03ucORsuXEcRGSi9k8JjtBNd32C8vhDx5H VzFnC2p2V7KA== X-IronPort-AV: E=McAfee;i="6000,8403,9891"; a="246161334" X-IronPort-AV: E=Sophos;i="5.81,168,1610438400"; d="scan'208";a="246161334" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Feb 2021 07:59:17 -0800 IronPort-SDR: 4JZqKZWl6liW2USIsHk99U8PnwnqWdUORe7iZ+xHsTwt0HwDRkZoa+X4h50TlU9wn8H0eMZuvm TlqSIQiZnFCg== X-IronPort-AV: E=Sophos;i="5.81,168,1610438400"; d="scan'208";a="396755483" Received: from aburakov-mobl.ger.corp.intel.com (HELO [10.213.247.83]) ([10.213.247.83]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Feb 2021 07:59:16 -0800 To: oulijun , Thomas Monjalon Cc: Ferruh Yigit , dev , linuxarm@openeuler.org References: <8270022.kECihOmdav@thomas> <0aacfa1e-2191-c196-ac73-fad99c016aec@huawei.com> From: "Burakov, Anatoly" Message-ID: Date: Wed, 10 Feb 2021 15:59:13 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <0aacfa1e-2191-c196-ac73-fad99c016aec@huawei.com> Content-Type: text/plain; charset=gbk; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] =?utf-8?q?=E3=80=90Some_Questions_About_Multi-Process?= =?utf-8?q?_Resource_Cleaning=E3=80=91?= X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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