From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by dpdk.org (Postfix) with ESMTP id 845AB1B213; Mon, 21 May 2018 21:12:15 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 197F92211D; Mon, 21 May 2018 15:12:15 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Mon, 21 May 2018 15:12:15 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=mesmtp; bh=KHD44MSx85BY5PI8YUlWppSkz3 oVxWWDF7j2ZYUu1ZU=; b=Q1z0Ofz2OBoSG3EWocrm79VVwXjHVb9v8zmpPp7mg5 itV9/XitNVXMqWF6f8sJfGM0xJGUWe5DHE9cVXhqnSN4bVNdY3BuaBIIWAaVNQ2I sj4gL78VlcA0sNH3+JcQ6Ne/LSmKzfrrfuIoUlEDr6yvLOlWfMwoA0EKRhTPxERO w= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=KHD44M Sx85BY5PI8YUlWppSkz3oVxWWDF7j2ZYUu1ZU=; b=fNfsNCa+eP2VLycRFrCH8v jvRZ6G01dm3Cm4M9a4QS34kDue760DjZFQQkVzRYOc2ospQirAAZsHdg45kEuZtf kk9jkxLbTNtzKCI7FD6SVVvBEhv+D+feQnKMKg2RM6bCuJ+hb2FfZ8jf2JExj5O2 IV/uqSt9nxmcJrb/ALa2NOoY1MtIM2fIGR8VrN8d1Z0SPsUtpTXGas3okZxRkDLx txvh+9EndWuBpR7kEqJHwsKy7KXN8juxhuQECc+MeNBpI1hSg+oyiWyOQeOrVIB6 GR7zTZuZEdcdv9B+d3Tebg4zjYDH3/AmrrOIoVolZ8mlmuNA3W7xNbpmtUE5GEzw == X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Sender: Received: from xps.localnet (95.15.136.77.rev.sfr.net [77.136.15.95]) by mail.messagingengine.com (Postfix) with ESMTPA id 3C2EE10265; Mon, 21 May 2018 15:12:11 -0400 (EDT) From: Thomas Monjalon To: Ferruh Yigit Cc: Matan Azrad , "Iremonger, Bernard" , "Yao, Lei A" , "Yang, Zhiyong" , "dev@dpdk.org" , "maxime.coquelin@redhat.com" , "Bie, Tiwei" , "stable@dpdk.org" , Harry Van Haaren Date: Mon, 21 May 2018 21:12:03 +0200 Message-ID: <2537573.0mMpuaFsgd@xps> In-Reply-To: <52652a78-bda8-0b8f-d02e-c70c84650c8a@intel.com> References: <20180518095937.28710-1-zhiyong.yang@intel.com> <1553952.sZOlap8oeX@xps> <52652a78-bda8-0b8f-d02e-c70c84650c8a@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v2] app/testpmd: fix pmd_test_exit function for vdevs X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2018 19:12:15 -0000 21/05/2018 18:44, Ferruh Yigit: > On 5/21/2018 5:40 PM, Thomas Monjalon wrote: > > 21/05/2018 18:37, Ferruh Yigit: > >> On 5/19/2018 3:19 PM, Thomas Monjalon wrote: > >>> 18/05/2018 18:29, Ferruh Yigit: > >>>> On 5/18/2018 4:55 PM, Matan Azrad wrote: > >>>>> Hi all > >>>>> > >>>>> While this patch also applied I don't understand it. > >>>>> Is it mandatory for each PMD to free all its resources in dev_close()? > >>>>> Or it should be done by the rte_device remove function? > >>>>> > >>>>> If the resource cleanup should be done by the remove function I think it > >>>>> should be called for all the devices (pci, vdev, etc). > >>>>> > >>>>> Is there an exit function for EAL to clean rte_eal_init()? If no, looks like we need it... > >>>> > >>>> Hi Matan, > >>>> > >>>> I believe there is a gap in resource cleanup. > >>>> dev_close() it not for resource cleanup, it should be in PMD remove() functions, > >>>> and PMDs have it. The problem is remove path is not called in application exit. > >>>> > >>>> As far as I know there is no simple API to clean the resources, having it may > >>>> help application to do the cleanup. > >>>> > >>>> I have seen the rte_eal_cleanup() API by Harry, that can be extended to cover > >>>> PMD resource cleanup if there is enough motivation for it. > >>> > >>> Yes, EAL resources should be removed by the function rte_eal_cleanup(). > >>> And ethdev ports must be removed by rte_eth_dev_close(). > >> > >> There is probe() and remove() functions. > >> There is dev_close devops, called by rte_eth_dev_close(), but there is no open() > >> or equivalent. > >> > >> For example an ethdev allocated its private data during probe(), if > >> rte_eth_dev_close() free it, how can a new ethdev can be allocated? > > > > I don't understand the question. > > You say closing a port and opening a new one. > > So we allocate private data in the new probe. > > the question is why resources allocated in probe() but freed in close() instead > of remove()? Because close() is the opposite of probe(). The function remove() does not exist in ethdev. However it exists in EAL layer for rte_device. Reminder: one rte_device can be common to several ethdev ports, or other class of ports. > Or should we have something like rte_eth_dev_open() ? I don't think it is needed.