From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by dpdk.org (Postfix) with ESMTP id 8FCE15B12; Tue, 14 May 2019 17:29:38 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga105.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 May 2019 08:29:37 -0700 X-ExtLoop1: 1 Received: from irsmsx105.ger.corp.intel.com ([163.33.3.28]) by FMSMGA003.fm.intel.com with ESMTP; 14 May 2019 08:29:35 -0700 Received: from irsmsx101.ger.corp.intel.com ([169.254.1.10]) by irsmsx105.ger.corp.intel.com ([169.254.7.155]) with mapi id 14.03.0415.000; Tue, 14 May 2019 16:29:35 +0100 From: "Trahe, Fiona" To: Shally Verma , "dev@dpdk.org" CC: "akhil.goyal@nxp.com" , Ashish Gupta , "Daly, Lee" , Sunila Sahu , "stable@dpdk.org" , "Trahe, Fiona" Thread-Topic: [PATCH v2] doc/compress: clarify error handling on data-plane Thread-Index: AQHU7uRoniPOIsNkTEyu55+FfYvFQqZiueMAgAg3CkA= Date: Tue, 14 May 2019 15:29:34 +0000 Message-ID: <348A99DA5F5B7549AA880327E580B43589767E7F@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> In-Reply-To: Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiYzU4MTY4NTktNzE5Ny00MDQxLTllY2QtYTcwNjYxNWQ3MjcxIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiR2VGVURmdnZIYmpOUVNYZGJYVlwvNU04ck83U2lUak0rcVVzTUEwbVBtSmEzdGVPM0plYWJuczBQRFJLbXQ2ZlYifQ== x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.0.600.7 dlp-reaction: no-action x-originating-ip: [163.33.239.181] Content-Type: text/plain; charset="us-ascii" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 May 2019 15:29:39 -0000 Hi Shally, Although we're close to agreement on this, I'm reconsidering. I think the difficulty we've had finding the best wording highlights the co= nfusion an app developer will have in figuring out how to handle errors on enqueue.=20 So I'm proposing to drop this - which was intended to allow some optimisati= on - and instead propose a more robust approach, i.e. add this to the doc: Operation status after enqueue / dequeue ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Some of the above values may arise in the op after an ``rte_compressdev_enqueue_burst()``. If number ops enqueued < number op= s requested then the app should check the op.status of nb_enqd+1. If status is RTE_COMP_OP_STATUS_NOT_PROCESSED, it likely indicates a full-queue case= for a hardware device and a retry after dequeuing some ops is likely to be successful. If the= op holds any other status, e.g. RTE_COMP_OP_STATUS_INVALID_ARGS, a retry with the same op is unlikely t= o be successful. =20 I know this adds an extra fork, so is less optimal, but once there's even a= small chance that an error may occur on the enqueue, a robust application = should probably check anyway. What do you think? If you agree, I'll send the doc update and a perf tool update to add the st= atus check on the enqueue. Btw - this doesn't stop PMDs from minimising those cases, just means they'r= e not bound by the API to do it. Fiona=20 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 B095CA00E6 for ; Tue, 14 May 2019 17:29:40 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 06C545F2C; Tue, 14 May 2019 17:29:40 +0200 (CEST) Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by dpdk.org (Postfix) with ESMTP id 8FCE15B12; Tue, 14 May 2019 17:29:38 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga105.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 May 2019 08:29:37 -0700 X-ExtLoop1: 1 Received: from irsmsx105.ger.corp.intel.com ([163.33.3.28]) by FMSMGA003.fm.intel.com with ESMTP; 14 May 2019 08:29:35 -0700 Received: from irsmsx101.ger.corp.intel.com ([169.254.1.10]) by irsmsx105.ger.corp.intel.com ([169.254.7.155]) with mapi id 14.03.0415.000; Tue, 14 May 2019 16:29:35 +0100 From: "Trahe, Fiona" To: Shally Verma , "dev@dpdk.org" CC: "akhil.goyal@nxp.com" , Ashish Gupta , "Daly, Lee" , Sunila Sahu , "stable@dpdk.org" , "Trahe, Fiona" Thread-Topic: [PATCH v2] doc/compress: clarify error handling on data-plane Thread-Index: AQHU7uRoniPOIsNkTEyu55+FfYvFQqZiueMAgAg3CkA= Date: Tue, 14 May 2019 15:29:34 +0000 Message-ID: <348A99DA5F5B7549AA880327E580B43589767E7F@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> In-Reply-To: Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiYzU4MTY4NTktNzE5Ny00MDQxLTllY2QtYTcwNjYxNWQ3MjcxIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiR2VGVURmdnZIYmpOUVNYZGJYVlwvNU04ck83U2lUak0rcVVzTUEwbVBtSmEzdGVPM0plYWJuczBQRFJLbXQ2ZlYifQ== x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.0.600.7 dlp-reaction: no-action x-originating-ip: [163.33.239.181] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Message-ID: <20190514152934.Ko_mwgf6fhcNsC3aWSIdogBQ_qzGqq8wu6oY9tjrDfc@z> Hi Shally, Although we're close to agreement on this, I'm reconsidering. I think the difficulty we've had finding the best wording highlights the co= nfusion an app developer will have in figuring out how to handle errors on enqueue.=20 So I'm proposing to drop this - which was intended to allow some optimisati= on - and instead propose a more robust approach, i.e. add this to the doc: Operation status after enqueue / dequeue ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Some of the above values may arise in the op after an ``rte_compressdev_enqueue_burst()``. If number ops enqueued < number op= s requested then the app should check the op.status of nb_enqd+1. If status is RTE_COMP_OP_STATUS_NOT_PROCESSED, it likely indicates a full-queue case= for a hardware device and a retry after dequeuing some ops is likely to be successful. If the= op holds any other status, e.g. RTE_COMP_OP_STATUS_INVALID_ARGS, a retry with the same op is unlikely t= o be successful. =20 I know this adds an extra fork, so is less optimal, but once there's even a= small chance that an error may occur on the enqueue, a robust application = should probably check anyway. What do you think? If you agree, I'll send the doc update and a perf tool update to add the st= atus check on the enqueue. Btw - this doesn't stop PMDs from minimising those cases, just means they'r= e not bound by the API to do it. Fiona=20