From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <dev-bounces@dpdk.org> Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 691DCA0C56; Wed, 8 Sep 2021 03:16:23 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 7F9474114E; Wed, 8 Sep 2021 03:16:06 +0200 (CEST) Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by mails.dpdk.org (Postfix) with ESMTP id 751A140DF6 for <dev@dpdk.org>; Wed, 8 Sep 2021 03:16:01 +0200 (CEST) X-IronPort-AV: E=McAfee;i="6200,9189,10100"; a="281368124" X-IronPort-AV: E=Sophos;i="5.85,276,1624345200"; d="scan'208";a="281368124" Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Sep 2021 18:16:00 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.85,276,1624345200"; d="scan'208";a="693000859" Received: from unknown (HELO icx-npg-scs1-cp1.localdomain) ([10.233.180.245]) by fmsmga006.fm.intel.com with ESMTP; 07 Sep 2021 18:15:59 -0700 From: Nicolas Chautru <nicolas.chautru@intel.com> To: dev@dpdk.org, gakhil@marvell.com Cc: thomas@monjalon.net, trix@redhat.com, hemant.agrawal@nxp.com, mingshan.zhang@intel.com, arun.joshi@intel.com, Nicolas Chautru <nicolas.chautru@intel.com> Date: Tue, 7 Sep 2021 18:15:40 -0700 Message-Id: <1631063741-28631-6-git-send-email-nicolas.chautru@intel.com> X-Mailer: git-send-email 1.8.3.1 In-Reply-To: <1631063741-28631-1-git-send-email-nicolas.chautru@intel.com> References: <1631063741-28631-1-git-send-email-nicolas.chautru@intel.com> Subject: [dpdk-dev] [PATCH v3 5/6] doc: clarification of usage of HARQ in bbdev doc X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 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> New paragraph detailing typical VRAN usecase and mapping to bbdev API usage. Signed-off-by: Nicolas Chautru <nicolas.chautru@intel.com> --- doc/guides/prog_guide/bbdev.rst | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+) diff --git a/doc/guides/prog_guide/bbdev.rst b/doc/guides/prog_guide/bbdev.rst index 8bd7cba..f39b62f 100644 --- a/doc/guides/prog_guide/bbdev.rst +++ b/doc/guides/prog_guide/bbdev.rst @@ -1054,6 +1054,29 @@ capability RTE_BBDEV_LDPC_INTERNAL_HARQ_MEMORY_OUT_ENABLE is set then the HARQ is stored in memory internal to the device and not visible to BBDEV. +.. note:: + More explicitly for a typical usage of HARQ retransmission in a VRAN + application using a HW PMD, there will be 2 cases. + + For 1st transmission, only the HARQ output is enabled : + + - the harq_combined_output.offset is provided to a given address. ie. typically an integer index * 32K, where the index is tracked by the application based on code block index for a given UE and HARQ process. + + - the related operation flag would notably include RTE_BBDEV_LDPC_HQ_COMBINE_OUT_ENABLE and RTE_BBDEV_LDPC_HARQ_6BIT_COMPRESSION. + + - note that not explicit flush or reset of the memory is required. + + For 2nd transmission, an input is also required to benefit from HARQ combination gain: + + - the changes mentioned above are the same (note that rvIndex may be adjusted). + + - the operation flag would additionally include the LDPC_HQ_COMBINE_IN_ENABLE flag. + + - the harq_combined_input.offset must set to the address of the related code block (ie. same as the harq_combine_output index above for the same code block, HARQ process, UE). + + - the harq_combined_input.length must be set to the length which was provided back in the related harq_combined_output.length when it has processed and dequeued (previous HARQ iteration). + + The output mbuf data structures are expected to be allocated by the application with enough room for the output data. -- 1.8.3.1