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 <nicolas.chau...@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::
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 <t...@redhat.com> No, it isn't fine. Fixing some typos and formatting while pulling in main.
