From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30069.outbound.protection.outlook.com [40.107.3.69]) by dpdk.org (Postfix) with ESMTP id CA95E1B84F; Thu, 8 Feb 2018 20:03:17 +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=r4NrCoZCMw/w+kWz5z8Ck4r04dIV+DxZpKBDQDxQR/Q=; b=riqvpzaz6Hzb8Kx05EQ8Qm6A747wrb6lHpQv52AUqF69yCnSxaULIB/LcNKBepYlQDhOSeyPZSvz7HuTbTH7ycUtOKwkM2rdgXMBUKCRfPSXbcYj1lAe6rvmVjy6ilRl9sGQUzaXfWQ3XcT3jwx/VtnGMBF1vOTxmjahbKgF+MY= Received: from AM4PR0501MB2657.eurprd05.prod.outlook.com (10.172.215.19) by AM4PR0501MB1939.eurprd05.prod.outlook.com (10.167.91.23) 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 19:03:15 +0000 Received: from AM4PR0501MB2657.eurprd05.prod.outlook.com ([fe80::80c6:df5:b1b0:ff05]) by AM4PR0501MB2657.eurprd05.prod.outlook.com ([fe80::80c6:df5:b1b0:ff05%17]) with mapi id 15.20.0485.009; Thu, 8 Feb 2018 19:03:15 +0000 From: Matan Azrad To: =?iso-8859-1?Q?Ga=EBtan_Rivet?= CC: "dev@dpdk.org" , "stable@dpdk.org" , "Ophir Munk" Thread-Topic: [PATCH v5 2/3] net/failsafe: fix removal scope Thread-Index: AQHToQEFvv8od7rbYEW4tivY1EJkX6Oa2w9g Date: Thu, 8 Feb 2018 19:03:15 +0000 Message-ID: References: <1518092427-4333-1-git-send-email-matan@mellanox.com> <1518107653-15466-1-git-send-email-matan@mellanox.com> <1518107653-15466-3-git-send-email-matan@mellanox.com> <20180208171931.oxiqp6433pmft36m@bidouze.vm.6wind.com> In-Reply-To: <20180208171931.oxiqp6433pmft36m@bidouze.vm.6wind.com> Accept-Language: en-US, he-IL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=matan@mellanox.com; x-originating-ip: [85.64.136.190] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR0501MB1939; 7:zBH1nG0j3S1Tp0/AZrq3jF13Si1DqRohpwp0g+RNhvli+/E6B3byEBLYvGRYDoqtF5rTF0AlWGnrLYuM8++3AR1lmvm6ve6aiUNGfOX9sHUAhKb1kDqGGB8G3SdWncmii4QRUmDLx6sgiwjGwLVnI33TeR7ld+sEvqbboWJG5rrZm5xfg6fynbQcpC+zjiX7Xa/Il9PkLKkKmo4J0zvek624OCeAD46jHQldwf4MF4RFjC+vcSjFLbmP0BJobK6b x-ms-exchange-antispam-srfa-diagnostics: SSOS;SSOR; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: ee3fceed-66b4-4421-b892-08d56f269bec x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:AM4PR0501MB1939; x-ms-traffictypediagnostic: AM4PR0501MB1939: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(3231101)(2400082)(944501161)(6055026)(6041288)(20161123558120)(20161123564045)(20161123562045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:AM4PR0501MB1939; BCL:0; PCL:0; RULEID:; SRVR:AM4PR0501MB1939; x-forefront-prvs: 0577AD41D6 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(396003)(376002)(366004)(39860400002)(39380400002)(189003)(199004)(105586002)(6916009)(81156014)(97736004)(8676002)(6116002)(3660700001)(3846002)(3280700002)(106356001)(55016002)(107886003)(9686003)(93886005)(26005)(6506007)(59450400001)(6246003)(66066001)(316002)(7736002)(53936002)(33656002)(2950100002)(68736007)(7696005)(25786009)(74316002)(2900100001)(305945005)(478600001)(86362001)(99286004)(5250100002)(5660300001)(186003)(102836004)(2906002)(4326008)(76176011)(229853002)(54906003)(6436002)(8936002)(14454004)(81166006); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0501MB1939; H:AM4PR0501MB2657.eurprd05.prod.outlook.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-antispam-message-info: JiRpGW063lD8Ui7DsRH587dD49p0xEFj5A/255OHp3KK7OMVKNl0p3PlJzFgB/p3HKYyUzBav5DdaKKFsMcngA== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: Mellanox.com X-MS-Exchange-CrossTenant-Network-Message-Id: ee3fceed-66b4-4421-b892-08d56f269bec X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Feb 2018 19:03:15.6497 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a652971c-7d2e-4d9b-a6a4-d149256f461b X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0501MB1939 Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Feb 2018 19:03:17 -0000 Hi Gaetan From: Ga=EBtan Rivet, Thursday, February 8, 2018 7:20 PM > Hi Matan, >=20 > Thanks for dealing with this. >=20 > 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. > > >=20 > 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 du= ring > fs_dev_configure. >=20 > The flag itself only means "there is something to be done on this device, > please clean up". >=20 > Once the clean-up has happened, then the flag is not necessary anymore > and should be reset. >=20 > So I thought that this fix would actually put the flag reset within > fs_dev_remove, right before reinstalling the hotplug alarm. >=20 > 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. >=20 > The "remove" flag is initialized at 0 when sub-devices are allocated (dur= ing > 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. >=20 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. =20 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 > > --- > > 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 =3D 0; >=20 > 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 t= his > 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 =3D 0; > > } > > DEBUG("Configuring sub-device %d", i); > > - sdev->remove =3D 0; >=20 > This is correct. >=20 > > ret =3D 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 =3D DEV_STARTED; > > + sdev->remove =3D 0; >=20 > This seems unnecessary, if this operation was already performed once the > device has been properly removed. Same answer as above. =20 > > } > > if (PRIV(dev)->state < DEV_STARTED) > > PRIV(dev)->state =3D DEV_STARTED; > > -- > > 1.8.3.1 > > >=20 > -- > Ga=EBtan Rivet > 6WIND