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.chau...@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.coque...@redhat.com>
Thanks,
Maxime
desc = acc_desc(q, total_enqueued_cbs);
vrb_fcw_td_fill(op, &desc->req.fcw_td);
