Re: [PATCH v3 03/12] baseband/acc: remove the 4G SO capability for VRB1

[Maxime Coquelin <maxime.coquelin@redhat.com>]

On 9/29/23 18:35, Nicolas Chautru wrote:
> This removes the specific capability and support of LTE Decoder
> Soft Output option on the VRB1 PMD.
> 
> This is triggered as a vendor decision to defeature the related optional
> capability so that to avoid theoretical risk of race conditions
> impacting the device reliability. That optional APP LLR output is
> not impacting the actual decoder hard output.
> 
> Signed-off-by: Nicolas Chautru <nicolas.chautru@intel.com>
> ---
>   doc/guides/bbdevs/vrb1.rst         |  4 ----
>   drivers/baseband/acc/rte_vrb_pmd.c | 10 ++++++----
>   2 files changed, 6 insertions(+), 8 deletions(-)
> 
> diff --git a/doc/guides/bbdevs/vrb1.rst b/doc/guides/bbdevs/vrb1.rst
> index 9c48d30964..fdefb20651 100644
> --- a/doc/guides/bbdevs/vrb1.rst
> +++ b/doc/guides/bbdevs/vrb1.rst
> @@ -71,11 +71,7 @@ The Intel vRAN Boost v1.0 PMD supports the following bbdev capabilities:
>      - ``RTE_BBDEV_TURBO_EARLY_TERMINATION``: set early termination feature.
>      - ``RTE_BBDEV_TURBO_DEC_SCATTER_GATHER``: supports scatter-gather for input/output data.
>      - ``RTE_BBDEV_TURBO_HALF_ITERATION_EVEN``: set half iteration granularity.
> -   - ``RTE_BBDEV_TURBO_SOFT_OUTPUT``: set the APP LLR soft output.
> -   - ``RTE_BBDEV_TURBO_EQUALIZER``: set the turbo equalizer feature.
> -   - ``RTE_BBDEV_TURBO_SOFT_OUT_SATURATE``: set the soft output saturation.
>      - ``RTE_BBDEV_TURBO_CONTINUE_CRC_MATCH``: set to run an extra odd iteration after CRC match.
> -   - ``RTE_BBDEV_TURBO_NEG_LLR_1_BIT_SOFT_OUT``: set if negative APP LLR output supported.
>      - ``RTE_BBDEV_TURBO_MAP_DEC``: supports flexible parallel MAP engine decoding.
>   
>   * For the FFT operation:
> diff --git a/drivers/baseband/acc/rte_vrb_pmd.c b/drivers/baseband/acc/rte_vrb_pmd.c
> index c5a74bae11..f11882f90e 100644
> --- a/drivers/baseband/acc/rte_vrb_pmd.c
> +++ b/drivers/baseband/acc/rte_vrb_pmd.c
> @@ -1025,15 +1025,11 @@ vrb_dev_info_get(struct rte_bbdev *dev, struct rte_bbdev_driver_info *dev_info)
>   					RTE_BBDEV_TURBO_SUBBLOCK_DEINTERLEAVE |
>   					RTE_BBDEV_TURBO_CRC_TYPE_24B |
>   					RTE_BBDEV_TURBO_DEC_CRC_24B_DROP |
> -					RTE_BBDEV_TURBO_EQUALIZER |
> -					RTE_BBDEV_TURBO_SOFT_OUT_SATURATE |
>   					RTE_BBDEV_TURBO_HALF_ITERATION_EVEN |
>   					RTE_BBDEV_TURBO_CONTINUE_CRC_MATCH |
> -					RTE_BBDEV_TURBO_SOFT_OUTPUT |
>   					RTE_BBDEV_TURBO_EARLY_TERMINATION |
>   					RTE_BBDEV_TURBO_DEC_INTERRUPTS |
>   					RTE_BBDEV_TURBO_NEG_LLR_1_BIT_IN |
> -					RTE_BBDEV_TURBO_NEG_LLR_1_BIT_SOFT_OUT |
>   					RTE_BBDEV_TURBO_MAP_DEC |
>   					RTE_BBDEV_TURBO_DEC_TB_CRC_24B_KEEP |
>   					RTE_BBDEV_TURBO_DEC_SCATTER_GATHER,
> @@ -1982,6 +1978,12 @@ enqueue_dec_one_op_cb(struct acc_queue *q, struct rte_bbdev_dec_op *op,
>   	struct rte_mbuf *input, *h_output_head, *h_output,
>   		*s_output_head, *s_output;
>   
> +	if ((q->d->device_variant == VRB1_VARIANT) &&
> +			(check_bit(op->turbo_dec.op_flags, RTE_BBDEV_TURBO_SOFT_OUTPUT))) {
> +		/* SO not supported for VRB1. */
> +		return -EPERM;
> +	}
> +

A better option would be to have a pointer on the device capabilities in
the acc_device struct, doing so would be more future-proof. Maybe it
could be considered?

But in the mean time, it addresses this specific issue:
Reviewed-by: Maxime Coquelin <maxime.coquelin@redhat.com>

Thanks,
Maxime

>   	desc = acc_desc(q, total_enqueued_cbs);
>   	vrb_fcw_td_fill(op, &desc->req.fcw_td);
>