From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 95813A034F; Mon, 11 Oct 2021 22:29:08 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 2E27741134; Mon, 11 Oct 2021 22:29:08 +0200 (CEST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by mails.dpdk.org (Postfix) with ESMTP id 12DDD4111D for ; Mon, 11 Oct 2021 22:29:07 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id B1F305C017C; Mon, 11 Oct 2021 16:29:06 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Mon, 11 Oct 2021 16:29:06 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=fm2; bh= y509Sv6Lueblw4SUDDM9ZgVPDPYHJXYqKPkvjgqHfLU=; b=dSJJDbCI9jmCOxwK 3xJ+OcAJQSDLgFO8IvYUJhdbzta9CvCsBAMoQMPw1HTYHWU6y7tkiiXavV5XbkS7 HpLHx1fW906tsR9xjoqdNknE6kK3XQFz9Bt07mPu1xvBE0n5xRFKZDQC6ljBrj8s GmK9XrOmb11r3ELxeMIo6Z1n2zcE3JOkOcb+SAjozASilEv9RR9wWonEmK6GbyU7 6JA/BeIckWqMaDnAPjFT63RRJquS59sybdORCuxdQHwQaEoSWYBn8bKObbupBDn3 VfQ8igPjqEZQY/OPiYZtlBZ8Iv9qwizqkxa2emzuyXfbFgFb7M/qH+iqaqXljRyt d7jV8g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=y509Sv6Lueblw4SUDDM9ZgVPDPYHJXYqKPkvjgqHf LU=; b=NpY6DXtWqpOnqljUIAW1wK0S+qsuS4m3G+FVI+khSfw5v73PDaL76xD6o WnN78dtYbcO5944YjqrkFVGE4BxAEwM38O6oLU96ZecxL3PukdfPMkfxA39D22F/ qK0ZNVsbDkB4LuPpSLi06AU+FFiNkhRG6egQPCRle+W5Xi1wy6TvmW0lcWLzBAcC 2vp9HDSVuV3sOo0EeGVcsHpDWSDMuubx7w1z/lrAkCblTdufIQczm3r/k7q/8eoo ztYcQFN1ScfzTKD7gy9FLXbNQEHTkWcC7Tr4ELyK104mkZ1YZvTTKNqbLtFAWyf2 aA7925EANpuz4uksWbB1jp8OGICfg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrvddtiedgudeggecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpedugefgvdefudfftdefgeelgffhueekgfffhfeujedtteeutdej ueeiiedvffegheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 11 Oct 2021 16:29:04 -0400 (EDT) From: Thomas Monjalon To: Nicolas Chautru Cc: dev@dpdk.org, gakhil@marvell.com, hemant.agrawal@nxp.com, mingshan.zhang@intel.com, arun.joshi@intel.com, Tom Rix Date: Mon, 11 Oct 2021 22:29:01 +0200 Message-ID: <2192559.Aoev046PIl@thomas> In-Reply-To: References: <1631063741-28631-1-git-send-email-nicolas.chautru@intel.com> <1631063741-28631-6-git-send-email-nicolas.chautru@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 12/09/2021 14:44, Tom Rix: > On 9/7/21 6:15 PM, Nicolas Chautru wrote: > > New paragraph detailing typical VRAN usecase and mapping > > to bbdev API usage. > > > > Signed-off-by: Nicolas Chautru > > --- > > 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:: blank line missing > > + 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 : no space before ":" > > + > > + - 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. "*no* explicit" > > + > > + 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). "must *be* set" > > + > > + - 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). lines are too long > > + > > + > > Fine. > > Reviewed-by: Tom Rix No, it isn't fine. Fixing some typos and formatting while pulling in main.