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 29CB91B513 for ; Wed, 10 Oct 2018 00:02:55 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 99DAC21FE9; Tue, 9 Oct 2018 18:02:54 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Tue, 09 Oct 2018 18:02:54 -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=InWNHA3s0Uo6J+0Zj7Jg6Cu4uBUe3thowZa0iMyKurM=; b=jhNk5/guKSaL fojay2kJIlbWH/PB4yjaJe4RqUj4H2wL84lqZGwkjeLZOiz00Ei7/g8Yx/5/EmZj nAvkpDDANmH+hzD24+3r1a0Jq8F2ffCQjRERyeufATtpQcE2ZPaF9DovtZJVtOxZ 8UlSDIMCfWc+PaVvrtYqoGq9Z8ZGpBU= 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=InWNHA3s0Uo6J+0Zj7Jg6Cu4uBUe3thowZa0iMyKu rM=; b=utDvSjagaJq+1b71pu+cs039SS38idmZ3JyEkvfB5zBFBfVHGV9AUGFrJ eQ7mfM9ni37MfGOQS7YNVb00VVHQlPjX82mJamcJayvIFFQydq3CjmPWBUNgf/ke BOUNavJ6UiGy+UoVr65+0uZ6qgslEpmWgP1apqtmUu9Z8si46IKxwIGE3IU8WF+A j5G/rrarDhRXPgsrBDLDjX45LwwqvS5VxBU8iw4q9gTd39rWcT7ire9Yo8IjI78E aYMLFg06OofG8W8X8HuacZg6toKDG7Eu39HN3bdSLEbgzGNFC7pAgnf6g6ZsAqcE vmjUjO7KcTOgrdUussk/hMS753Cyg== 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 9426CE5190; Tue, 9 Oct 2018 18:00:09 -0400 (EDT) From: Thomas Monjalon To: Ferruh Yigit Cc: dev@dpdk.org, arybchenko@solarflare.com Date: Wed, 10 Oct 2018 00:00:07 +0200 Message-ID: <2115860.EbHCjSuZbr@xps> In-Reply-To: References: <20180907233929.21950-1-thomas@monjalon.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [RFC] ethdev: complete closing to free all resources 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: Tue, 09 Oct 2018 22:02:55 -0000 28/09/2018 14:46, Ferruh Yigit: > On 9/8/2018 12:39 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 removing the associated rte_device, the driver should check > > if no more port (ethdev, cryptodev, etc) is still open for the device. > > Then the device resources can be freed by the driver inside the > > dev_close() driver callback operation. > > > > 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(). > > > > Signed-off-by: Thomas Monjalon > > --- > > This patch contains only the change in the close function as RFC. > > > > This idea was presented at Dublin during the "hotplug talk". > > --- > > @@ -1372,6 +1373,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); > > + > > + rte_eth_dev_release_port(dev); > > These already done in: > rte_eth_dev_pci_generic_remove() > rte_eth_dev_pci_release() > > Perhaps all content of rte_eth_dev_pci_release(), including above updates, > should move to rte_eth_dev_close() and rte_eth_dev_pci_generic_remove() call > rte_eth_dev_close() directly. Yes I think it is the way to go: - when removing a rte_device, close all associated ports. and the reverse can be done in addition: - when closing the last port of a rte_device, remove it. > Just thinking aloud, > > driver->probe() called when a new device added. > Application startup can be thought as all devices added one by one. [Perhaps > this can be change in the future to add devices only when explicitly stated] > > driver->remove() called when device removed. > When application terminated this path not called at all, perhaps we need a way > to remove all devices one by one on exit. > > eth_dev_close(), when eth_dev removed in ethdev layer but device is not removed > in eal level, > > I think it make sense for eth_dev_close(): > - It does more cleanup, free resources and port_id > - but it may need to do more clean up, like call uninit() and do more driver > internal clean up too, and clean up the hw. > - so call stack can be: > driver->remove() > rte_eth_dev_pci_generic_remove() > eth_dev_close() > dev_uninit() [driver unint function ] > > > Another question, after eth_dev_close() ethdev is not usable and not able to > restart it back. So why we need eth_dev_close() in addition to dev remove, why > not directly call rte_eth_dev_detach()? rte_eth_dev_detach is assuming a 1:1 mapping between EAL rte_device and rte_eth_dev port. That's why it is deprecated and going to be removed.