From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0081.outbound.protection.outlook.com [104.47.0.81]) by dpdk.org (Postfix) with ESMTP id 9EE9A1B014 for ; Mon, 8 Jan 2018 15:00:57 +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=799s0RL8NlnaKYM9a4UK3LlE92JXvqpwHqCdwzHs5qg=; b=mHhHfxD1XbHRi+2f0Xks4nQs2GozTFrcgXT6dMVkE9eNTP6gOqpUHGW2JALmC+rUvj08tSuXdea0hHTI9cLMtz+tILNcSH6QVueLXfUSGJLOvXFfYZkmkVCcWTZjxiTPOWw0xyiwxljGXNpN/iDoTQLetPqe/tn2wznCkd8Ygow= Received: from AM6PR0502MB3797.eurprd05.prod.outlook.com (52.133.21.26) by AM6PR0502MB3799.eurprd05.prod.outlook.com (52.133.21.28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.386.5; Mon, 8 Jan 2018 14:00:54 +0000 Received: from AM6PR0502MB3797.eurprd05.prod.outlook.com ([fe80::b4b4:7de8:cf70:aa3a]) by AM6PR0502MB3797.eurprd05.prod.outlook.com ([fe80::b4b4:7de8:cf70:aa3a%13]) with mapi id 15.20.0386.006; Mon, 8 Jan 2018 14:00:54 +0000 From: Matan Azrad To: =?iso-8859-1?Q?Ga=EBtan_Rivet?= CC: Adrien Mazarguil , Thomas Monjalon , "dev@dpdk.org" Thread-Topic: [PATCH v3 6/6] net/failsafe: fix removed device handling Thread-Index: AQHTeRfCVjig+VM1dkqFOSUojatLK6NMDewggB3e44CAAB0D8IAAEkcAgAADA2A= Date: Mon, 8 Jan 2018 14:00:54 +0000 Message-ID: References: <1513175370-16583-1-git-send-email-matan@mellanox.com> <1513703415-29145-1-git-send-email-matan@mellanox.com> <1513703415-29145-7-git-send-email-matan@mellanox.com> <20171219222131.plcfn5wqggyn5znw@bidouze.vm.6wind.com> <20180108105739.qkyejshupojkwyv2@bidouze.vm.6wind.com> <20180108134654.wb7svquzhuuvvmh6@bidouze.vm.6wind.com> In-Reply-To: <20180108134654.wb7svquzhuuvvmh6@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: [193.47.165.251] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM6PR0502MB3799; 7:ZDTkOmulvKpyDo3XMS6w8s/UVjoJCcfwCxHAZGxgJVTbuqc3aVJjv6qtFfUUqrgnezfZI5P5GsoD3ktQob8Wyf/7UN+didE0NTHTES45IPxX/5uL8ORTrBO6AerDSu901rMkUJbiK9A86uCuPYApkUn6De0unkUy6E1FOFZPCTNtMdZqrmCDY8NvRyyCnC71we0P1P9eu0H1jz1p9uE1GZiARszFVKo+J5lfcFNda0E91cSn8Ka3nvZdwcrYhz0E x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 2fd9f32c-0b5f-4c83-10ca-08d556a03c3b x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(48565401081)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:AM6PR0502MB3799; x-ms-traffictypediagnostic: AM6PR0502MB3799: x-ld-processed: a652971c-7d2e-4d9b-a6a4-d149256f461b,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(3231023)(944501075)(6055026)(6041268)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123558120)(20161123560045)(6072148)(201708071742011); SRVR:AM6PR0502MB3799; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:AM6PR0502MB3799; x-forefront-prvs: 054642504A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(396003)(366004)(39380400002)(376002)(39860400002)(189003)(199004)(24454002)(7696005)(14454004)(3660700001)(105586002)(33656002)(53936002)(4326008)(2950100002)(76176011)(3280700002)(6246003)(6916009)(59450400001)(74316002)(478600001)(66066001)(2906002)(5660300001)(99286004)(305945005)(25786009)(68736007)(7736002)(106356001)(2900100001)(86362001)(97736004)(3846002)(6116002)(55016002)(229853002)(9686003)(5250100002)(316002)(102836004)(54906003)(8936002)(93886005)(6436002)(8676002)(6506007)(81166006)(81156014); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR0502MB3799; H:AM6PR0502MB3797.eurprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:3; A:1; LANG:en; received-spf: None (protection.outlook.com: mellanox.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: qqFIYcj/5YQ4uqw/WMH8dywUPZEKKdv6DySGpMQg/Ff7PXtWPXUWKoo6LT1PzvBuOJmFx4d4Zox3RLUXm0T5rg== 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: 2fd9f32c-0b5f-4c83-10ca-08d556a03c3b X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jan 2018 14:00:54.7115 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a652971c-7d2e-4d9b-a6a4-d149256f461b X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR0502MB3799 Subject: Re: [dpdk-dev] [PATCH v3 6/6] net/failsafe: fix removed device handling 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: Mon, 08 Jan 2018 14:00:57 -0000 Hi Gaetan From: Ga=EBtan Rivet, Monday, January 8, 2018 3:47 PM > On Mon, Jan 08, 2018 at 12:55:49PM +0000, Matan Azrad wrote: > > Hi Gaetan > > > > From: Ga=EBtan Rivet, Monday, January 8, 2018 12:58 PM > > > Hi Matan, > > > > > > Sorry for the delay on this. > > > > > > > It's OK in spite of I need to fetch it back :) > > > > > On Wed, Dec 20, 2017 at 10:58:29AM +0000, Matan Azrad wrote: > > > And this kind of code-flow is not unusual, or even unwanted. > > > I dislike having this kind of implicit rule derived from using a > > > helper such as fs_is_error(). > > > > > > The alternative > > > > > > if ((err =3D fs_err(sdev, err))) { > > > ERROR("xxxx"); > > > return err; > > > } > > > > > > Forces the value err to be set to the correct one. > > > > > Good point, will change it. > > > > > This mistake can already be found in your patch: > > > > > > > @@ -150,7 +150,7 @@ > > > > continue; > > > > local_ret =3D rte_flow_destroy(PORT_ID(sdev), > > > > flow->flows[i], error); > > > > - if (local_ret) { > > > > + if (fs_is_error(sdev, local_ret)) { > > > > ERROR("Failed to destroy flow on sub_device= %d: %d", > > > > i, local_ret); > > > > if (ret =3D=3D 0) > > > > > > > Sorry, I can't see any issue here. > > >=20 > You're right, actually the code would still be correct. > I checked again the rest of the edit, there shouldn't be any issue, usual= ly "0" > is explicitly returned. >=20 > Still, the point stands. >=20 Yes. > > > Your environment does not include the function, but this is within > > > fs_flow_destroy (please update to include the context by the way it > > > helps a lot the review :). Afterward, line 162 ret is directly used a= s return > value. > > > > > I don't understand what do you mean. > > > > > Also, fs_err() would need to transform rte_errno when relevant > > > (mostly in failsafe_flow.c I think). > > > > > Your suggestion is always to update rte_errno to 0 in case the error is > because of removal? > > >=20 > If the error is indeed due to the device being absent, then rte_errno sho= uld > be set back to its previous value I think. So, I think it will require old rte_errno save before each device command..= . Why not to set it to 0 in the special case(removal) by the new internal API= ? >=20 > -- > Ga=EBtan Rivet > 6WIND