Message ID | 1518107653-15466-3-git-send-email-matan@mellanox.com (mailing list archive) |
---|---|
State | Superseded, archived |
Delegated to: | Ferruh Yigit |
Headers |
Return-Path: <dev-bounces@dpdk.org> X-Original-To: patchwork@dpdk.org Delivered-To: patchwork@dpdk.org Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 79B601B82B; Thu, 8 Feb 2018 17:34:35 +0100 (CET) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10049.outbound.protection.outlook.com [40.107.1.49]) by dpdk.org (Postfix) with ESMTP id 8DA0A1B821; Thu, 8 Feb 2018 17:34:33 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Mellanox.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=bbdG//G3DwDk7MO5rptLCxP7At7khO7BH0nIZ8d9D0I=; b=aJkKbG4H9ZzvIeAgdMEfVFbEiVc3b7erD6irbghK07d4K5/0YkhRZZ6T1vynJnStyd3iRwFRHz2x/JYwJKBM45+O8ogVGd6E78oURdxucU9Gk9xvbpJzS7Z5fgm5FjCMCC2HXjIjkt4GwAHwCyevV9rpSwylXIHkAIAC4N3EyTw= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=matan@mellanox.com; Received: from mellanox.com (37.142.13.130) by DB6PR0501MB2664.eurprd05.prod.outlook.com (2603:10a6:4:80::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.464.11; Thu, 8 Feb 2018 16:34:30 +0000 From: Matan Azrad <matan@mellanox.com> To: Gaetan Rivet <gaetan.rivet@6wind.com> Cc: dev@dpdk.org, stable@dpdk.org Date: Thu, 8 Feb 2018 16:34:12 +0000 Message-Id: <1518107653-15466-3-git-send-email-matan@mellanox.com> X-Mailer: git-send-email 1.8.3.1 In-Reply-To: <1518107653-15466-1-git-send-email-matan@mellanox.com> References: <1518092427-4333-1-git-send-email-matan@mellanox.com> <1518107653-15466-1-git-send-email-matan@mellanox.com> MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [37.142.13.130] X-ClientProxiedBy: HE1PR0102CA0023.eurprd01.prod.exchangelabs.com (2603:10a6:7:14::36) To DB6PR0501MB2664.eurprd05.prod.outlook.com (2603:10a6:4:80::22) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: f5970f09-c631-445d-c744-08d56f11d4c8 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4604075)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603307)(7153060)(7193020); SRVR:DB6PR0501MB2664; X-Microsoft-Exchange-Diagnostics: 1; DB6PR0501MB2664; 3:TwJ48jYKsc2FYoOkbslgaQ0TM+ZdCQI+3mmTEW7nDXh6oHzJE4IUkSD1wZYfoSEZfwM1kQXnpV9ZeUfNcOF9L5TujwkNpQRTUL1zKfkK30xvHtOrNirN6BeFWhDtlznc4PegtDI7qF3K/UEfVv8BEgiGp4gEHf+j6ZCYd05hYBovaerA1uVsdX5pSL8PkeiodmOEooGRr+8VRvZ7Bgl0onX32QDrMsvEcBXZlbD6i3koBKKkdHRABKdFiGaJidFR; 25:2nAS5rv7duyaUvMDhsyzeQlwReU+fM9uT79Bm4FV+dIElxM/4cdqT5MFfNNJ7/kFdocS7RZZDHwqcE7mVx2P1XA1bjq6tP8oHU+VqxGQPudsIxjZneFb7oKkVXNkc+4TKc80/oVdk5xufmiKRzLMjmaYFDiXTZratXll9TtTkFsoaB6jP+w/c/SaU27sWpAaUelAdInF+cvPMkN7Sk0mF28YSVPqpQpGxy8p0KCfsmCAzv5wnJOtE1Y0qA3T9zrplDsqv2d2t8cIO4yAFyDlxBwYuwgls3HttridaPeOfaINONOIV+8MFVv/G1EQAvbq+UEWbv5iz4J+HbHJbc3Rhw==; 31:kbeF4rK8eNcf+U8aBfguJM2S/vi8hw8MyHNfDK08/CtRhSEVU5OYdnHIc0oc6GK7NTQZcoawQA5AHAmPxszQ4SzvqM9do28XugvYT6xJGn1pR59rAYYyeLZ03KVNIXNl6WDzA/H6JV56VyVEVtiLs20FbDBj6ymNMJ+YSkxn8N5Gv4sQq3izzlkf1rEIVjf/C14cOFUVm/MP0leY43qykMae0PoOjPydCJ0BaLuWQjY= X-MS-TrafficTypeDiagnostic: DB6PR0501MB2664: X-Microsoft-Exchange-Diagnostics: 1; DB6PR0501MB2664; 20:cu7ayB/B6BB7SkvWgjo9exm/GnQvgDXaSeqFe6kjnvbQGDOjhdRpEpc7Aj9Tk1P4pE998ANsg1U2H03JWRXqsOkriSF8dwHqpuM+TaPqd/BrXKvVWoElpsOT8PxsW3LbNjbq1NN1jCtWCktBTWfuMZwflWBUP9e6i8cWlXluSiKDMhVSkddNgdlYhyBAh5bsBFblQLnOuu6o+0RTNdbNLTTDbzr118fRzvRBOMQYvsznqfoyF9siSFohcoWsUEa22HSDcvfWyw525CrOA+d9oUN573n2UXj2cdZxhmu537NSWPR5NGPBgptBnfbCNgD7h+9vL+bGob3NasibijpAw06JIvAZprg/yu4Jq3N75pXMOD8zYe7EWG/aCq671ZMUQnXT+ovZehoSHtn3VXe8ryUG/1ci+M1UX6O2cOwXH1qO1/ATW9AM+t8+V/OXIP9CtOQE2IQMDV38OgGaOVQR4yKI4nEUiLOrI9Qh0EHsokpcT4BPBeHp3/hSZoqQh6cG; 4:nHbkbLvd7034JyhTQzd2/WiY2sVgjf7UiT9rKMSBgZAOIcMexh+dXcBdMCFw6L3lwti0wF1USaUNQ8/ks24hpeYyn9NGdkh7aHRwWjxOavEyuJR4xzLHOCmV7bd6g5/HHvouQpCgCW+Q/r27S4ExIR5IbnfxcxXFkI+qbcWjgSS2XK7vK6sJo0J91fVLM2piFKK5SZr4yxTKYVJtqCy/EbCnrzzvd/8H2WXmmhP+A8RWb65MSCF54dnzl9XeQHIoOmUD4Dh2315mlMcCVex7nw== X-Microsoft-Antispam-PRVS: <DB6PR0501MB2664DFD4D7E743E2A707D378D2F30@DB6PR0501MB2664.eurprd05.prod.outlook.com> X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(3231101)(2400082)(944501161)(3002001)(10201501046)(93006095)(93001095)(6055026)(6041288)(20161123564045)(20161123560045)(20161123562045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:DB6PR0501MB2664; BCL:0; PCL:0; RULEID:; SRVR:DB6PR0501MB2664; X-Forefront-PRVS: 0577AD41D6 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(366004)(396003)(39380400002)(376002)(346002)(39860400002)(189003)(199004)(316002)(6916009)(2950100002)(105586002)(3846002)(6116002)(4720700003)(6666003)(478600001)(25786009)(47776003)(5660300001)(2906002)(106356001)(16526019)(16586007)(66066001)(186003)(33026002)(8676002)(81156014)(50226002)(21086003)(86362001)(36756003)(69596002)(26005)(8936002)(50466002)(48376002)(386003)(305945005)(81166006)(97736004)(55016002)(51416003)(52116002)(53936002)(68736007)(7736002)(7696005)(59450400001)(76176011)(4326008); DIR:OUT; SFP:1101; SCL:1; SRVR:DB6PR0501MB2664; H:mellanox.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: mellanox.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DB6PR0501MB2664; 23:u2ZHmDQXgXlezgiRkZbBXxKqnz7DJ4CYy0iKbTU?= LeL2XQnW5JoPOiBAJGMGt8GC5N7i4qwX/vmA5FQ2xUsccZZnQVjANdCI4+C/O4RUYlY7cX3Tu5gzDxDkmDUUAircFc2aWMEjHlzoped5b0PznQuOHO/7ZG3qcNAkMwGu0TY09GphKv5gm0OyaO5T4dF6R9gtb7W4X0YpRTQnP2ZFHfXh1lTBN7TYSrd3nIgVbhs4bRyfbJXA8VJVcDd8Kb37lSE4MZip5RMK43twsQlk6TuKraUKvkO80XNpwz5Lx3Zvtcj6xWIaJ1f/9NuDfyqRei3H+6IFm7bzoEcUgIvXb3qc/QippY8mapYC5+EBj6PwaZvqy3afpdtLW7+ze1FdeKBCAb4HOj3jxnd2xHNTEgoGmiKEQwxQ0+SOkV7wZCb+onUh6z/ouw04STAJzt4gx6XgcpUA3L+rg+VyFBF6M/14j9GreCUJyrJWJ33q4SLmCJUWrg0PNaqQlwucq/A2YewDGuhfJzcKJyssKE9PQmGpjUxtfyrNbcxkdVjytA/O+cCeWMluY4cFfeggXQjHAcVXs5CTn+qMiOSzaBm6hyiRCeINaBw7mqYQXhGL5z5KJLhNTIrmyiExveoW0bV74+9/aDAEqT24IuvUqP6rHjZd0He4CZfBvijAOQDug4+rSfX9braWWjqzB1/rcxT2DZZ6OV7GhrDW7pz5fqVIhOqmJdKp9JUQJ57ymf+2PnBmSQ2w4EiPidKzukt8PAdO27548cgMt46J9g6ANQzmnCLBWM7U2alL0TrFqtxNUM4m2hWv5D1raREuwXG21VMkPqkgCc0tEQ+fI/ciaDE35ocpZKTQ0//ALG2goNddXkWq+U21dJrFOheWepdcnpjX7tUtBlTtzlBHqs13H8S41eo0Vld171Cw9tXDOPZ0soYT0r8E+qgS3G+Fe+3FSmhJhABbhpaLmNJHaPPXeCWDY+NZ850F92XjV5lgWXMBfmUzw0XxBctt8uzCYK/PE5vDMgKte7dUgNRTOuEdTTKyf/WYsSb6JQ9xas7x/iOWtplxHMyP54pSmdsvhnCzh40hCteYLaQgBbY5V98I4EO1b1xO50T2nb/k70YFzWivhE6BYCztJzgjhoC/P5uTC219JaqsFtyGULxGWJevH8hTITGzEPzt0jFqcliHpHiH1+rGs6PtoUWAnwFOsPNFq7ahZ X-Microsoft-Exchange-Diagnostics: 1; DB6PR0501MB2664; 6:c/nRoe7Qie/CpZhjJgjFbvHXgfzuhaYw3ZGhzpkJGIl95BnSFGJSdV5bD3cMPCoQCw6ajcLgBVQ/3QKc005nwDTP8tcaHHbeYXqpZ3zHIntWEiRheUVpo8RPFmORV1tYQyxKsX1nRelxUaCJUtBetmZ6pmSbMG3WplcGzE+qJIsmr144rzykga3ELa//5AyiNWEMTGTzIt8byo9DPZijGQ8KnhoJKTrDKTYzNCZNYL+ZkJN2L3m9E3/LLlA2R98XeqK4dXtjlA5lnlGy/P/2uYt7peutE2gf5vNWqW9MOSQZDC78atRmPMyYpbo89nhzJvmNpg5MSf8zfFGI8/hHC0GssRCDAdDbMJR+cPyJW4Y=; 5:i6+SrQIsnHxoPXm8lAe3w+LT6Bptb7ZS7ZVibQQSV24HBLBny29GdqCfpLhJPJWl0ZMcSFgYSJ/lwReN0ITppEQI48BJNUJ7nf2aY4ox7dxapHqceqQL4uDzuq346MTgJL2e1teavtKlzF7LR0UUnMNg5B6+oHwHj/IJlP42EkI=; 24:VvaeJ+gP8B9wNa5sLbDOu2xZauHxqgzQfH79AoshmJ3//M852P3FlJSbrKryZ+2AHc3hSq2O3Z0M3DycMDyAO3CLvUaOC1plH3x39z6fS2A=; 7:tLIBj9RTej6kRyuCMX7Cpa23LWQjwJOR8Jh0IGZEZgFKMrXC62QCUM+ye5ZU6I4aJ5Ai5Tu63Sko4a80dOoPzVE2PLxwj6N5uve3BdDNQv0SasKahgUhU48bV52rljyGgI6yRKogMUtlMilSrAejv66XGkltbDFhlZ/Et9diZSp3ZoTKvJia1Yh5ZxNXqKzzsjPTvPH3phQW5H2lKV1oneea93ug5BzVr0vauMnizc9+bzjiskHha9J6/mkdVYyW SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: Mellanox.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Feb 2018 16:34:30.9254 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: f5970f09-c631-445d-c744-08d56f11d4c8 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: a652971c-7d2e-4d9b-a6a4-d149256f461b X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0501MB2664 Subject: [dpdk-dev] [PATCH v5 2/3] net/failsafe: fix removal scope 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://dpdk.org/ml/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://dpdk.org/ml/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://dpdk.org/ml/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org Sender: "dev" <dev-bounces@dpdk.org> |
Checks
Context | Check | Description |
---|---|---|
ci/checkpatch | success | coding style OK |
ci/Intel-compilation | success | Compilation OK |
Commit Message
Matan Azrad
Feb. 8, 2018, 4:34 p.m. UTC
Fail-safe PMD uses per sub-device flag called "remove" to indicate the
scope where the sub-device isn't synchronized with the fail-safe state.
This flag is set when fail-safe gets RMV notification about the
physical removal of the sub-device and should be unset when the
sub-device completes all the configurations cause it to arrive to the
fail-safe state.
The previous code wrongly unsets the flag after calling to the
sub-device PMD dev_configure() operation and before all the
configurations were done.
Change the remove flag unsetting to be only after the sub-device
successes to arrive to the fail-safe state.
Fixes: a46f8d5 ("net/failsafe: add fail-safe PMD")
Cc: stable@dpdk.org
Signed-off-by: Matan Azrad <matan@mellanox.com>
---
drivers/net/failsafe/failsafe_ether.c | 2 ++
drivers/net/failsafe/failsafe_ops.c | 2 +-
2 files changed, 3 insertions(+), 1 deletion(-)
Comments
Hi Matan, Thanks for dealing with this. On Thu, Feb 08, 2018 at 04:34:12PM +0000, Matan Azrad wrote: > Fail-safe PMD uses per sub-device flag called "remove" to indicate the > scope where the sub-device isn't synchronized with the fail-safe state. > > This flag is set when fail-safe gets RMV notification about the > physical removal of the sub-device and should be unset when the > sub-device completes all the configurations cause it to arrive to the > fail-safe state. > > The previous code wrongly unsets the flag after calling to the > sub-device PMD dev_configure() operation and before all the > configurations were done. > > Change the remove flag unsetting to be only after the sub-device > successes to arrive to the fail-safe state. > I'm not sure this is the right way to do this. I think it's clear that it was a mistake to set sdev->remove to 0 only during fs_dev_configure. The flag itself only means "there is something to be done on this device, please clean up". Once the clean-up has happened, then the flag is not necessary anymore and should be reset. So I thought that this fix would actually put the flag reset within fs_dev_remove, right before reinstalling the hotplug alarm. At this point, the device state would have been set back to DEV_UNDEFINED, so the remove flag is unnecessary for any operation trying to avoid unplugged slaves. The "remove" flag is initialized at 0 when sub-devices are allocated (during fail-safe init). This means that there would be a difference in the state of the slave between its first initialization and any subsequent init, after one successful plugout. > Fixes: a46f8d5 ("net/failsafe: add fail-safe PMD") > Cc: stable@dpdk.org > > Signed-off-by: Matan Azrad <matan@mellanox.com> > --- > drivers/net/failsafe/failsafe_ether.c | 2 ++ > drivers/net/failsafe/failsafe_ops.c | 2 +- > 2 files changed, 3 insertions(+), 1 deletion(-) > > diff --git a/drivers/net/failsafe/failsafe_ether.c b/drivers/net/failsafe/failsafe_ether.c > index 4c6e938..ca42376 100644 > --- a/drivers/net/failsafe/failsafe_ether.c > +++ b/drivers/net/failsafe/failsafe_ether.c > @@ -377,6 +377,8 @@ > i); > goto err_remove; > } > + if (PRIV(dev)->state < DEV_STARTED) > + sdev->remove = 0; Here the remove flag should already be 0. If it isn't, this is a (logical) bug, which should be properly addressed instead of patched in this way. > } > } > /* > diff --git a/drivers/net/failsafe/failsafe_ops.c b/drivers/net/failsafe/failsafe_ops.c > index 7a67e16..a7c2dba 100644 > --- a/drivers/net/failsafe/failsafe_ops.c > +++ b/drivers/net/failsafe/failsafe_ops.c > @@ -131,7 +131,6 @@ > dev->data->dev_conf.intr_conf.lsc = 0; > } > DEBUG("Configuring sub-device %d", i); > - sdev->remove = 0; This is correct. > ret = rte_eth_dev_configure(PORT_ID(sdev), > dev->data->nb_rx_queues, > dev->data->nb_tx_queues, > @@ -197,6 +196,7 @@ > return ret; > } > sdev->state = DEV_STARTED; > + sdev->remove = 0; This seems unnecessary, if this operation was already performed once the device has been properly removed. > } > if (PRIV(dev)->state < DEV_STARTED) > PRIV(dev)->state = DEV_STARTED; > -- > 1.8.3.1 >
Hi Gaetan From: Gaëtan Rivet, Thursday, February 8, 2018 7:20 PM > Hi Matan, > > Thanks for dealing with this. > > On Thu, Feb 08, 2018 at 04:34:12PM +0000, Matan Azrad wrote: > > Fail-safe PMD uses per sub-device flag called "remove" to indicate the > > scope where the sub-device isn't synchronized with the fail-safe state. > > > > This flag is set when fail-safe gets RMV notification about the > > physical removal of the sub-device and should be unset when the > > sub-device completes all the configurations cause it to arrive to the > > fail-safe state. > > > > The previous code wrongly unsets the flag after calling to the > > sub-device PMD dev_configure() operation and before all the > > configurations were done. > > > > Change the remove flag unsetting to be only after the sub-device > > successes to arrive to the fail-safe state. > > > > I'm not sure this is the right way to do this. > I think it's clear that it was a mistake to set sdev->remove to 0 only during > fs_dev_configure. > > The flag itself only means "there is something to be done on this device, > please clean up". > > Once the clean-up has happened, then the flag is not necessary anymore > and should be reset. > > So I thought that this fix would actually put the flag reset within > fs_dev_remove, right before reinstalling the hotplug alarm. > > At this point, the device state would have been set back to DEV_UNDEFINED, > so the remove flag is unnecessary for any operation trying to avoid > unplugged slaves. > > The "remove" flag is initialized at 0 when sub-devices are allocated (during > fail-safe init). This means that there would be a difference in the state of the > slave between its first initialization and any subsequent init, after one > successful plugout. > But what's about plug-in process? Do you want to allow control commands for a sub-device while it is plugging-in? Unset the remove flag in fs_dev_remove allows to control commands to occur in parallel to plug in process. Maybe the name of the flag should be changed to unsynchronized. > > Fixes: a46f8d5 ("net/failsafe: add fail-safe PMD") > > Cc: stable@dpdk.org > > > > Signed-off-by: Matan Azrad <matan@mellanox.com> > > --- > > drivers/net/failsafe/failsafe_ether.c | 2 ++ > > drivers/net/failsafe/failsafe_ops.c | 2 +- > > 2 files changed, 3 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/net/failsafe/failsafe_ether.c > > b/drivers/net/failsafe/failsafe_ether.c > > index 4c6e938..ca42376 100644 > > --- a/drivers/net/failsafe/failsafe_ether.c > > +++ b/drivers/net/failsafe/failsafe_ether.c > > @@ -377,6 +377,8 @@ > > i); > > goto err_remove; > > } > > + if (PRIV(dev)->state < DEV_STARTED) > > + sdev->remove = 0; > > Here the remove flag should already be 0. If it isn't, this is a > (logical) bug, which should be properly addressed instead of patched in this > way. Same answer as above. > > } > > } > > /* > > diff --git a/drivers/net/failsafe/failsafe_ops.c > > b/drivers/net/failsafe/failsafe_ops.c > > index 7a67e16..a7c2dba 100644 > > --- a/drivers/net/failsafe/failsafe_ops.c > > +++ b/drivers/net/failsafe/failsafe_ops.c > > @@ -131,7 +131,6 @@ > > dev->data->dev_conf.intr_conf.lsc = 0; > > } > > DEBUG("Configuring sub-device %d", i); > > - sdev->remove = 0; > > This is correct. > > > ret = rte_eth_dev_configure(PORT_ID(sdev), > > dev->data->nb_rx_queues, > > dev->data->nb_tx_queues, > > @@ -197,6 +196,7 @@ > > return ret; > > } > > sdev->state = DEV_STARTED; > > + sdev->remove = 0; > > This seems unnecessary, if this operation was already performed once the > device has been properly removed. Same answer as above. > > } > > if (PRIV(dev)->state < DEV_STARTED) > > PRIV(dev)->state = DEV_STARTED; > > -- > > 1.8.3.1 > > > > -- > Gaëtan Rivet > 6WIND
diff --git a/drivers/net/failsafe/failsafe_ether.c b/drivers/net/failsafe/failsafe_ether.c index 4c6e938..ca42376 100644 --- a/drivers/net/failsafe/failsafe_ether.c +++ b/drivers/net/failsafe/failsafe_ether.c @@ -377,6 +377,8 @@ i); goto err_remove; } + if (PRIV(dev)->state < DEV_STARTED) + sdev->remove = 0; } } /* diff --git a/drivers/net/failsafe/failsafe_ops.c b/drivers/net/failsafe/failsafe_ops.c index 7a67e16..a7c2dba 100644 --- a/drivers/net/failsafe/failsafe_ops.c +++ b/drivers/net/failsafe/failsafe_ops.c @@ -131,7 +131,6 @@ dev->data->dev_conf.intr_conf.lsc = 0; } DEBUG("Configuring sub-device %d", i); - sdev->remove = 0; ret = rte_eth_dev_configure(PORT_ID(sdev), dev->data->nb_rx_queues, dev->data->nb_tx_queues, @@ -197,6 +196,7 @@ return ret; } sdev->state = DEV_STARTED; + sdev->remove = 0; } if (PRIV(dev)->state < DEV_STARTED) PRIV(dev)->state = DEV_STARTED;