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 9064DA00E6 for ; Wed, 15 May 2019 13:16:22 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 465C35F2A; Wed, 15 May 2019 13:16:21 +0200 (CEST) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id 5F7375F25; Wed, 15 May 2019 13:16:19 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga006.jf.intel.com ([10.7.209.51]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 May 2019 04:16:17 -0700 X-ExtLoop1: 1 Received: from sivswdev09.ir.intel.com (HELO localhost.localdomain) ([10.237.217.48]) by orsmga006.jf.intel.com with ESMTP; 15 May 2019 04:16:15 -0700 From: Fiona Trahe To: dev@dpdk.org Cc: fiona.trahe@intel.com, shallyv@marvell.com, ssahu@marvell.com, lee.daly@intel.com, ashishg@marvell.com, akhil.goyal@nxp.com, tomaszx.jozwiak@intel.com, stable@dpdk.org Date: Wed, 15 May 2019 12:16:07 +0100 Message-Id: <1557918967-6869-1-git-send-email-fiona.trahe@intel.com> X-Mailer: git-send-email 1.7.0.7 In-Reply-To: <1554821747-27868-1-git-send-email-fiona.trahe@intel.com> References: <1554821747-27868-1-git-send-email-fiona.trahe@intel.com> Subject: [dpdk-dev] [PATCH v3] 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" Content-Type: text/plain; charset="UTF-8" Message-ID: <20190515111607.6vnM-xlh8Ki7IzvOtgiN9TvIFYroKpSQY1e591qn8ZI@z> Fixed some typos and clarified how errors on ops which fail to get submitted on the enqueue API should be handled. Fixes: a584d3bea902 ("doc: add compressdev library guide") cc: stable@dpdk.org Signed-off-by: Fiona Trahe --- v3 changes: - change proposal so appl must check status of op_enqueued+1 if all ops are not enqueued. v2 changes: - changed "0 or undefined" to just "undefined" as 0 is superfluous. doc/guides/prog_guide/compressdev.rst | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-) diff --git a/doc/guides/prog_guide/compressdev.rst b/doc/guides/prog_guide/compressdev.rst index a06c835a0..bd9bebce6 100644 --- a/doc/guides/prog_guide/compressdev.rst +++ b/doc/guides/prog_guide/compressdev.rst @@ -201,7 +201,7 @@ for stateful processing of ops. Operation Status ~~~~~~~~~~~~~~~~ Each operation carries a status information updated by PMD after it is processed. -following are currently supported status: +Following are currently supported: - RTE_COMP_OP_STATUS_SUCCESS, Operation is successfully completed @@ -227,14 +227,24 @@ following are currently supported status: is not an error case. Output data up to op.produced can be used and next op in the stream should continue on from op.consumed+1. +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 ops 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 to be successful. + + Produced, Consumed And Operation Status ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - If status is RTE_COMP_OP_STATUS_SUCCESS, consumed = amount of data read from input buffer, and produced = amount of data written in destination buffer -- If status is RTE_COMP_OP_STATUS_FAILURE, - consumed = produced = 0 or undefined +- If status is RTE_COMP_OP_STATUS_ERROR, + consumed = produced = undefined - If status is RTE_COMP_OP_STATUS_OUT_OF_SPACE_TERMINATED, consumed = 0 and produced = usually 0, but in decompression cases a PMD may return > 0 -- 2.13.6