From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id A9D50A0471 for ; Fri, 21 Jun 2019 12:16:06 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 211831D5B8; Fri, 21 Jun 2019 12:16:06 +0200 (CEST) Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [67.231.154.164]) by dpdk.org (Postfix) with ESMTP id AF26D1D5B5; Fri, 21 Jun 2019 12:16:04 +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-us2.ppe-hosted.com (PPE Hosted ESMTP Server) with ESMTPS id 4FD81340072; Fri, 21 Jun 2019 10:16:02 +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, 21 Jun 2019 11:15:55 +0100 To: David Marchand CC: dev , dpdk stable , Thomas Monjalon , Ferruh Yigit References: <1561110041-1795-1-git-send-email-arybchenko@solarflare.com> From: Andrew Rybchenko Message-ID: <4e335594-04ee-100c-c5ee-d07ceeca56ae@solarflare.com> Date: Fri, 21 Jun 2019 13:15:52 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.1 MIME-Version: 1.0 In-Reply-To: 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-24700.000 X-TM-AS-Result: No-9.948300-8.000000-10 X-TMASE-MatchedRID: 9d2LtCNB3NJ2LasmHuCXMfZvT2zYoYOwC/ExpXrHizzI13IEGi/Kk1ym Rv3NQjsEc7HQMVzrcjKKxd7ZmcvXo48iv1am7RhcGi6hW8XaLRlp4xorO9dSmR3RY4pGTCyHY7b tfej9JsJGO66u731D0o9CL1e45ag47ZpdgJkP1WIzvWHRIxWXwnqLr3o+NE+IK8VLPDcP9n5VBT xVtaxF+Ihm3gB+YH4RGcRwLfmoPZijTL7a/i7QWuIfK/Jd5eHmamKrgqy61cLfc2Xd6VJ+ykToj XJjM1qltFAtncATmUs0Lv+3/90GP0ybjZJytb9Ih6XwUno6mkl8yGO3dvk8/VcbfIj2Ta9sP84r 9LuHKWGNKIBh68PaAWuRi/mMYtyx6BQEtCkk8tIvj6wHfIGxySPx0viUmdeulpjjxODlFo4GDGW JuDpKM84ffyU1s6hM5VhZc7vwBAMHot1G7FlH2+QYBHVKqgDUXkzKqhs+h7SbKItl61J/ycnjLT A/UDoASlnU38LCY8tWRVlrjsKO8MZW5ai5WKlyxFKYJ6T3/jN2tk+l/zw184O9AW+UJK09qHtZg vggzYGIeWujaX10XqmCyMmlRmS7tsnkl+BFkEuMyNerHU+BJtmch3NMW+V8Vlxr1FJij9s= X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--9.948300-8.000000 X-TMASE-Version: SMEX-12.5.0.1300-8.5.1010-24700.000 X-MDID: 1561112163-lxxYZQZArDG0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] [dpdk-stable] [PATCH 1/3] ethdev: avoid error on PCI unplug of already closed ethdev 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 6/21/19 12:52 PM, David Marchand wrote: > On Fri, Jun 21, 2019 at 11:41 AM Andrew Rybchenko > wrote: >> If PCI Ethernet device driver removes it on close >> (RTE_ETH_DEV_CLOSE_REMOVE) and later PCI device itself is unplugged, >> it should not fail because of Ethernet device is already removed. >> >> Fixes: 23ea57a2a0ce ("ethdev: complete closing of port") >> Cc: stable@dpdk.org >> >> Signed-off-by: Andrew Rybchenko >> Reviewed-by: Ivan Malov >> --- >> Cc: Thomas Monjalon >> Cc: Ferruh Yigit >> >> lib/librte_ethdev/rte_ethdev_pci.h | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/lib/librte_ethdev/rte_ethdev_pci.h >> b/lib/librte_ethdev/rte_ethdev_pci.h >> index 23257e986..ccdbb46ec 100644 >> --- a/lib/librte_ethdev/rte_ethdev_pci.h >> +++ b/lib/librte_ethdev/rte_ethdev_pci.h >> @@ -184,7 +184,7 @@ rte_eth_dev_pci_generic_remove(struct rte_pci_device >> *pci_dev, >> >> eth_dev = rte_eth_dev_allocated(pci_dev->device.name); >> if (!eth_dev) >> - return -ENODEV; >> + return 0; >> >> if (dev_uninit) { >> ret = dev_uninit(eth_dev); >> -- >> 2.17.1 >> > We are changing the behavior for all drivers, while I understand this > should apply to the ones that have the RTE_ETH_DEV_CLOSE_REMOVE flag. > Btw, I had reported this earlier [1], care to add a little Reported-by for > me ? :-) Yes, I agree. Unfortunately there is no ethdev here to check RTE_ETH_DEV_CLOSE_REMOVE. It could be PCI driver flag for the feature, but I'm not sure if it makes sense to add one more flag for transition. > 1: http://mails.dpdk.org/archives/dev/2019-June/134150.html