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 73CD0239; Mon, 21 May 2018 12:54:58 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id DDED8220DF; Mon, 21 May 2018 06:54:57 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Mon, 21 May 2018 06:54:57 -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=wLTm+I5AeOXGds8YYb0veJ0EWZ vdCBHejjH9Uw+0Yho=; b=UmB8vWHPfvQaEyvXarL41Dwo6EcX1al+fgHkg1xu1S 1jWnZF+DelF6b4755LGIzIX9bD6aOZbx+UHbVlTPaG66QUPW5XwY9l/GDr2kikt6 a0eyCgqi0WUah4WFQTfQAugTFz5W6mwEHTzqLhG48MbSF/vozJc1fXfNIBgmv7AQ g= 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=wLTm+I 5AeOXGds8YYb0veJ0EWZvdCBHejjH9Uw+0Yho=; b=GBt8OXmMfE7Fj6CUMjRwpp irrGbhBCaEzqdhHHzSlLpfMdNg6c8nOxe9PD8E13TI72b7gsikX6mbMSsmqpmxiW dUyatAbKIEyh9HK0ioAZx9Cfb9/yFYtPJhdrH9spZd8QWqeFJMIlYcKzk4G4B1JA UUnelyLGYWBtIXZ95bMkUpTZfFysrlCfj5JsbLKxmqy1fOrx6xsI8DYl+59a9DFD xxapkixEAjLw11n2vH5IBvWXN4p/m63mLzvfJe4aFTFL9NqKs8ZPWmoXUXD1OGEP vcYwSMME8yOopQCBB8Ov/rqqxQzepl9ZVjXEU14/hbvBVijM8P+s0tFbFYYjYCdw == 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 (236.204.154.77.rev.sfr.net [77.154.204.236]) by mail.messagingengine.com (Postfix) with ESMTPA id A324F1025C; Mon, 21 May 2018 06:54:54 -0400 (EDT) From: Thomas Monjalon To: Ferruh Yigit , "Yang, Zhiyong" Cc: dev@dpdk.org, Matan Azrad , "Iremonger, Bernard" , "Yao, Lei A" , "maxime.coquelin@redhat.com" , "Bie, Tiwei" , "stable@dpdk.org" , Harry Van Haaren Date: Mon, 21 May 2018 12:54:51 +0200 Message-ID: <4367922.LPtKO2KjJs@xps> In-Reply-To: <2140651.lW3kzKMLfn@xps> References: <20180518095937.28710-1-zhiyong.yang@intel.com> <2140651.lW3kzKMLfn@xps> 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 10:54:58 -0000 19/05/2018 16:19, Thomas Monjalon: > 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(). This patch is relying on rte_eth_dev_detach() to remove the EAL device. It should be done in rte_eal_cleanup(). I am concerned that this patch is workarounding a miss in rte_eal_cleanup, and takes a different action only for vdev. It is a bad example. And the function rte_eth_dev_detach() is fundamentally wrong and should be deprecated: http://dpdk.org/commit/b05b444d22 http://dpdk.org/commit/b0fb266855 http://dpdk.org/commit/df3e8ad73f One more concern: it seems this patch is breaking failsafe use case. Note: bonding is managed as an exception in rte_eth_dev_detach().