From: Maxime Coquelin <maxime.coquelin@redhat.com>
To: "Chautru, Nicolas" <nicolas.chautru@intel.com>,
"Vargas, Hernan" <hernan.vargas@intel.com>,
"dev@dpdk.org" <dev@dpdk.org>,
"gakhil@marvell.com" <gakhil@marvell.com>,
"trix@redhat.com" <trix@redhat.com>
Cc: "Zhang, Qi Z" <qi.z.zhang@intel.com>
Subject: Re: [PATCH v7 1/1] baseband/acc100: add detection for deRM corner cases
Date: Thu, 3 Nov 2022 16:07:36 +0100 [thread overview]
Message-ID: <f1eca5c6-15ee-344c-b3b3-73cdd16a60d8@redhat.com> (raw)
In-Reply-To: <BY5PR11MB4451227C79F0FACD298DB40CF8389@BY5PR11MB4451.namprd11.prod.outlook.com>
Hi Nicolas,
On 11/3/22 15:59, Chautru, Nicolas wrote:
> Hi Maxime,
>
>> -----Original Message-----
>> From: Maxime Coquelin <maxime.coquelin@redhat.com>
>> Sent: Thursday, November 3, 2022 7:10 AM
>> To: Vargas, Hernan <hernan.vargas@intel.com>; dev@dpdk.org;
>> gakhil@marvell.com; trix@redhat.com
>> Cc: Chautru, Nicolas <nicolas.chautru@intel.com>; Zhang, Qi Z
>> <qi.z.zhang@intel.com>
>> Subject: Re: [PATCH v7 1/1] baseband/acc100: add detection for deRM corner
>> cases
>>
>>
>>
>> On 11/1/22 05:13, Hernan Vargas wrote:
>>> Add function to detect if de-ratematch pre-processing is recommended
>>> for SW corner cases.
>>> Some specific 5GUL FEC corner cases may cause unintended back pressure
>>> and in some cases a potential stability issue on the ACC100.
>>> The PMD can detect such code block configuration and issue an info
>>> message to the user.
>>>
>>> Signed-off-by: Hernan Vargas <hernan.vargas@intel.com>
>>> ---
>>> drivers/baseband/acc/acc_common.h | 8 ++++
>>> drivers/baseband/acc/rte_acc100_pmd.c | 55
>> +++++++++++++++++++++++++--
>>> 2 files changed, 60 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/baseband/acc/acc_common.h
>>> b/drivers/baseband/acc/acc_common.h
>>> index eae7eab4e9..6213b0b61e 100644
>>> --- a/drivers/baseband/acc/acc_common.h
>>> +++ b/drivers/baseband/acc/acc_common.h
>>> @@ -123,6 +123,14 @@
>>> #define ACC_HARQ_ALIGN_64B 64
>>> #define ACC_MAX_ZC 384
>>>
>>> +/* De-ratematch code rate limitation for recommended operation */
>>> +#define ACC_LIM_03 2 /* 0.03 */ #define ACC_LIM_09 6 /* 0.09 */
>>> +#define ACC_LIM_14 9 /* 0.14 */ #define ACC_LIM_21 14 /* 0.21 */
>>> +#define ACC_LIM_31 20 /* 0.31 */ #define ACC_MAX_E (128 * 1024 - 2)
>>> +
>>> /* Helper macro for logging */
>>> #define rte_acc_log(level, fmt, ...) \
>>> rte_log(RTE_LOG_ ## level, RTE_LOG_NOTICE, fmt "\n", \ diff --git
>>> a/drivers/baseband/acc/rte_acc100_pmd.c
>>> b/drivers/baseband/acc/rte_acc100_pmd.c
>>> index 23bc5d25bb..47609f95b7 100644
>>> --- a/drivers/baseband/acc/rte_acc100_pmd.c
>>> +++ b/drivers/baseband/acc/rte_acc100_pmd.c
>>> @@ -756,6 +756,14 @@ acc100_queue_setup(struct rte_bbdev *dev,
>> uint16_t queue_id,
>>> ret = -ENOMEM;
>>> goto free_lb_out;
>>> }
>>> + q->derm_buffer = rte_zmalloc_socket(dev->device->driver->name,
>>> + RTE_BBDEV_TURBO_MAX_CB_SIZE * 10,
>>> + RTE_CACHE_LINE_SIZE, conf->socket);
>>> + if (q->derm_buffer == NULL) {
>>> + rte_bbdev_log(ERR, "Failed to allocate derm_buffer memory");
>>> + ret = -ENOMEM;
>>> + goto free_companion_ring_addr;
>>> + }
>>>
>>> /*
>>> * Software queue ring wraps synchronously with the HW when it
>>> reaches @@ -776,7 +784,7 @@ acc100_queue_setup(struct rte_bbdev *dev,
>> uint16_t queue_id,
>>> q_idx = acc100_find_free_queue_idx(dev, conf);
>>> if (q_idx == -1) {
>>> ret = -EINVAL;
>>> - goto free_companion_ring_addr;
>>> + goto free_derm_buffer;
>>> }
>>>
>>> q->qgrp_id = (q_idx >> ACC100_GRP_ID_SHIFT) & 0xF; @@ -804,6
>> +812,9
>>> @@ acc100_queue_setup(struct rte_bbdev *dev, uint16_t queue_id,
>>> dev->data->queues[queue_id].queue_private = q;
>>> return 0;
>>>
>>> +free_derm_buffer:
>>> + rte_free(q->derm_buffer);
>>> + q->derm_buffer = NULL;
>>> free_companion_ring_addr:
>>> rte_free(q->companion_ring_addr);
>>> q->companion_ring_addr = NULL;
>>> @@ -890,6 +901,7 @@ acc100_queue_release(struct rte_bbdev *dev,
>> uint16_t q_id)
>>> /* Mark the Queue as un-assigned */
>>> d->q_assigned_bit_map[q->qgrp_id] &= (0xFFFFFFFFFFFFFFFF -
>>> (uint64_t) (1 << q->aq_id));
>>> + rte_free(q->derm_buffer);
>>> rte_free(q->companion_ring_addr);
>>> rte_free(q->lb_in);
>>> rte_free(q->lb_out);
>>> @@ -3111,10 +3123,41 @@ harq_loopback(struct acc_queue *q, struct
>> rte_bbdev_dec_op *op,
>>> return 1;
>>> }
>>>
>>> +/* Assess whether a work around is recommended for the deRM corner
>>> +cases */ static inline bool derm_workaround_recommended(struct
>>> +rte_bbdev_op_ldpc_dec *ldpc_dec, struct acc_queue *q) {
>>> + if (!is_acc100(q))
>>> + return false;
>>> + int32_t e = ldpc_dec->cb_params.e;
>>> + int q_m = ldpc_dec->q_m;
>>> + int z_c = ldpc_dec->z_c;
>>> + int K = (ldpc_dec->basegraph == 1 ? ACC_K_ZC_1 : ACC_K_ZC_2) * z_c;
>>> + bool recommended = false;
>>> +
>>> + if (ldpc_dec->basegraph == 1) {
>>> + if ((q_m == 4) && (z_c >= 320) && (e * ACC_LIM_31 > K * 64))
>>> + recommended = true;
>>> + else if ((e * ACC_LIM_21 > K * 64))
>>> + recommended = true;
>>> + } else {
>>> + if (q_m <= 2) {
>>> + if ((z_c >= 208) && (e * ACC_LIM_09 > K * 64))
>>> + recommended = true;
>>> + else if ((z_c < 208) && (e * ACC_LIM_03 > K * 64))
>>> + recommended = true;
>>> + } else if (e * ACC_LIM_14 > K * 64)
>>> + recommended = true;
>>> + }
>>> +
>>> + return recommended;
>>> +}
>>> +
>>> /** Enqueue one decode operations for ACC100 device in CB mode */
>>> static inline int
>>> enqueue_ldpc_dec_one_op_cb(struct acc_queue *q, struct
>> rte_bbdev_dec_op *op,
>>> - uint16_t total_enqueued_cbs, bool same_op)
>>> + uint16_t total_enqueued_cbs, bool same_op,
>>> + struct rte_bbdev_queue_data *q_data)
>>> {
>>> int ret;
>>> if (unlikely(check_bit(op->ldpc_dec.op_flags,
>>> @@ -3168,6 +3211,12 @@ enqueue_ldpc_dec_one_op_cb(struct acc_queue
>> *q, struct rte_bbdev_dec_op *op,
>>> } else {
>>> struct acc_fcw_ld *fcw;
>>> uint32_t seg_total_left;
>>> +
>>> + if (derm_workaround_recommended(&op->ldpc_dec, q)) {
>>> + RTE_SET_USED(q_data);
>> Why do we need q_data if it is not being used?
>
> As you can guess this notably allows customer do consider running deRM from here as a local patch hence keeping the q_data accessible.
> Basically we keep the prototype of the function enqueue_ldpc_dec_one_op_cb() compatible with such usage.
> I believe this is a good practice here. Let us know if you are not convinced.
I think it is better to just warn the user, without adding unused
parameters.
Thanks,
Maxime
> Thanks
> Nic
>
>>
>>> + rte_bbdev_log(INFO, "Corner case may require deRM
>> pre-processing");
>>> + }
>>> +
>>> fcw = &desc->req.fcw_ld;
>>> q->d->fcw_ld_fill(op, fcw, harq_layout);
>>>
>>> @@ -3721,7 +3770,7 @@ acc100_enqueue_ldpc_dec_cb(struct
>> rte_bbdev_queue_data *q_data,
>>> ops[i]->ldpc_dec.n_cb, ops[i]->ldpc_dec.q_m,
>>> ops[i]->ldpc_dec.n_filler, ops[i]-
>>> ldpc_dec.cb_params.e,
>>> same_op);
>>> - ret = enqueue_ldpc_dec_one_op_cb(q, ops[i], i, same_op);
>>> + ret = enqueue_ldpc_dec_one_op_cb(q, ops[i], i, same_op,
>> q_data);
>>> if (ret < 0) {
>>> acc_enqueue_invalid(q_data);
>>> break;
>
next prev parent reply other threads:[~2022-11-03 15:07 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-01 4:13 [PATCH v7 0/1] baseband/acc100: changes for 22.11 Hernan Vargas
2022-11-01 4:13 ` [PATCH v7 1/1] baseband/acc100: add detection for deRM corner cases Hernan Vargas
2022-11-03 13:00 ` [EXT] " Akhil Goyal
2022-11-03 14:10 ` Maxime Coquelin
2022-11-03 14:59 ` Chautru, Nicolas
2022-11-03 15:07 ` Maxime Coquelin [this message]
2022-11-03 16:20 ` Chautru, Nicolas
2022-11-03 19:24 ` Chautru, Nicolas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f1eca5c6-15ee-344c-b3b3-73cdd16a60d8@redhat.com \
--to=maxime.coquelin@redhat.com \
--cc=dev@dpdk.org \
--cc=gakhil@marvell.com \
--cc=hernan.vargas@intel.com \
--cc=nicolas.chautru@intel.com \
--cc=qi.z.zhang@intel.com \
--cc=trix@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).