From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [148.163.129.52]) by dpdk.org (Postfix) with ESMTP id 581851B4EA for ; Fri, 19 Oct 2018 12:13:54 +0200 (CEST) X-Virus-Scanned: Proofpoint Essentials engine Received: from webmail.solarflare.com (uk.solarflare.com [193.34.186.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mx1-us3.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTPS id 89F2C600056; Fri, 19 Oct 2018 10:13:52 +0000 (UTC) Received: from [192.168.38.17] (91.220.146.112) by ukex01.SolarFlarecom.com (10.17.10.4) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 19 Oct 2018 11:13:46 +0100 To: Thomas Monjalon , CC: , , , References: <20180907233929.21950-1-thomas@monjalon.net> <20181019020757.27698-1-thomas@monjalon.net> <20181019020757.27698-7-thomas@monjalon.net> From: Andrew Rybchenko Message-ID: Date: Fri, 19 Oct 2018 13:13:06 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <20181019020757.27698-7-thomas@monjalon.net> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB X-Originating-IP: [91.220.146.112] X-ClientProxiedBy: ocex03.SolarFlarecom.com (10.20.40.36) To ukex01.SolarFlarecom.com (10.17.10.4) X-TM-AS-Product-Ver: SMEX-12.5.0.1300-8.5.1010-24164.003 X-TM-AS-Result: No-9.489400-8.000000-10 X-TMASE-MatchedRID: QfHZjzml1E8OwH4pD14DsPHkpkyUphL9wuIWIvQEbW6vPoND+wakFlPK Q4g0ENBTz0kHebusWqG/OcTZGXKzdinPugGsN3p5bc297PAGtWbhKQh1LCmGBgQDWSkWo+x8MFd dv+pLbrcojlDYdAoPBa4kW4+WV/vKFohKFQUjhh1VTfJWlqPdDEDwlkRNC6PC2+mPn502VC+hDy 0IIm8xIvXan0PHJ+OKeM0YmPWGC84MiTNbd7AZSUNTnAhL0/m3ZpZpZFu3mKCbKItl61J/ycnjL TA/UDoAoTCA5Efyn8DyABN92SNtPN0H8LFZNFG7bkV4e2xSge6CURfSAXfohvmIB7i30mCsAWbZ owyleR899tLsKd3pajZFEgw6u+Np X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--9.489400-8.000000 X-TMASE-Version: SMEX-12.5.0.1300-8.5.1010-24164.003 X-MDID: 1539944033-sebjJAMS7Ztd Subject: Re: [dpdk-dev] [PATCH v6 6/6] 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: Fri, 19 Oct 2018 10:13:54 -0000 On 10/19/18 5:07 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 which were done by rte_eth_dev_detach(), > are now done at the end of rte_eth_dev_close() if the driver supports > the flag RTE_ETH_DEV_CLOSE_REMOVE. > There will be a transition period for PMDs to enable this new flag > and migrate to the new behaviour. > When enabling RTE_ETH_DEV_CLOSE_REMOVE, the PMD must free all its > private resources for the port, in its dev_close function. > It is advised to call the dev_close function in the remove function > in order to support removing a device without closing its ports. > > Some drivers does not allocate MAC addresses dynamically or separately. > In those cases, the pointer is set to NULL, in order to avoid wrongly > freeing them in rte_eth_dev_release_port(). > > A closed port will have the state RTE_ETH_DEV_UNUSED which is > considered as invalid by rte_eth_dev_is_valid_port(). > So validity is not checked anymore for closed ports in testpmd. > > Signed-off-by: Thomas Monjalon Reviewed-by: Andrew Rybchenko I really like the idea with RTE_ETH_DEV_CLOSE_REMOVE. As I understand it should applied to dpdk-next-net, but right now there are conflicts in net/tap (patch 4).