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 09F8EA0096 for ; Thu, 9 May 2019 10:58:17 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 8679C4CA0; Thu, 9 May 2019 10:58:17 +0200 (CEST) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70043.outbound.protection.outlook.com [40.107.7.43]) by dpdk.org (Postfix) with ESMTP id 2B27F37B7; Thu, 9 May 2019 10:58:14 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nxp.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XjAvQcQSVc/456onJHhGXUsQ7sc0zf60FTvP2ypikqA=; b=o5M0AVVTqJieFP577OVc6fToPglSlBh/37rIK67aW7Gzl7v1pS3AjlMnBSLSO8/RyJRD2FNGBhoAaaWl7bmQuRdw8Worg2o2A3IioIxD3A7VhPIsWh5uy4p2KD/7IRCbSS86N1wVjsxPb5sivQgNUnZyTil1fOg9KPs9Lqgr2tk= Received: from VI1PR04MB4893.eurprd04.prod.outlook.com (20.177.49.154) by VI1PR04MB3021.eurprd04.prod.outlook.com (10.170.228.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1856.11; Thu, 9 May 2019 08:58:12 +0000 Received: from VI1PR04MB4893.eurprd04.prod.outlook.com ([fe80::98b0:84a6:1c08:57c7]) by VI1PR04MB4893.eurprd04.prod.outlook.com ([fe80::98b0:84a6:1c08:57c7%3]) with mapi id 15.20.1856.016; Thu, 9 May 2019 08:58:12 +0000 From: Akhil Goyal To: "Trahe, Fiona" , Shally Verma , "dev@dpdk.org" CC: Ashish Gupta , "Daly, Lee" , Sunila Sahu , "stable@dpdk.org" Thread-Topic: [PATCH v2] doc/compress: clarify error handling on data-plane Thread-Index: AQHU/3J2BWTCNc5ewUOlcpCkMFbNZKZf8dwAgAATXoCAATKQgIAAFjoAgAE9OMA= Date: Thu, 9 May 2019 08:58:12 +0000 Message-ID: References: <1554740072-11898-1-git-send-email-fiona.trahe@intel.com> <1554821747-27868-1-git-send-email-fiona.trahe@intel.com> <348A99DA5F5B7549AA880327E580B4358974F5BC@IRSMSX101.ger.corp.intel.com> <348A99DA5F5B7549AA880327E580B435897553D3@IRSMSX101.ger.corp.intel.com> <348A99DA5F5B7549AA880327E580B4358975602D@IRSMSX101.ger.corp.intel.com> In-Reply-To: <348A99DA5F5B7549AA880327E580B4358975602D@IRSMSX101.ger.corp.intel.com> Accept-Language: en-IN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=akhil.goyal@nxp.com; x-originating-ip: [92.120.1.65] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4ae91f58-6516-4e66-bf56-08d6d45c779e x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:VI1PR04MB3021; x-ms-traffictypediagnostic: VI1PR04MB3021: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 003245E729 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(366004)(39860400002)(376002)(396003)(346002)(13464003)(189003)(199004)(53936002)(4326008)(478600001)(5660300002)(6246003)(2906002)(74316002)(99286004)(14454004)(25786009)(52536014)(2501003)(476003)(71190400001)(71200400001)(14444005)(256004)(76116006)(66556008)(66446008)(64756008)(66476007)(66066001)(73956011)(66946007)(86362001)(33656002)(8936002)(110136005)(3846002)(6116002)(446003)(486006)(44832011)(6506007)(53546011)(229853002)(7696005)(11346002)(76176011)(305945005)(7736002)(9686003)(81156014)(102836004)(316002)(8676002)(68736007)(6436002)(54906003)(186003)(81166006)(55016002)(26005); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR04MB3021; H:VI1PR04MB4893.eurprd04.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: nxp.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: +3OSiJvdIcfEWoJ+Cl+n/UddWHjr2SeVo8I0JHye9slfmVSMfTKDgxAAzW/HcCylNC6VND6xwjnABh9+WLfHIDHlAdsJkEyjCMZtvY0/U0pr7Jf9RExZPCNVNNQR5L+gQBRJzpRfGMClxYj7R/+KO28zkywmfO+lUf5PcXG6clHYBxsyVy+xg9Ywnlgy3XZCGDRLqN7Y2o8tfrWbf53oCyRXUbnJCpwMfuDPOJF5p2JzLS31wHYKSWBts3LvxyXkzunG1omL4gJj8iTUAspdvt/UI+Ft/oMrYL2vRva7RSWZyZa9BPfdlL7ihmDtzVq3ikef6Uqhq405pQp4ANOX1cfhBTcTdhv6YyW8/4EYfYW5XWG4IkKuEJf6fyxcKm1DU8FBebkMw9X7maAtmcpcPmTTiozKF9CusHnTHa5wNlM= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nxp.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4ae91f58-6516-4e66-bf56-08d6d45c779e X-MS-Exchange-CrossTenant-originalarrivaltime: 09 May 2019 08:58:12.7335 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR04MB3021 Subject: Re: [dpdk-stable] [PATCH v2] doc/compress: clarify error handling on data-plane X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org Sender: "stable" Hi Fiona/Shally, Can we get a closure on this patch by today EOD(We are closing tree for RC4= today). Thomas will pick this patch directly on master. Thanks, Akhil > -----Original Message----- > From: Trahe, Fiona > Sent: Wednesday, May 8, 2019 7:31 PM > To: Shally Verma ; dev@dpdk.org > Cc: Akhil Goyal ; Ashish Gupta = ; > Daly, Lee ; Sunila Sahu ; > stable@dpdk.org; Trahe, Fiona > Subject: RE: [PATCH v2] doc/compress: clarify error handling on data-plan= e >=20 > HI Shally, >=20 > > -----Original Message----- > > From: Shally Verma [mailto:shallyv@marvell.com] > > Sent: Wednesday, May 8, 2019 1:41 PM > > To: Trahe, Fiona ; dev@dpdk.org > > Cc: akhil.goyal@nxp.com; Ashish Gupta ; Daly, Lee > ; Sunila > > Sahu ; stable@dpdk.org > > Subject: RE: [PATCH v2] doc/compress: clarify error handling on data-pl= ane > > > > Hi Fiona > > > > > > > -----Original Message----- > > > From: Trahe, Fiona > > > Sent: Tuesday, May 7, 2019 11:54 PM > > > To: Shally Verma ; dev@dpdk.org > > > Cc: akhil.goyal@nxp.com; Ashish Gupta ; Daly, Le= e > > > ; Sunila Sahu ; stable@dpdk.or= g; > > > Trahe, Fiona > > > Subject: RE: [PATCH v2] doc/compress: clarify error handling on data-= plane > > > > > > Hi Shally > > > > > > > > > > + > > > > > > > +There are some exceptions whereby errors can occur on the > > > > > ``enqueue``. > > > > > > > +For any error which can occur in a production environment an= d > > > > > > > +can be successful after a retry with the same op the PMD may > > > > > > > +return the error on the enqueue. > > > > > > This statement looks bit confusing. > > > > > > Seems like we are trying to add a description regarding op stat= us > > > > > > check even after the enqueue call unlike current scenario, wher= e > > > > > > app only check for it after dequeue? > > > > > [Fiona] The line following this explains that there is no need to > > > > > check op.status in this case. > > > > > Maybe it's not obvious that the application SHOULD check that all > > > > > ops are enqueued? > > > > > I can reword as: > > > > > The application should always check the value returned by the enq= ueue. > > > > > If less than the full burst is enqueued there's no need for the > > > > > application to check op.status of any or every op - it can simply > > > > > retry from the return > > > > > value+1 in a later enqueue and expect success. > > > > > > > > > I agree to purpose of patch but have these confusions when I read > > > description above: > > > > > > > > My understand is , if op status is INVALID_ARGS or any ERROR which = is > > > > permanent in nature, Then nb_enqd return will be less than actually > > > passed. > > > [Fiona] True. > > > > > > > Regardless of whatever reason, if any time app gets nb_enqd < actua= lly > > > > passed, then app should check status of nb_enqd + 1th op > > > [Fiona]. No, that's exactly what I was proposing to avoid. > > > > > > > to find exact cause of failure and then either attempt re-enqueue O= r > > > > correct op preparation or take any other appropriate action. > > > [Fiona] I was proposing to constrain PMDs to only return a subset of = errors > > > on the enqueue, so apps could be optimised. > > > But if you think it's not possible for PMDs to comply with it, then y= es, apps > > > would always have to check status of nb_enqd + 1th op, and fork depen= ding > > > on the status. > > > Is this the case? > > > If so, much of this patch is unnecessary and I'll send a simplified v= 3 as almost > > > any status can be returned anywhere. > > > > > [Shally] Okay. I seem to understand it now. > > Purpose seem reasonable just a simpler rephrase would help. > > It will be easier for me to further feedback on 1st v2 patch sent. So w= ill send it > another email. > [Fiona] ok, will look for that. >=20 >=20 > > > > Also, STATUS_ERROR is very generic, it can be when queue is full in > > > > which case app can re-attempt an enqueue of same op > > > OR > > > > It can also indicate any irrecoverable error on enqueue, in which a= pp > > > > just probably has to reset everything. For such kind of case, it mi= ght > > > > not be possible for PMD design to even push it into completion queu= e > > > > for an app to dequeue . I would suggest add another status code t= ype > > > > which reflect permanent error condition i.e. irrecoverable error co= de > > > > which tells an app to perform PMD qp reset/re-init to recover and s= implify > > > description just to state an expected APP behavior to avoid infinite = loop > > > condition. > > > > It is then an app choice whether or not to check for op status for > > > > error after enqueue depending on whether its running in production > > > environment or dev environment. > > > [Fiona] I wouldn't expect ERROR in a queue full case. I'd see ERROR a= s the > > > catch-all when some other specific status isn't appropriate. If you t= hink > > > there's a need for another specific status then best send an API patc= h > > > proposing it. This patch is only documenting the existing set. > > > > [Shally] Sorry, I missed. STATUS_NOT_PROCESSED can be indication of > queue_full. > > STATUS_ERROR on dequeue =3D any catch-all error case > > STATUS_ERROR on enqueue =3D any irrecoverable error on op. app should n= ot > attempt same op or may be > > reset queue pair or PMD. > > > > Is this interpretation correct? > [Fiona] Yes