From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by dpdk.org (Postfix) with ESMTP id 6BDAF1B202 for ; Wed, 10 Oct 2018 09:44:49 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 1214021BD8; Wed, 10 Oct 2018 03:44:49 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Wed, 10 Oct 2018 03:44:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=mesmtp; bh=uadpQRFXmx73mIeQN8QFhQdDBsTCB/+a/zDqQ7KakvE=; b=eWYvg6AduC57 zaISzoDwrSit8k3tj9xy3JE9pFef0z8bY6pJoDVzhkd//jZEpCIHQCenW8OC1sHj B+8kkM187rDOd1zODufv2upRG36GYQBva/884xj+Ft5eA4zdDwqLY4okdTT5bL/7 +mB1UL8EimUhATC0g1UdrUxQi6HNKfo= 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-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=uadpQRFXmx73mIeQN8QFhQdDBsTCB/+a/zDqQ7Kak vE=; b=dp9hsR2wgu7js/m/r9ei25+qjM7JiNBRBBVYSgA9LIHsRINf/TzdmfRGq yrdi8gyY9L/wI8XTZNzLsUE1NTwxNzKZQfxZfmFrGNBI38FV+qYUOi1rr2StIYU+ sThmVyMqmF/TsSujEKyt73Y6YvZL94S16pumeRp8GOKqCZbEF2vwhmy9HdchOI0A +pH1vChCtHhxCpNqgqjSLeUZDEbjK7CmYBROnoSU9+YNdpvyisS8CoURhwqgixZ0 sYQjRkC/6qgR1b7j1w0mRXScLQsA3tqAOAQTXLVTH1ABToADR/47e3Ri+/juZdoE 7kffqaHNQyg6S+kcXnO/QKADoHzUw== X-ME-Sender: X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id C278DE4074; Wed, 10 Oct 2018 03:44:47 -0400 (EDT) From: Thomas Monjalon To: Andrew Rybchenko Cc: ferruh.yigit@intel.com, dev@dpdk.org, ophirmu@mellanox.com Date: Wed, 10 Oct 2018 09:44:46 +0200 Message-ID: <7172106.4TAESsr7Yr@xps> In-Reply-To: References: <20180907233929.21950-1-thomas@monjalon.net> <20181009221732.17377-1-thomas@monjalon.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v2] ethdev: complete closing of port 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: Wed, 10 Oct 2018 07:44:49 -0000 10/10/2018 08:15, Andrew Rybchenko: > On 10/10/18 1:17 AM, Thomas Monjalon wrote: > > After closing a port, it cannot be restarted. > > So there is no reason to not free all associated resources. > > > > The last step was done with rte_eth_dev_detach() which is deprecated. > > Instead of blindly removing the associated rte_device, the driver should > > check if no more port (ethdev, cryptodev, etc) is open for the device. > > > > The last ethdev freeing (dev_private and final release), which were done > > by rte_eth_dev_detach(), are now done at the end of rte_eth_dev_close(). > > > > If the driver is trying to free the port again, the function > > rte_eth_dev_release_port() will abort with -ENODEV error. > > > > Signed-off-by: Thomas Monjalon > > --- > > lib/librte_ethdev/rte_ethdev.c | 6 ++++++ > > lib/librte_ethdev/rte_ethdev.h | 3 +-- > > 2 files changed, 7 insertions(+), 2 deletions(-) > > > > diff --git a/lib/librte_ethdev/rte_ethdev.c b/lib/librte_ethdev/rte_ethdev.c > > index ed83e5954..3062dc711 100644 > > --- a/lib/librte_ethdev/rte_ethdev.c > > +++ b/lib/librte_ethdev/rte_ethdev.c > > @@ -506,6 +506,8 @@ rte_eth_dev_release_port(struct rte_eth_dev *eth_dev) > > { > > if (eth_dev == NULL) > > return -EINVAL; > > + if (eth_dev->state == RTE_ETH_DEV_UNUSED) > > + return -ENODEV; > > > > rte_eth_dev_shared_data_prepare(); > > > > @@ -1441,6 +1443,10 @@ rte_eth_dev_close(uint16_t port_id) > > dev->data->nb_tx_queues = 0; > > rte_free(dev->data->tx_queues); > > dev->data->tx_queues = NULL; > > + > > + rte_free(dev->data->dev_private); > > It is used by, for example, PCI device uninit functions. > What does guarantee that uninit is done and we can free the private data. The state of the port is set to UNUSED and the name is NULL. So nobody should try to use it anymore. There are already some checks before calling uninit functions. For instance, in rte_eth_dev_pci_generic_remove(), rte_eth_dev_allocated() will return NULL and won't call uninit function.