+The Turbo decode structure includes the ``input``, ``hard_output`` and
+optionally the ``soft_output`` mbuf data pointers.
+
+.. csv-table:: **struct rte_bbdev_op_turbo_dec** parameters
+ :header: "Parameter", "Description"
+ :widths: 10, 30
+
+ "input","virtual circular buffer, wk, size 3*Kpi for each CB"
+ "hard output","hard decisions buffer, decoded output, size K for each CB"
+ "soft output","soft LLR output buffer (optional)"
+ "op_flags","bitmask of all active operation capabilities"
+ "rv_index","redundancy version index [0..3]"
+ "iter_max","maximum number of iterations to perform in decode all CBs"
+ "iter_min","minimum number of iterations to perform in decoding all CBs"
+ "iter_count","number of iterations to performed in decoding all CBs"
+ "ext_scale","scale factor on extrinsic info (5 bits)"
+ "num_maps","number of MAP engines to use in decode"
+ "code_block_mode","code block or transport block mode"
+ "cb_params", "code block specific parameters (code block mode only)"
+ "tb_params", "transport block specific parameters (transport block mode only)"
+
+Similarly, the decode interface works on both the code block (CB) and the
+transport block (TB). An operation executes in "CB-mode" when the CB is
+standalone. While "TB-mode" executes when an operation performs on one or
+multiple CBs that belong to a TB. Therefore, a given data can be standalone CB,
+full-size TB or partial TB. Partial TB means that only a subset of CBs belonging
+to a bigger TB are being enqueued.
+
+ **NOTE:** It is assumed that all enqueued ops in one ``rte_bbdev_enqueue_dec_ops()``
+ call belong to one mode, either CB-mode or TB-mode.
+
+
+The CB parameter ``k`` is the size of the decoded CB (this maps to K as described in
+3GPP TS 36.212 section 5.1.2), this size is inclusive of CRC24A/B.
+The ``length`` is inclusive of CRC24A/B and equals to ``k`` in this case.
+
+The input encoded CB data is the Virtual Circular Buffer data stream, wk, with
+the null padding included as described in 3GPP TS 36.212 section 5.1.4.1.2 and
+shown in 3GPP TS 36.212 section 5.1.4.1 Figure 5.1.4-1.
+The size of the virtual circular buffer is 3*Kpi, where Kpi is the 32 byte
+aligned value of K, as specified in 3GPP TS 36.212 section 5.1.4.1.1.
+
+Each byte in the input circular buffer is the LLR value of each bit of the
+original CB.
+
+``hard_output`` is a mandatory capability that all BBDEV PMDs support. This is
+the decoded CBs of K sizes (CRC24A/B is the last 24-bit in each decoded CB).
+Soft output is an optional capability for BBDEV PMDs. Setting flag
+``RTE_BBDEV_TURBO_DEC_TB_CRC_24B_KEEP`` in ``op_flags`` directs BBDEV to retain
+CRC24B at the end of each CB. This might be useful for the application in debug
+mode.
+An LLR rate matched output is computed in the ``soft_output`` buffer structure
+for the given CB parameter ``e`` size (this maps to E described in
+3GPP TS 36.212 section 5.1.4.1.2). The output mbuf buffer size needs to be big
+enough to hold the encoded buffer of size ``e``.
+
+The first CB Virtual Circular Buffer (VCB) index is given by ``r`` but the
+number of the remaining CB VCBs is calculated automatically by BBDEV before
+passing down to the driver.
+
+The number of remaining CB VCBs should not be confused with ``c``. ``c`` is the
+total number of CBs that composes the whole TB (this maps to C as
+described in 3GPP TS 36.212 section 5.1.2).
+
+The ``length`` is total size of the CBs inclusive of any CRC24A and CRC24B in
+case they were appended by the application.
+
+The case when one CB belongs to TB and is being enqueued individually to BBDEV,
+this case is considered as a special case of partial TB where its number of CBs
+is 1. Therefore, it requires to get processed in TB-mode.
+
+The output mbuf data structure is expected to be allocated by the application
+with enough room for the output data.
+
+The figure below visualizes the decoding of CBs using BBDEV interface in
+TB-mode. CB-mode is a reduced version, where only one CB exists:
+
+.. _figure_turbo_tb_decode:
+
+.. figure:: img/turbo_tb_decode.*
+
+ Turbo decoding of Code Blocks in mbuf structure
+
+BBDEV LDPC Encode Operation
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The operation flags that can be set for each LDPC encode operation are
+given below.
+
+ **NOTE:** The actual operation flags that may be used with a specific
+ BBDEV PMD are dependent on the driver capabilities as reported via
+ ``rte_bbdev_info_get()``, and may be a subset of those below.
+
++--------------------------------------------------------------------+
+|Description of LDPC encode capability flags |
++====================================================================+
+|RTE_BBDEV_LDPC_INTERLEAVER_BYPASS |
+| Set to bypass bit-level interleaver on output stream |
++--------------------------------------------------------------------+
+|RTE_BBDEV_LDPC_RATE_MATCH |
+| Set to enabling the RATE_MATCHING processing |
++--------------------------------------------------------------------+
+|RTE_BBDEV_LDPC_CRC_24A_ATTACH |
+| Set to attach transport block CRC-24A |
++--------------------------------------------------------------------+
+|RTE_BBDEV_LDPC_CRC_24B_ATTACH |
+| Set to attach code block CRC-24B |
++--------------------------------------------------------------------+
+|RTE_BBDEV_LDPC_CRC_16_ATTACH |
+| Set to attach code block CRC-16 |
++--------------------------------------------------------------------+
+|RTE_BBDEV_LDPC_ENC_INTERRUPTS |
+| Set if a device supports encoder dequeue interrupts |
++--------------------------------------------------------------------+
+|RTE_BBDEV_LDPC_ENC_SCATTER_GATHER |
+| Set if a device supports scatter-gather functionality |
++--------------------------------------------------------------------+
+|RTE_BBDEV_LDPC_ENC_CONCATENATION |
+| Set if a device supports concatenation of non byte aligned output |
++--------------------------------------------------------------------+
+
+The structure passed for each LDPC encode operation is given below,
+with the operation flags forming a bitmask in the ``op_flags`` field.
+
+.. code-block:: c
+
+ struct rte_bbdev_op_ldpc_enc {
+
+ struct rte_bbdev_op_data input;
+ struct rte_bbdev_op_data output;
+
+ uint32_t op_flags;
+ uint8_t rv_index;
+ uint8_t basegraph;
+ uint16_t z_c;
+ uint16_t n_cb;
+ uint8_t q_m;
+ uint16_t n_filler;
+ uint8_t code_block_mode;
+ union {
+ struct rte_bbdev_op_enc_ldpc_cb_params cb_params;
+ struct rte_bbdev_op_enc_ldpc_tb_params tb_params;
+ };
+ };
+
+The LDPC encode parameters are set out in the table below.
+
++----------------+--------------------------------------------------------------------+
+|Parameter |Description |
++================+====================================================================+
+|input |input CB or TB data |
++----------------+--------------------------------------------------------------------+
+|output |rate matched CB or TB output buffer |
++----------------+--------------------------------------------------------------------+
+|op_flags |bitmask of all active operation capabilities |
++----------------+--------------------------------------------------------------------+
+|rv_index |redundancy version index [0..3] |
++----------------+--------------------------------------------------------------------+
+|basegraph |Basegraph 1 or 2 |
++----------------+--------------------------------------------------------------------+
+|z_c |Zc, LDPC lifting size |
++----------------+--------------------------------------------------------------------+
+|n_cb |Ncb, length of the circular buffer in bits. |
++----------------+--------------------------------------------------------------------+
+|q_m |Qm, modulation order {2,4,6,8,10} |
++----------------+--------------------------------------------------------------------+
+|n_filler |number of filler bits |
++----------------+--------------------------------------------------------------------+
+|code_block_mode |code block or transport block mode |
++----------------+--------------------------------------------------------------------+
+|op_flags |bitmask of all active operation capabilities |
++----------------+--------------------------------------------------------------------+
+|**cb_params** |code block specific parameters (code block mode only) |
++----------------+------------+-------------------------------------------------------+
+| |e |E, length of the rate matched output sequence in bits |
++----------------+------------+-------------------------------------------------------+
+|**tb_params** | transport block specific parameters (transport block mode only) |
++----------------+------------+-------------------------------------------------------+
+| |c |number of CBs in the TB or partial TB |
++----------------+------------+-------------------------------------------------------+
+| |r |index of the first CB in the inbound mbuf data |
++----------------+------------+-------------------------------------------------------+
+| |c_ab |number of CBs that use Ea before switching to Eb |
++----------------+------------+-------------------------------------------------------+
+| |ea |Ea, length of the RM output sequence in bits, r < cab |
++----------------+------------+-------------------------------------------------------+
+| |eb |Eb, length of the RM output sequence in bits, r >= cab |
++----------------+------------+-------------------------------------------------------+
+
+The mbuf input ``input`` is mandatory for all BBDEV PMDs and is the
+incoming code block or transport block data.
+
+The mbuf output ``output`` is mandatory and is the encoded CB(s). In
+CB-mode ut contains the encoded CB of size ``e`` (E in 3GPP TS 38.212
+section 6.2.5). In TB-mode it contains multiple contiguous encoded CBs
+of size ``ea`` or ``eb``.
+The ``output`` buffer is allocated by the application with enough room
+for the output data.
+
+The encode interface works on both a code block (CB) and a transport
+block (TB) basis.
+
+ **NOTE:** All enqueued ops in one ``rte_bbdev_enqueue_enc_ops()``
+ call belong to one mode, either CB-mode or TB-mode.
+
+The valid modes of operation are:
+
+* CB-mode: one CB (attach CRC24B if required)
+* CB-mode: one CB making up one TB (attach CRC24A if required)
+* TB-mode: one or more CB of a partial TB (attach CRC24B(s) if required)
+* TB-mode: one or more CB of a complete TB (attach CRC24AB(s) if required)
+
+In CB-mode if ``RTE_BBDEV_LDPC_CRC_24A_ATTACH`` is set then CRC24A
+is appended to the CB. If ``RTE_BBDEV_LDPC_CRC_24A_ATTACH`` is not
+set the application is responsible for calculating and appending CRC24A
+before calling BBDEV. The input data mbuf ``length`` is inclusive of
+CRC24A/B where present and is equal to the code block size ``K``.
+
+In TB-mode, CRC24A is assumed to be pre-calculated and appended to the
+inbound TB data buffer, unless the ``RTE_BBDEV_LDPC_CRC_24A_ATTACH``
+flag is set when it is the responsibility of BBDEV. The input data
+mbuf ``length`` is total size of the CBs inclusive of any CRC24A and
+CRC24B in the case they were appended by the application.
+
+Not all BBDEV PMDs may be capable of CRC24A/B calculation. Flags
+``RTE_BBDEV_LDPC_CRC_24A_ATTACH`` and ``RTE_BBDEV_LDPC_CRC_24B_ATTACH``
+inform the application of the relevant capability. These flags can be set
+in the ``op_flags`` parameter to indicate BBDEV to calculate and append
+CRC24A to CB before going forward with LDPC encoding.
+
+The difference between the partial and full-size TB is that BBDEV needs
+the index of the first CB in this group and the number of CBs in the group.
+The first CB index is given by ``r`` but the number of the CBs is
+calculated by BBDEV before signalling to the driver.
+
+The number of CBs in the group should not be confused with ``c``, the
+total number of CBs in the full TB (``C`` as per 3GPP TS 38.212 section 5.2.2)
+
+Figure :numref:`figure_turbo_tb_encode` above
+showing the Turbo encoding of CBs using BBDEV interface in TB-mode
+is also valid for LDPC encode.
+
+BBDEV LDPC Decode Operation
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The operation flags that can be set for each LDPC decode operation are
+given below.
+
+ **NOTE:** The actual operation flags that may be used with a specific
+ BBDEV PMD are dependent on the driver capabilities as reported via
+ ``rte_bbdev_info_get()``, and may be a subset of those below.
+
++--------------------------------------------------------------------+
+|Description of LDPC decode capability flags |
++====================================================================+
+|RTE_BBDEV_LDPC_CRC_TYPE_24A_CHECK |
+| Set for transport block CRC-24A checking |
++--------------------------------------------------------------------+
+|RTE_BBDEV_LDPC_CRC_TYPE_24B_CHECK |
+| Set for code block CRC-24B checking |
++--------------------------------------------------------------------+
+|RTE_BBDEV_LDPC_CRC_TYPE_24B_DROP |
+| Set to drop the last CRC bits decoding output |
++--------------------------------------------------------------------+
+|RTE_BBDEV_LDPC_CRC_TYPE_16_CHECK |
+| Set for code block CRC-16 checking |
++--------------------------------------------------------------------+
+|RTE_BBDEV_LDPC_DEINTERLEAVER_BYPASS |
+| Set for bit-level de-interleaver bypass on input stream |
++--------------------------------------------------------------------+
+|RTE_BBDEV_LDPC_HQ_COMBINE_IN_ENABLE |
+| Set for HARQ combined input stream enable |
++--------------------------------------------------------------------+
+|RTE_BBDEV_LDPC_HQ_COMBINE_OUT_ENABLE |
+| Set for HARQ combined output stream enable |
++--------------------------------------------------------------------+
+|RTE_BBDEV_LDPC_DECODE_BYPASS |
+| Set for LDPC decoder bypass |
+| |
+| RTE_BBDEV_LDPC_HQ_COMBINE_OUT_ENABLE must be set |
++--------------------------------------------------------------------+
+|RTE_BBDEV_LDPC_DECODE_SOFT_OUT |
+| Set for soft-output stream enable |
++--------------------------------------------------------------------+
+|RTE_BBDEV_LDPC_SOFT_OUT_RM_BYPASS |
+| Set for Rate-Matching bypass on soft-out stream |
++--------------------------------------------------------------------+
+|RTE_BBDEV_LDPC_SOFT_OUT_DEINTERLEAVER_BYPASS |
+| Set for bit-level de-interleaver bypass on soft-output stream |
++--------------------------------------------------------------------+
+|RTE_BBDEV_LDPC_ITERATION_STOP_ENABLE |
+| Set for iteration stopping on successful decode condition enable |
+| |
+| Where a successful decode is a successful syndrome check |
++--------------------------------------------------------------------+
+|RTE_BBDEV_LDPC_DEC_INTERRUPTS |
+| Set if a device supports decoder dequeue interrupts |
++--------------------------------------------------------------------+
+|RTE_BBDEV_LDPC_DEC_SCATTER_GATHER |
+| Set if a device supports scatter-gather functionality |
++--------------------------------------------------------------------+
+|RTE_BBDEV_LDPC_HARQ_6BIT_COMPRESSION |
+| Set if a device supports input/output HARQ compression |
+| Data is packed as 6 bits by dropping and saturating the MSBs |
++--------------------------------------------------------------------+
+|RTE_BBDEV_LDPC_LLR_COMPRESSION |
+| Set if a device supports input LLR compression |
+| Data is packed as 6 bits by dropping and saturating the MSBs |
++--------------------------------------------------------------------+
+|RTE_BBDEV_LDPC_INTERNAL_HARQ_MEMORY_IN_ENABLE |
+| Set if a device supports HARQ input to device's internal memory |
++--------------------------------------------------------------------+
+|RTE_BBDEV_LDPC_INTERNAL_HARQ_MEMORY_OUT_ENABLE |
+| Set if a device supports HARQ output to device's internal memory |
++--------------------------------------------------------------------+
+|RTE_BBDEV_LDPC_INTERNAL_HARQ_MEMORY_LOOPBACK |
+| Set if a device supports loopback access to HARQ internal memory |
++--------------------------------------------------------------------+
+
+The structure passed for each LDPC decode operation is given below,
+with the operation flags forming a bitmask in the ``op_flags`` field.
+
+.. code-block:: c
+
+
+ struct rte_bbdev_op_ldpc_dec {
+
+ struct rte_bbdev_op_data input;
+ struct rte_bbdev_op_data hard_output;
+ struct rte_bbdev_op_data soft_output;
+ struct rte_bbdev_op_data harq_combined_input;
+ struct rte_bbdev_op_data harq_combined_output;
+
+ uint32_t op_flags;
+ uint8_t rv_index;
+ uint8_t basegraph;
+ uint16_t z_c;
+ uint16_t n_cb;
+ uint8_t q_m;
+ uint16_t n_filler;
+ uint8_t iter_max;
+ uint8_t iter_count;
+ uint8_t code_block_mode;
+ union {
+ struct rte_bbdev_op_dec_ldpc_cb_params cb_params;
+ struct rte_bbdev_op_dec_ldpc_tb_params tb_params;
+ };
+ };
+
+
+The LDPC decode parameters are set out in the table below.
+
++----------------+--------------------------------------------------------------------+
+|Parameter |Description |
++================+====================================================================+
+|input |input CB or TB data |
++----------------+--------------------------------------------------------------------+
+|hard_output |hard decisions buffer, decoded output |
++----------------+--------------------------------------------------------------------+
+|soft_output |soft LLR output buffer (optional) |
++----------------+--------------------------------------------------------------------+
+|harq_comb_input |HARQ combined input buffer (optional) |
++----------------+--------------------------------------------------------------------+
+|harq_comb_output|HARQ combined output buffer (optional) |
++----------------+--------------------------------------------------------------------+
+|op_flags |bitmask of all active operation capabilities |
++----------------+--------------------------------------------------------------------+
+|rv_index |redundancy version index [0..3] |
++----------------+--------------------------------------------------------------------+
+|basegraph |Basegraph 1 or 2 |
++----------------+--------------------------------------------------------------------+
+|z_c |Zc, LDPC lifting size |
++----------------+--------------------------------------------------------------------+
+|n_cb |Ncb, length of the circular buffer in bits. |
++----------------+--------------------------------------------------------------------+
+|q_m |Qm, modulation order {1,2,4,6,8} from pi/2-BPSK to 256QAM |
++----------------+--------------------------------------------------------------------+
+|n_filler |number of filler bits |
++----------------+--------------------------------------------------------------------+
+|iter_max |maximum number of iterations to perform in decode all CBs |
++----------------+--------------------------------------------------------------------+
+|iter_count |number of iterations performed in decoding all CBs |
++----------------+--------------------------------------------------------------------+
+|code_block_mode |code block or transport block mode |
++----------------+--------------------------------------------------------------------+
+|op_flags |bitmask of all active operation capabilities |
++----------------+--------------------------------------------------------------------+
+|**cb_params** |code block specific parameters (code block mode only) |
++----------------+------------+-------------------------------------------------------+
+| |e |E, length of the rate matched output sequence in bits |
++----------------+------------+-------------------------------------------------------+
+|**tb_params** | transport block specific parameters (transport block mode only) |
++----------------+------------+-------------------------------------------------------+
+| |c |number of CBs in the TB or partial TB |
++----------------+------------+-------------------------------------------------------+
+| |r |index of the first CB in the inbound mbuf data |
++----------------+------------+-------------------------------------------------------+
+| |c_ab |number of CBs that use Ea before switching to Eb |
++----------------+------------+-------------------------------------------------------+
+| |ea |Ea, length of the RM output sequence in bits, r < cab |
++----------------+------------+-------------------------------------------------------+
+| |eb |Eb, length of the RM output sequence in bits r >= cab |
++----------------+------------+-------------------------------------------------------+
+
+The mbuf input ``input`` encoded CB data is mandatory for all BBDEV PMDs
+and is the Virtual Circular Buffer data stream with null padding.
+Each byte in the input circular buffer is the LLR value of each bit of
+the original CB.
+
+The mbuf output ``hard_output`` is mandatory and is the decoded CBs size
+K (CRC24A/B is the last 24-bit in each decoded CB).
+
+The mbuf output ``soft_output`` is optional and is an LLR rate matched
+output of size ``e`` (this is ``E`` as per 3GPP TS 38.212 section 6.2.5).
+
+The mbuf input ``harq_combine_input`` is optional and is a buffer with
+the input to the HARQ combination function of the device. If the
+capability RTE_BBDEV_LDPC_INTERNAL_HARQ_MEMORY_IN_ENABLE is set
+then the HARQ is stored in memory internal to the device and not visible
+to BBDEV.
+
+The mbuf output ``harq_combine_output`` is optional and is a buffer for
+the output of the HARQ combination function of the device. If the
+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 no 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 be 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.
+
+As with the LDPC encode, the decode interface works on both a code block
+(CB) and a transport block (TB) basis.
+
+ **NOTE:** All enqueued ops in one ``rte_bbdev_enqueue_dec_ops()``
+ call belong to one mode, either CB-mode or TB-mode.
+
+The valid modes of operation are:
+
+* CB-mode: one CB (check CRC24B if required)
+* CB-mode: one CB making up one TB (check CRC24A if required)
+* TB-mode: one or more CB making up a partial TB (check CRC24B(s) if required)
+* TB-mode: one or more CB making up a complete TB (check CRC24B(s) if required)
+
+The mbuf ``length`` is inclusive of CRC24A/B where present and is equal
+the code block size ``K``.
+
+The first CB Virtual Circular Buffer (VCB) index is given by ``r`` but the
+number of the remaining CB VCBs is calculated automatically by BBDEV
+and passed down to the driver.
+
+The number of remaining CB VCBs should not be confused with ``c``, the
+total number of CBs in the full TB (``C`` as per 3GPP TS 38.212 section 5.2.2)