From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) by dpdk.org (Postfix) with ESMTP id 7A07C2BD5; Wed, 8 May 2019 14:41:30 +0200 (CEST) Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x48CTrSb007788; Wed, 8 May 2019 05:41:29 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marvell.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=pfpt0818; bh=62zHiBX/XluXyx7nxafaDrnR/apHCS5JvMLztunnOOA=; b=i+XkXqKJjAdWKrNx7fMsBzJ2oGh6DJIJkvy70mevU4SrEk+Eom7Z8SRaIsfOjx/gZ6+s ftPPoZOPN9NsMHuYUHO9P6Apu5V0p6z+d937oXfbI6kM8/ghPvut1TXbViUn/srHYXao QtqurNuLqU8ACF1/h9Wke0EIGyRRtOjHLtMfITSlganTGUF5mPdi8kQQrV4lOgrjmUG5 3CPHXyb01c5bWrv6RqpCDrykixMPwrM8v51u2sa4XTsPEN5iM7XRWSJsRJCkxZRq6Tz5 lzYx5qPv+3sNZkNNdwDpnTnEB1atQwpk6TLdxlctGRnvi4Kek6Z9KP6BzXahzYV6qVPM Lg== Received: from sc-exch03.marvell.com ([199.233.58.183]) by mx0b-0016f401.pphosted.com with ESMTP id 2sbxw0r3dc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 08 May 2019 05:41:29 -0700 Received: from SC-EXCH04.marvell.com (10.93.176.84) by SC-EXCH03.marvell.com (10.93.176.83) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Wed, 8 May 2019 05:41:28 -0700 Received: from NAM04-SN1-obe.outbound.protection.outlook.com (104.47.44.54) by SC-EXCH04.marvell.com (10.93.176.84) with Microsoft SMTP Server (TLS) id 15.0.1367.3 via Frontend Transport; Wed, 8 May 2019 05:41:27 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marvell.onmicrosoft.com; s=selector1-marvell-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=62zHiBX/XluXyx7nxafaDrnR/apHCS5JvMLztunnOOA=; b=vwK25k+pKkr21pXzhzTEExaKTd6YIKm6hOgm6ThqgNHsRfUWUSPspt2QnkPTPRxvETwt00VfaBPQtXQhP5exVwnvdjVv7/Fws8HRaGLLFnnVZEofiy0WCETNqnSzOoJiWZNJDYTosL9TRLxNOFbXd70aOvPWHKEHnxESGbYuvjc= Received: from BN6PR1801MB2052.namprd18.prod.outlook.com (10.161.157.11) by BN6PR1801MB1876.namprd18.prod.outlook.com (10.161.154.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1856.10; Wed, 8 May 2019 12:41:23 +0000 Received: from BN6PR1801MB2052.namprd18.prod.outlook.com ([fe80::99fe:90b9:ca17:a552]) by BN6PR1801MB2052.namprd18.prod.outlook.com ([fe80::99fe:90b9:ca17:a552%6]) with mapi id 15.20.1856.012; Wed, 8 May 2019 12:41:23 +0000 From: Shally Verma To: "Trahe, Fiona" , "dev@dpdk.org" CC: "akhil.goyal@nxp.com" , Ashish Gupta , "Daly, Lee" , Sunila Sahu , "stable@dpdk.org" Thread-Topic: [PATCH v2] doc/compress: clarify error handling on data-plane Thread-Index: AQHU7uRcY1b0dFOFhkSSkiDYaczK7aZB3cywgBMpTgCACwagIIAAGJyAgAEwVcA= Date: Wed, 8 May 2019 12:41:23 +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> In-Reply-To: <348A99DA5F5B7549AA880327E580B435897553D3@IRSMSX101.ger.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [115.113.156.2] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7148e3f1-88e4-4bee-84a8-08d6d3b27a92 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(7168020)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:BN6PR1801MB1876; x-ms-traffictypediagnostic: BN6PR1801MB1876: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0031A0FFAF x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(376002)(39860400002)(346002)(366004)(136003)(199004)(189003)(13464003)(7696005)(76176011)(86362001)(2501003)(446003)(11346002)(476003)(66446008)(64756008)(73956011)(66946007)(76116006)(55016002)(6436002)(68736007)(52536014)(229853002)(486006)(6246003)(66476007)(53936002)(81156014)(66556008)(81166006)(8676002)(2906002)(6116002)(3846002)(9686003)(186003)(25786009)(6506007)(53546011)(4326008)(55236004)(8936002)(26005)(33656002)(102836004)(478600001)(66066001)(14454004)(71190400001)(71200400001)(7736002)(74316002)(305945005)(5660300002)(110136005)(54906003)(316002)(99286004)(256004)(14444005); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR1801MB1876; H:BN6PR1801MB2052.namprd18.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: marvell.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: VbpPyhmyB5kYg5grM84yf/tPDsbkGdh5zRSJTpGLnbJ4iaXMPnxEBwB6sQbVRUc3iIZThDUzd+jDICkyinoWxJIzSOf+/2f3p3SRfE189jH2jhmjEDVdysanfcBEDGWZ6YTtxKq1A0qM/601P+GkfXOyCMliDWq0kVH4n5N4oubNNMM9VsWQ92v/wLpldntKpFsu+vYRwTPuX0C6Mg6g0WbpsOKK8FmaOe00BdIqVz8razqHW5MVl6hAg7xK50r25E2qks+nJsev+IygPpJjTgcUmEMNv2Auqsy6WfQzwC5s3zqtF5Z4G38H+ROtn2q9hwMQNi5NVVXS22cROkE0BTIvPcEbF51O0sCbOvcY2me1AxeceHsPDOY2f7nfwbil47+3zocfrXx6fCjTmmKVa2x6G8XysoKiCxJ6kGAEmp8= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 7148e3f1-88e4-4bee-84a8-08d6d3b27a92 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 May 2019 12:41:23.1956 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 70e1fb47-1155-421d-87fc-2e58f638b6e0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR1801MB1876 X-OriginatorOrg: marvell.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-05-08_07:, , signatures=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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2019 12:41:30 -0000 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, 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 > > > > > + > > > > > +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 the 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 are 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 > > > 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. >=20 > > Regardless of whatever reason, if any time app gets nb_enqd < actually > > passed, then app should check status of nb_enqd + 1th op > [Fiona]. No, that's exactly what I was proposing to avoid. >=20 > > to find exact cause of failure and then either attempt re-enqueue Or > > correct op preparation or take any other appropriate action. > [Fiona] I was proposing to constrain PMDs to only return a subset of erro= rs > on the enqueue, so apps could be optimised. > But if you think it's not possible for PMDs to comply with it, then yes, = apps > 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= almost > any status can be returned anywhere. >=20 [Shally] Okay. I seem to understand it now.=20 Purpose seem reasonable just a simpler rephrase would help. It will be easier for me to further feedback on 1st v2 patch sent. So will = send it another email. >=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 > > just probably has to reset everything. For such kind of case, it might > > not be possible for PMD design to even push it into completion queue > > for an app to dequeue . I would suggest add another status code type > > which reflect permanent error condition i.e. irrecoverable error code > > which tells an app to perform PMD qp reset/re-init to recover and simpl= ify > 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 th= e > catch-all when some other specific status isn't appropriate. If you think > there's a need for another specific status then best send an API patch > proposing it. This patch is only documenting the existing set. [Shally] Sorry, I missed. STATUS_NOT_PROCESSED can be indication of queue_f= ull.=20 STATUS_ERROR on dequeue =3D any catch-all error case STATUS_ERROR on enqueue =3D any irrecoverable error on op. app should not a= ttempt same op or may be reset queue pair or PMD. Is this interpretation correct? 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 83666A0096 for ; Wed, 8 May 2019 14:41:34 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 27EC1378B; Wed, 8 May 2019 14:41:32 +0200 (CEST) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) by dpdk.org (Postfix) with ESMTP id 7A07C2BD5; Wed, 8 May 2019 14:41:30 +0200 (CEST) Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x48CTrSb007788; Wed, 8 May 2019 05:41:29 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marvell.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=pfpt0818; bh=62zHiBX/XluXyx7nxafaDrnR/apHCS5JvMLztunnOOA=; b=i+XkXqKJjAdWKrNx7fMsBzJ2oGh6DJIJkvy70mevU4SrEk+Eom7Z8SRaIsfOjx/gZ6+s ftPPoZOPN9NsMHuYUHO9P6Apu5V0p6z+d937oXfbI6kM8/ghPvut1TXbViUn/srHYXao QtqurNuLqU8ACF1/h9Wke0EIGyRRtOjHLtMfITSlganTGUF5mPdi8kQQrV4lOgrjmUG5 3CPHXyb01c5bWrv6RqpCDrykixMPwrM8v51u2sa4XTsPEN5iM7XRWSJsRJCkxZRq6Tz5 lzYx5qPv+3sNZkNNdwDpnTnEB1atQwpk6TLdxlctGRnvi4Kek6Z9KP6BzXahzYV6qVPM Lg== Received: from sc-exch03.marvell.com ([199.233.58.183]) by mx0b-0016f401.pphosted.com with ESMTP id 2sbxw0r3dc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 08 May 2019 05:41:29 -0700 Received: from SC-EXCH04.marvell.com (10.93.176.84) by SC-EXCH03.marvell.com (10.93.176.83) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Wed, 8 May 2019 05:41:28 -0700 Received: from NAM04-SN1-obe.outbound.protection.outlook.com (104.47.44.54) by SC-EXCH04.marvell.com (10.93.176.84) with Microsoft SMTP Server (TLS) id 15.0.1367.3 via Frontend Transport; Wed, 8 May 2019 05:41:27 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marvell.onmicrosoft.com; s=selector1-marvell-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=62zHiBX/XluXyx7nxafaDrnR/apHCS5JvMLztunnOOA=; b=vwK25k+pKkr21pXzhzTEExaKTd6YIKm6hOgm6ThqgNHsRfUWUSPspt2QnkPTPRxvETwt00VfaBPQtXQhP5exVwnvdjVv7/Fws8HRaGLLFnnVZEofiy0WCETNqnSzOoJiWZNJDYTosL9TRLxNOFbXd70aOvPWHKEHnxESGbYuvjc= Received: from BN6PR1801MB2052.namprd18.prod.outlook.com (10.161.157.11) by BN6PR1801MB1876.namprd18.prod.outlook.com (10.161.154.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1856.10; Wed, 8 May 2019 12:41:23 +0000 Received: from BN6PR1801MB2052.namprd18.prod.outlook.com ([fe80::99fe:90b9:ca17:a552]) by BN6PR1801MB2052.namprd18.prod.outlook.com ([fe80::99fe:90b9:ca17:a552%6]) with mapi id 15.20.1856.012; Wed, 8 May 2019 12:41:23 +0000 From: Shally Verma To: "Trahe, Fiona" , "dev@dpdk.org" CC: "akhil.goyal@nxp.com" , Ashish Gupta , "Daly, Lee" , Sunila Sahu , "stable@dpdk.org" Thread-Topic: [PATCH v2] doc/compress: clarify error handling on data-plane Thread-Index: AQHU7uRcY1b0dFOFhkSSkiDYaczK7aZB3cywgBMpTgCACwagIIAAGJyAgAEwVcA= Date: Wed, 8 May 2019 12:41:23 +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> In-Reply-To: <348A99DA5F5B7549AA880327E580B435897553D3@IRSMSX101.ger.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [115.113.156.2] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7148e3f1-88e4-4bee-84a8-08d6d3b27a92 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(7168020)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:BN6PR1801MB1876; x-ms-traffictypediagnostic: BN6PR1801MB1876: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0031A0FFAF x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(376002)(39860400002)(346002)(366004)(136003)(199004)(189003)(13464003)(7696005)(76176011)(86362001)(2501003)(446003)(11346002)(476003)(66446008)(64756008)(73956011)(66946007)(76116006)(55016002)(6436002)(68736007)(52536014)(229853002)(486006)(6246003)(66476007)(53936002)(81156014)(66556008)(81166006)(8676002)(2906002)(6116002)(3846002)(9686003)(186003)(25786009)(6506007)(53546011)(4326008)(55236004)(8936002)(26005)(33656002)(102836004)(478600001)(66066001)(14454004)(71190400001)(71200400001)(7736002)(74316002)(305945005)(5660300002)(110136005)(54906003)(316002)(99286004)(256004)(14444005); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR1801MB1876; H:BN6PR1801MB2052.namprd18.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: marvell.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: VbpPyhmyB5kYg5grM84yf/tPDsbkGdh5zRSJTpGLnbJ4iaXMPnxEBwB6sQbVRUc3iIZThDUzd+jDICkyinoWxJIzSOf+/2f3p3SRfE189jH2jhmjEDVdysanfcBEDGWZ6YTtxKq1A0qM/601P+GkfXOyCMliDWq0kVH4n5N4oubNNMM9VsWQ92v/wLpldntKpFsu+vYRwTPuX0C6Mg6g0WbpsOKK8FmaOe00BdIqVz8razqHW5MVl6hAg7xK50r25E2qks+nJsev+IygPpJjTgcUmEMNv2Auqsy6WfQzwC5s3zqtF5Z4G38H+ROtn2q9hwMQNi5NVVXS22cROkE0BTIvPcEbF51O0sCbOvcY2me1AxeceHsPDOY2f7nfwbil47+3zocfrXx6fCjTmmKVa2x6G8XysoKiCxJ6kGAEmp8= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 7148e3f1-88e4-4bee-84a8-08d6d3b27a92 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 May 2019 12:41:23.1956 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 70e1fb47-1155-421d-87fc-2e58f638b6e0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR1801MB1876 X-OriginatorOrg: marvell.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-05-08_07:, , signatures=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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Message-ID: <20190508124123.ZP2XYZF5Fu7jfrCVBH0WY3HisTKP7Z6lZ1_Fc9wsbC0@z> 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, 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 > > > > > + > > > > > +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 the 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 are 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 > > > 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. >=20 > > Regardless of whatever reason, if any time app gets nb_enqd < actually > > passed, then app should check status of nb_enqd + 1th op > [Fiona]. No, that's exactly what I was proposing to avoid. >=20 > > to find exact cause of failure and then either attempt re-enqueue Or > > correct op preparation or take any other appropriate action. > [Fiona] I was proposing to constrain PMDs to only return a subset of erro= rs > on the enqueue, so apps could be optimised. > But if you think it's not possible for PMDs to comply with it, then yes, = apps > 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= almost > any status can be returned anywhere. >=20 [Shally] Okay. I seem to understand it now.=20 Purpose seem reasonable just a simpler rephrase would help. It will be easier for me to further feedback on 1st v2 patch sent. So will = send it another email. >=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 > > just probably has to reset everything. For such kind of case, it might > > not be possible for PMD design to even push it into completion queue > > for an app to dequeue . I would suggest add another status code type > > which reflect permanent error condition i.e. irrecoverable error code > > which tells an app to perform PMD qp reset/re-init to recover and simpl= ify > 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 th= e > catch-all when some other specific status isn't appropriate. If you think > there's a need for another specific status then best send an API patch > proposing it. This patch is only documenting the existing set. [Shally] Sorry, I missed. STATUS_NOT_PROCESSED can be indication of queue_f= ull.=20 STATUS_ERROR on dequeue =3D any catch-all error case STATUS_ERROR on enqueue =3D any irrecoverable error on op. app should not a= ttempt same op or may be reset queue pair or PMD. Is this interpretation correct?