From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <dev-bounces@dpdk.org> Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id B9848A0096 for <public@inbox.dpdk.org>; Tue, 7 May 2019 20:24:18 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 861E53772; Tue, 7 May 2019 20:24:16 +0200 (CEST) Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by dpdk.org (Postfix) with ESMTP id B6B312BD5; Tue, 7 May 2019 20:24:13 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga104.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 May 2019 11:24:12 -0700 X-ExtLoop1: 1 Received: from irsmsx109.ger.corp.intel.com ([163.33.3.23]) by orsmga008.jf.intel.com with ESMTP; 07 May 2019 11:24:10 -0700 Received: from irsmsx111.ger.corp.intel.com (10.108.20.4) by IRSMSX109.ger.corp.intel.com (163.33.3.23) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 7 May 2019 19:24:09 +0100 Received: from irsmsx101.ger.corp.intel.com ([169.254.1.115]) by irsmsx111.ger.corp.intel.com ([169.254.2.85]) with mapi id 14.03.0415.000; Tue, 7 May 2019 19:24:09 +0100 From: "Trahe, Fiona" <fiona.trahe@intel.com> To: Shally Verma <shallyv@marvell.com>, "dev@dpdk.org" <dev@dpdk.org> CC: "akhil.goyal@nxp.com" <akhil.goyal@nxp.com>, Ashish Gupta <ashishg@marvell.com>, "Daly, Lee" <lee.daly@intel.com>, Sunila Sahu <ssahu@marvell.com>, "stable@dpdk.org" <stable@dpdk.org>, "Trahe, Fiona" <fiona.trahe@intel.com> Thread-Topic: [PATCH v2] doc/compress: clarify error handling on data-plane Thread-Index: AQHU7uRoniPOIsNkTEyu55+FfYvFQqZB0WaAgBMsX4CACwRwAIAAF5Kg Date: Tue, 7 May 2019 18:24:09 +0000 Message-ID: <348A99DA5F5B7549AA880327E580B435897553D3@IRSMSX101.ger.corp.intel.com> References: <1554740072-11898-1-git-send-email-fiona.trahe@intel.com> <1554821747-27868-1-git-send-email-fiona.trahe@intel.com> <BN6PR1801MB20521B48C169DA254FF78019AD260@BN6PR1801MB2052.namprd18.prod.outlook.com> <348A99DA5F5B7549AA880327E580B4358974F5BC@IRSMSX101.ger.corp.intel.com> <BN6PR1801MB20524947F09A7520B79F318FAD310@BN6PR1801MB2052.namprd18.prod.outlook.com> In-Reply-To: <BN6PR1801MB20524947F09A7520B79F318FAD310@BN6PR1801MB2052.namprd18.prod.outlook.com> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNzA3ODg3NjMtZWJkMi00OGI5LWJjNjAtMjA1ZTViNjNkMmQyIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiU1NsT1BGeFNxUG5SOFBUaHpjWmlRTXBJTWtwN2JkZzNIZ0hReXd2Y1JxMm44ZTFBbnEzcGJpQWUyY1FhNjlKbCJ9 x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.0.600.7 dlp-reaction: no-action x-originating-ip: [163.33.239.182] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH v2] doc/compress: clarify error handling on data-plane 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://mails.dpdk.org/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org Sender: "dev" <dev-bounces@dpdk.org> Message-ID: <20190507182409.5HKHthrWlxS3DPWTQ08URVUNk11p92eGbr5aeJiAeJY@z> Hi Shally > > > > + > > > > +There are some exceptions whereby errors can occur on the > > ``enqueue``. > > > > +For any error which can occur in a production environment and can > > > > +be successful after a retry with the same op the PMD may return th= e > > > > +error on the enqueue. > > > This statement looks bit confusing. > > > Seems like we are trying to add a description regarding op status > > > check even after the enqueue call unlike current scenario, where 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 a= re > > enqueued? > > I can reword as: > > The application should always check the value returned by the enqueue. > > If less than the full burst is enqueued there's no need for the applica= tion to > > check op.status of any or every op - it can simply retry from the retur= n > > value+1 in a later enqueue and expect success. > > > I agree to purpose of patch but have these confusions when I read descri= ption above: >=20 > My understand is , if op status is INVALID_ARGS or any ERROR which is per= manent in nature, > Then nb_enqd return will be less than actually passed.=20 [Fiona] True. > Regardless of whatever reason, if any time app gets > nb_enqd < actually passed, then app should check status of nb_enqd + 1th = op=20 [Fiona]. No, that's exactly what I was proposing to avoid. > to find exact cause of failure and then either attempt re-enqueue Or corr= ect 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 yes, ap= ps would always have to check status of nb_enqd + 1th op, and fork depending on the status. Is this the case? If so, much of this patch is unnecessary and I'll send a simplified v3 as a= lmost any status can be returned anywhere. =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 app jus= t probably has to reset > everything. For such kind of case, it might not be possible for PMD desig= n > to even push it into completion queue for an app to dequeue . I would su= ggest add another status code > type which reflect permanent error condition i.e. irrecoverable error cod= e > which tells an app to perform PMD qp reset/re-init to recover and simplif= y 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 as the = catch-all when some other specific status isn't appropriate. If you think there's a need for an= other specific status then best send an API patch proposing it. This patch is only documenting the exi= sting set.