From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-f52.google.com (mail-pa0-f52.google.com [209.85.220.52]) by dpdk.org (Postfix) with ESMTP id D61B0106B for ; Tue, 7 Jul 2015 05:38:12 +0200 (CEST) Received: by pacgz10 with SMTP id gz10so31866297pac.3 for ; Mon, 06 Jul 2015 20:38:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=4+sM+XqB7DGCGoiHK2MerEJ3lTSqKEX7H4V16K0Nbm0=; b=j7LY6kn8xz2EdUKfDjw5Wif7vANeM2CwSWmlZoBwLS3FzUMTgK502qB7hHiU+WJz/W tuTJRCH6dKT5D8ueQc1eroI3kb8Zt5pfGWG42jqKIdLjbeiGGSO79eKyMqDzw2Twiuhz O6WCRnC3fS+f0S1BXYnaFAjhT1BzC/ObHQCxFYh8UsCNK3lBSWVOKxWr3V3WTLCDt0NR NNxBQZ7eld4dI54zYve7g3fIVjvt+JWwHefEizO0Yrl83wUk4NA2jSvvE3qBU+iC3SRi AsnIxQuyH3IeOoX4kYSZfzusvsEANfDzgscHWHWv7IVbzxsbnSc7AOtMsEhuPIQw4RXM N4TQ== X-Gm-Message-State: ALoCoQk069R9OzymfUCq8bi4QN8FY40Tx2Z3LLAhzV0kJLWCsCzdFtPsU0hNficiWEYUcUEOOvQR X-Received: by 10.66.139.168 with SMTP id qz8mr4156799pab.135.1436240292135; Mon, 06 Jul 2015 20:38:12 -0700 (PDT) Received: from [10.16.129.101] (napt.igel.co.jp. [219.106.231.132]) by mx.google.com with ESMTPSA id j3sm16952118pdf.76.2015.07.06.20.38.09 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Jul 2015 20:38:11 -0700 (PDT) Message-ID: <559B49A0.1060904@igel.co.jp> Date: Tue, 07 Jul 2015 12:38:08 +0900 From: Tetsuya Mukawa User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "dev@dpdk.org" References: <1435311160-8679-1-git-send-email-bernard.iremonger@intel.com> <533710CFB86FA344BFBF2D6802E60286046A625A@SHSMSX101.ccr.corp.intel.com> <8CEF83825BEC744B83065625E567D7C204A42C88@IRSMSX108.ger.corp.intel.com> <533710CFB86FA344BFBF2D6802E60286046A6ED8@SHSMSX101.ccr.corp.intel.com> <8CEF83825BEC744B83065625E567D7C204A42F5F@IRSMSX108.ger.corp.intel.com> <533710CFB86FA344BFBF2D6802E60286046A75A4@SHSMSX101.ccr.corp.intel.com> <533710CFB86FA344BFBF2D6802E60286046AE60D@SHSMSX101.ccr.corp.intel.com> In-Reply-To: <533710CFB86FA344BFBF2D6802E60286046AE60D@SHSMSX101.ccr.corp.intel.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v2] librte_ether: release memory in uninit function. X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2015 03:38:13 -0000 On 2015/07/06 20:35, Qiu, Michael wrote: > Hi, all > > As we has gap on the memory release action to be done in which step, I > appreciate all your comments on this patch. > > Currently, the correct quit sequence for testpmd is stop() ---> > port_stop() --> port_close() --> quit(). This will lead lots of memory > not released by default, like queues. > > We have 3 potential proposals(normal case means without hotplug): > > 1. Those memory release in close() other left in uninit() > This will work fine for both hotplug case and normal case. +1 I assume that once close() is called, we cannot start the port again without hotplugging. This is my premise. It might be good that we move finalization code to close() as much as possible, because of followings. 1. Anyway, once close() is called, we cannot start the port again. So it should be ok to free resources in close(). 2. Non-hotplugging applications can release resources if we implement finalization code to close(). Also I guess Stephen's suggestion is important to keep code clean. It may be good that 'dev->data->rx/tx_queues[queue_id]' are freed in rx/tx_queue_release() of each PMD, and rx/tx_queue_release() will be called by rte_eth_dev_close(). Also 'dev->data->rx/tx_queues[]' should be freed in ethdev.c. > 3. Combine close() and uninit(), only one will be left. > This will work fine for both hotplug case and normal case. But it > may change a lot, such as logic. I guess this will be second option. But I agree we need to change a lot. Also after enabling hotplug by default, when someone only wants to close the port, it will be impossible. Regards, Tetsuya