From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pd0-f180.google.com (mail-pd0-f180.google.com [209.85.192.180]) by dpdk.org (Postfix) with ESMTP id 265772A5E for ; Thu, 9 Jul 2015 05:32:15 +0200 (CEST) Received: by pddu5 with SMTP id u5so69518687pdd.3 for ; Wed, 08 Jul 2015 20:32:14 -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=LSKJyCyrgHoQvdb3Fq6kibWUfAFDHWTiuUItCm8DbZw=; b=FiBxMqitUHwRfVxBMyitbIk9ubxxTYbfqpePss/wIQrvZMA2X+huhVlkLSnVtbvi/c A+sFNQ1p//4nO1jiTuWcdROd/Mj+h68FaZ7vcsmSDLcPfO6AhfWAiFAeTqM37e9c6gFB een/v0y+zPRzd7UF7cqIo8myx5TCR+hafSApXgTw/JG3sZHMDWJTSOgZ2+FOYPUb16/Z Sym0Ikrwbva/ZqB+x0utgnS7MJa1RWQDODvEdUb3ETYUoa6VDuNsUI58dBWunBcVIbDC 3VaWZZBWeoDSYKTGbqCu1V+xI6ruV+ySbUA9ymp7Zpd3ZSkBu/OAs8Svg0FMEH9XQLRr LWqw== X-Gm-Message-State: ALoCoQnnICZduLeCwvEOg5pOvuzZaUzFPsThIVrBM5GA1fx4ybwbtDUIU4DAWBlwbFhiUYl5xtz3 X-Received: by 10.68.204.133 with SMTP id ky5mr26772662pbc.67.1436412734410; Wed, 08 Jul 2015 20:32:14 -0700 (PDT) Received: from [10.16.129.101] (napt.igel.co.jp. [219.106.231.132]) by smtp.googlemail.com with ESMTPSA id ug1sm4056058pbc.39.2015.07.08.20.32.11 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Jul 2015 20:32:13 -0700 (PDT) Message-ID: <559DEB39.5080808@igel.co.jp> Date: Thu, 09 Jul 2015 12:32:09 +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: Thomas Monjalon , "Iremonger, Bernard" , "Qiu, Michael" References: <8CEF83825BEC744B83065625E567D7C204A46F17@IRSMSX108.ger.corp.intel.com> <3983969.nNQCjP6QHn@xps13> In-Reply-To: <3983969.nNQCjP6QHn@xps13> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit 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: Thu, 09 Jul 2015 03:32:15 -0000 On 2015/07/08 18:59, Thomas Monjalon wrote: > 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? Yes, this assumption is only written in DPDK user's guide. So we should add description to doxygen. I will take care of it. Anyway, I will add description to doxygen like user's guide. (A) stop() and close() must be called before detach(). (B) close() releases all most all resources. Probably Bernard and Michael patches are fit for above restrictions. It may be good to add below in DPDK-2.2, though supporting below feature will be more user friendly. (C) Even if stop() and close() are not called, detach() will take care of it. Probably, it's not so much time left before releasing DPDK-2.1. So how about keeping current restriction written in user's guide, then add a new feature in DPDK-2.2. Regards, Tetsuya