From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-f43.google.com (mail-pa0-f43.google.com [209.85.220.43]) by dpdk.org (Postfix) with ESMTP id B3196234 for ; Wed, 8 Jul 2015 05:47:39 +0200 (CEST) Received: by pabvl15 with SMTP id vl15so123864694pab.1 for ; Tue, 07 Jul 2015 20:47:39 -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=f6NAwQlgtgnP/jqQ/kMDaWH2+zOepJaamztSbGGgQEQ=; b=IV1ogvfJkHVyhBaebUBKSp/N0vy75wQJZL2tDXS4OrmtLj8LCyNRPAmNclnmL+5Evp 6fBeYN7CSMHy47OTixgK86n3/i0ihHq8QfM1NjY482rP8CIU09bUaysRm21quBhwgrkh fb4rQp1YbKyYnNhk5c5XwEA2AqVyNEvkGVYuOwSqPdLfJzDG7XGgoOcDLfPENf9mRC3O pWQne/xUOypA3qESxHqAe5lSsTCFzVjz4xT/dHooKPehs52eyvgoGI9UHV4kuQ3psJgF 7GVMrnnEk7rcTjPRiYsNaJSAeAdPugqTCYGi0lAg/t7Cre28HRORtHUNJ085gtoxkezm 7/SA== X-Gm-Message-State: ALoCoQnerbrPrPDKml51TPj3AlQSkE/TWNn6LhFZtxyIHkXUf3Lp/NPFr1o/vVaNyrnUE0kzZ3vv X-Received: by 10.68.180.131 with SMTP id do3mr15733016pbc.42.1436327258959; Tue, 07 Jul 2015 20:47:38 -0700 (PDT) Received: from [10.16.129.101] (napt.igel.co.jp. [219.106.231.132]) by smtp.googlemail.com with ESMTPSA id jd4sm656996pbd.46.2015.07.07.20.47.35 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Jul 2015 20:47:38 -0700 (PDT) Message-ID: <559C9D55.6000109@igel.co.jp> Date: Wed, 08 Jul 2015 12:47:33 +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: "Iremonger, Bernard" , "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> <559B49A0.1060904@igel.co.jp> <8CEF83825BEC744B83065625E567D7C204A467FF@IRSMSX108.ger.corp.intel.com> In-Reply-To: <8CEF83825BEC744B83065625E567D7C204A467FF@IRSMSX108.ger.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: Wed, 08 Jul 2015 03:47:40 -0000 On 2015/07/07 19:53, Iremonger, Bernard wrote: >> -----Original Message----- >> From: Tetsuya Mukawa [mailto:mukawa@igel.co.jp] >> Sent: Tuesday, July 7, 2015 4:38 AM >> To: dev@dpdk.org >> Cc: Qiu, Michael; Iremonger, Bernard; thomas.monjalon@6wind.com; >> Ananyev, Konstantin; Stephen Hemminger; Zhang, Helin; Chen, Jing D; Neil >> Horman >> Subject: Re: [dpdk-dev] [PATCH v2] librte_ether: release memory in uninit >> function. >> >> 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. > There is also the scenario (outside of testpmd) where an application can call rte_eth_dev_close() or rte_eth_dev_detach() which calls rte_eth_dev_uninit() directly from an application. > In these cases the memory allocated in the EAL layer should be released in both rte_eth_dev_close() and rte_eth_dev_detach(). Hi Bernard, All DPDK applications that uses hotpluggingmust call rte_eth_dev_stop() and rte_eth_dev_close()APIs before detaching ports. (This is described in DPDK documentation) Could we ignore applications that only calls rte_eth_dev_detach()? > This patch is intended to address the rte_eth_dev_detach() case only (hotplug case). > Perhaps there should be a separate patch to address the rte_eth_dev_close() case. We all needs to have consensus about how to implement finalization code in close() and uninit(). Probably one of options will be implementing finalization code in close() as much as possible. Tetsuya, > Regards, > > Bernard. > >>> 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