From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) by dpdk.org (Postfix) with ESMTP id 0AFE15A5E for ; Wed, 8 Jul 2015 12:01:03 +0200 (CEST) Received: by wifm2 with SMTP id m2so84249669wif.1 for ; Wed, 08 Jul 2015 03:01:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:organization :user-agent:in-reply-to:references:mime-version :content-transfer-encoding:content-type; bh=Q7IJnVXTEgH8yFLx4R4hH/M7luD8OkmtK0fqdwkSDGo=; b=L697IdwBThgG4lB8WXXzbwB0LxHALNjbXfChanYVeGQ9gK3lKtcwnv/RfFMJKo3s82 TDP/El5+nhDyT8ntf/NZG+mXtKDFhTfgi1je16AtGMX5EwkrZzOHL/hvzH/FxaOUv639 LiFQ1is38riDADmsmsusJOHezXYS2FyNNEBXu9DWpi87NB080zo3rU1X7qvA2CfqVYQF 8z9FEKBIev/JN9KouePF9k+dhistx2FS2RlR+AE6xOdn4PkusIBNyVhvkYk1n47v/dZx jx2aUv2NABYJAoxbDyxn8rl2fLSrQCB0tvkdHjAvrsPcGvaCGmy9wDvLv5bVxGLVuNLD BWaw== X-Gm-Message-State: ALoCoQlgZqb1AAgC9cHVKWTYLp32AzsXIqP3hzuiFKX62F+/gvsl3c4lUK8ltlGfb5uQUf0w+Dxy X-Received: by 10.180.188.48 with SMTP id fx16mr72710269wic.35.1436349662860; Wed, 08 Jul 2015 03:01:02 -0700 (PDT) Received: from xps13.localnet (136-92-190-109.dsl.ovh.fr. [109.190.92.136]) by smtp.gmail.com with ESMTPSA id m10sm2023758wib.17.2015.07.08.03.01.01 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Jul 2015 03:01:01 -0700 (PDT) From: Thomas Monjalon To: "Iremonger, Bernard" , Tetsuya Mukawa Date: Wed, 08 Jul 2015 11:59:52 +0200 Message-ID: <3983969.nNQCjP6QHn@xps13> Organization: 6WIND User-Agent: KMail/4.14.8 (Linux/4.0.4-2-ARCH; KDE/4.14.8; x86_64; ; ) In-Reply-To: <8CEF83825BEC744B83065625E567D7C204A46F17@IRSMSX108.ger.corp.intel.com> References: <8CEF83825BEC744B83065625E567D7C204A46F17@IRSMSX108.ger.corp.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Cc: dev@dpdk.org 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 10:01:03 -0000 2015-07-08 09:49, Iremonger, Bernard: > From: Tetsuya Mukawa [mailto:mukawa@igel.co.jp] > > On 2015/07/07 19:53, Iremonger, Bernard wrote: > > > From: Tetsuya Mukawa [mailto:mukawa@igel.co.jp] > > >> 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, > > Hi Tetsuya, > Testpmd enforces the dev_stop(), dev_close() and dev_detach() sequence. > There is no reason why an application cannot call dev_detach() directly. > > During internal review of PMD dev_uninit() functions it was decided to ensure that this sequence was adhered to by calling dev_close() which calls dev_stop() from the dev_uninit() function. > In the PMD hotplug patches the following calling sequence is implemented: > dev_uninit() calls dev_close() calls dev_stop(). > At present most of the finalization code is implemented in dev_close() and dev_stop(). > The dev_uninit() functions implement what is left of the finalization code. It appears that the API is not defined. None of these assumptions is written in rte_ethdev.h. Please continue the discussion by submitting a patch fixing the doxygen comments of these functions. How an application developper is supposed to use these functions without having a clear explanation of their roles in doxygen?