From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <thomas@monjalon.net>
Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com
 [66.111.4.27]) by dpdk.org (Postfix) with ESMTP id 29CB91B513
 for <dev@dpdk.org>; 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: <xms:jiW9W-f5dXFkMY7o472LT2iA3gfTaSvAsyhtr19Hk20mPIbD9jfyIA>
X-ME-Proxy: <xmx:jiW9W90cvKePn3Jqd1FDoVIaWa48oohwfv-V7Ez54ezfaY5BdCTAnw>
 <xmx:jiW9W0OR2u4RWGS31RsM4dLgG9aLpCuS5GaJt1qNitiyr2eGlh5ysA>
 <xmx:jiW9W-IY-WFxxyTtlaeSdJbfxGM3U0COv9p2HeoDlr79KA4GlBq0aw>
 <xmx:jiW9W-47JPPqo_r9wtDTNtpgDC4b2l3Y6PzmECvoB1RJcCzImVr_XQ>
 <xmx:jiW9Ww6OIqnQkR-LNRJPs5z4msjDk7n41Dnk7lm1YMOO4at-WRXriQ>
 <xmx:jiW9WywO2q6yKe7OJR2qvTpCbS6TSzpSdC8UZwir0mraXw1ISLAyGQ>
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 <thomas@monjalon.net>
To: Ferruh Yigit <ferruh.yigit@intel.com>
Cc: dev@dpdk.org, arybchenko@solarflare.com
Date: Wed, 10 Oct 2018 00:00:07 +0200
Message-ID: <2115860.EbHCjSuZbr@xps>
In-Reply-To: <e6cc3b3a-bae7-3946-534a-78603bd488cb@intel.com>
References: <20180907233929.21950-1-thomas@monjalon.net>
 <e6cc3b3a-bae7-3946-534a-78603bd488cb@intel.com>
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 <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=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 <thomas@monjalon.net>
> > ---
> > 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.