Re: [PATCH v6 1/1] baseband/acc100: add workaround for deRM corner cases
On 10/25/22 8:01 AM, Chautru, Nicolas wrote:
Hi Maxime,
-Original Message-
From: Maxime Coquelin
Sent: Tuesday, October 25, 2022 1:26 AM
To: Vargas, Hernan ; dev@dpdk.org;
gak...@marvell.com; t...@redhat.com
Cc: Chautru, Nicolas ; Zhang, Qi Z
; David Marchand ;
Thomas Monjalon
Subject: Re: [PATCH v6 1/1] baseband/acc100: add workaround for deRM
corner cases
Hi Hernan,
On 10/25/22 04:38, Hernan Vargas wrote:
Add function to support de-ratematch pre-processing 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.
To be able to avoid completely such potential issue, the PMD can
preempt such code block configuration so that to process the first
level deRM in SW using the SDK libraries prior to running the rest of
the FEC decoding in HW using an amended code block configuration.
In case meson build system doesn't find such SDK libraries, the fall
method is to run in HW with a warning.
Signed-off-by: Hernan Vargas
---
drivers/baseband/acc/acc_common.h | 8 ++
drivers/baseband/acc/meson.build | 21 +
drivers/baseband/acc/rte_acc100_pmd.c | 108
+-
3 files changed, 134 insertions(+), 3 deletions(-)
diff --git a/drivers/baseband/acc/acc_common.h
b/drivers/baseband/acc/acc_common.h
index eae7eab4e9..5e8972b40a 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 when padding is required */
+#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/meson.build b/drivers/baseband/acc/meson.build
index 77c393b533..a5fc4fed01 100644
--- a/drivers/baseband/acc/meson.build
+++ b/drivers/baseband/acc/meson.build
@@ -1,6 +1,27 @@
# SPDX-License-Identifier: BSD-3-Clause
# Copyright(c) 2020 Intel Corporation
+# Check for FlexRAN SDK libraries
+dep_dec5g = dependency('flexran_sdk_ldpc_decoder_5gnr', required:
+false)
+
+if dep_dec5g.found()
+ext_deps += cc.find_library('libstdc++', required: true)
+ext_deps += cc.find_library('libirc', required: true)
+ext_deps += cc.find_library('libimf', required: true)
+ext_deps += cc.find_library('libipps', required: true)
+ext_deps += cc.find_library('libsvml', required: true)
+ext_deps += dep_dec5g
+ext_deps += dependency('flexran_sdk_ldpc_encoder_5gnr', required:
true)
+ext_deps += dependency('flexran_sdk_LDPC_ratematch_5gnr', required:
true)
+ext_deps += dependency('flexran_sdk_rate_dematching_5gnr', required:
true)
+ext_deps += dependency('flexran_sdk_turbo', required: true)
+ext_deps += dependency('flexran_sdk_crc', required: true)
+ext_deps += dependency('flexran_sdk_rate_matching', required: true)
+ext_deps += dependency('flexran_sdk_common', required: true)
+cflags += ['-DRTE_BBDEV_SDK_AVX2']
+cflags += ['-DRTE_BBDEV_SDK_AVX512'] endif
+
deps += ['bbdev', 'bus_pci']
sources = files('rte_acc100_pmd.c', 'rte_acc200_pmd.c') diff --git
a/drivers/baseband/acc/rte_acc100_pmd.c
b/drivers/baseband/acc/rte_acc100_pmd.c
index 23bc5d25bb..e8b230e563 100644
--- a/drivers/baseband/acc/rte_acc100_pmd.c
+++ b/drivers/baseband/acc/rte_acc100_pmd.c
@@ -25,6 +25,10 @@
#include "acc101_pmd.h"
#include "acc200_cfg.h"
+#ifdef RTE_BBDEV_SDK_AVX512
+#include #endif
+
#ifdef RTE_LIBRTE_BBDEV_DEBUG
RTE_LOG_REGISTER_DEFAULT(acc100_logtype, DEBUG);
#else
@@ -756,6 +760,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 +788,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
+816,9
@@ acc100_queue_setup(struct rte_bbdev *dev, uint16_t queue_id,
dev->data->queues[queue_id].queue_pri
Re: [PATCH v4 1/7] bbdev: allow operation type enum for growth
On 7/5/22 5:23 PM, Nicolas Chautru wrote:
Updating the enum for rte_bbdev_op_type
to allow to keep ABI compatible for enum insertion
while adding padded maximum value for array need.
Removing RTE_BBDEV_OP_TYPE_COUNT and instead exposing
RTE_BBDEV_OP_TYPE_PADDED_MAX.
Signed-off-by: Nicolas Chautru
---
app/test-bbdev/test_bbdev.c | 2 +-
app/test-bbdev/test_bbdev_perf.c | 4 ++--
examples/bbdev_app/main.c| 2 +-
lib/bbdev/rte_bbdev.c| 9 +
lib/bbdev/rte_bbdev_op.h | 2 +-
5 files changed, 10 insertions(+), 9 deletions(-)
diff --git a/app/test-bbdev/test_bbdev.c b/app/test-bbdev/test_bbdev.c
index ac06d73..1063f6e 100644
--- a/app/test-bbdev/test_bbdev.c
+++ b/app/test-bbdev/test_bbdev.c
@@ -521,7 +521,7 @@ struct bbdev_testsuite_params {
rte_mempool_free(mp);
TEST_ASSERT((mp = rte_bbdev_op_pool_create("Test_INV",
- RTE_BBDEV_OP_TYPE_COUNT, size, cache_size, 0)) == NULL,
+ RTE_BBDEV_OP_TYPE_PADDED_MAX, size, cache_size, 0)) ==
NULL,
"Failed test for rte_bbdev_op_pool_create: "
"returned value is not NULL for invalid type");
diff --git a/app/test-bbdev/test_bbdev_perf.c b/app/test-bbdev/test_bbdev_perf.c
index fad3b1e..1abda2d 100644
--- a/app/test-bbdev/test_bbdev_perf.c
+++ b/app/test-bbdev/test_bbdev_perf.c
@@ -2428,13 +2428,13 @@ typedef int (test_case_function)(struct active_device
*ad,
/* Find capabilities */
const struct rte_bbdev_op_cap *cap = info.drv.capabilities;
- for (i = 0; i < RTE_BBDEV_OP_TYPE_COUNT; i++) {
+ do {
if (cap->type == test_vector.op_type) {
capabilities = cap;
break;
}
cap++;
- }
+ } while (cap->type != RTE_BBDEV_OP_NONE);
TEST_ASSERT_NOT_NULL(capabilities,
"Couldn't find capabilities");
diff --git a/examples/bbdev_app/main.c b/examples/bbdev_app/main.c
index fc7e8b8..ef0ba76 100644
--- a/examples/bbdev_app/main.c
+++ b/examples/bbdev_app/main.c
@@ -1041,7 +1041,7 @@ uint16_t bbdev_parse_number(const char *mask)
void *sigret;
struct app_config_params app_params = def_app_config;
struct rte_mempool *ethdev_mbuf_mempool, *bbdev_mbuf_mempool;
- struct rte_mempool *bbdev_op_pools[RTE_BBDEV_OP_TYPE_COUNT];
+ struct rte_mempool *bbdev_op_pools[RTE_BBDEV_OP_TYPE_PADDED_MAX];
struct lcore_conf lcore_conf[RTE_MAX_LCORE] = { {0} };
struct lcore_statistics lcore_stats[RTE_MAX_LCORE] = { {0} };
struct stats_lcore_params stats_lcore;
diff --git a/lib/bbdev/rte_bbdev.c b/lib/bbdev/rte_bbdev.c
index aaee7b7..22bd894 100644
--- a/lib/bbdev/rte_bbdev.c
+++ b/lib/bbdev/rte_bbdev.c
@@ -23,6 +23,8 @@
#define DEV_NAME "BBDEV"
+/* Number of supported operation types */
+#define BBDEV_OP_TYPE_COUNT 5
/* BBDev library logging ID */
RTE_LOG_REGISTER_DEFAULT(bbdev_logtype, NOTICE);
@@ -890,10 +892,10 @@ struct rte_mempool *
return NULL;
}
- if (type >= RTE_BBDEV_OP_TYPE_COUNT) {
+ if (type >= BBDEV_OP_TYPE_COUNT) {
rte_bbdev_log(ERR,
"Invalid op type (%u), should be less than %u",
- type, RTE_BBDEV_OP_TYPE_COUNT);
+ type, BBDEV_OP_TYPE_COUNT);
return NULL;
}
@@ -1122,10 +1124,9 @@ struct rte_mempool *
"RTE_BBDEV_OP_TURBO_DEC",
"RTE_BBDEV_OP_TURBO_ENC",
"RTE_BBDEV_OP_LDPC_DEC",
- "RTE_BBDEV_OP_LDPC_ENC",
};
- if (op_type < RTE_BBDEV_OP_TYPE_COUNT)
+ if (op_type < BBDEV_OP_TYPE_COUNT)
return op_types[op_type];
rte_bbdev_log(ERR, "Invalid operation type");
diff --git a/lib/bbdev/rte_bbdev_op.h b/lib/bbdev/rte_bbdev_op.h
index 6d56133..cd82418 100644
--- a/lib/bbdev/rte_bbdev_op.h
+++ b/lib/bbdev/rte_bbdev_op.h
@@ -748,7 +748,7 @@ enum rte_bbdev_op_type {
RTE_BBDEV_OP_TURBO_ENC, /**< Turbo encode */
RTE_BBDEV_OP_LDPC_DEC, /**< LDPC decode */
RTE_BBDEV_OP_LDPC_ENC, /**< LDPC encode */
- RTE_BBDEV_OP_TYPE_COUNT, /**< Count of different op types */
Why not keep this enum so you don't have to make the BBDEV_OP_TYPE_COUNT
#define ?
Tom
+ RTE_BBDEV_OP_TYPE_PADDED_MAX = 8, /**< Maximum op type number
including padding */
};
/** Bit indexes of possible errors reported through status field */
Re: [PATCH v4 2/7] bbdev: add device status info
On 7/5/22 5:23 PM, Nicolas Chautru wrote:
Added device status information, so that the PMD can
expose information related to the underlying accelerator device status.
Minor order change in structure to fit into padding hole.
Signed-off-by: Nicolas Chautru
---
drivers/baseband/acc100/rte_acc100_pmd.c | 1 +
drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c | 1 +
drivers/baseband/fpga_lte_fec/fpga_lte_fec.c | 1 +
drivers/baseband/la12xx/bbdev_la12xx.c | 1 +
drivers/baseband/null/bbdev_null.c | 1 +
drivers/baseband/turbo_sw/bbdev_turbo_software.c | 1 +
lib/bbdev/rte_bbdev.c | 24 +++
lib/bbdev/rte_bbdev.h | 35 --
lib/bbdev/version.map | 6
9 files changed, 69 insertions(+), 2 deletions(-)
diff --git a/drivers/baseband/acc100/rte_acc100_pmd.c
b/drivers/baseband/acc100/rte_acc100_pmd.c
index de7e4bc..17ba798 100644
--- a/drivers/baseband/acc100/rte_acc100_pmd.c
+++ b/drivers/baseband/acc100/rte_acc100_pmd.c
@@ -1060,6 +1060,7 @@
/* Read and save the populated config from ACC100 registers */
fetch_acc100_config(dev);
+ dev_info->device_status = RTE_BBDEV_DEV_NOT_SUPPORTED;
/* This isn't ideal because it reports the maximum number of queues but
* does not provide info on how many can be uplink/downlink or different
diff --git a/drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c
b/drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c
index 82ae6ba..57b12af 100644
--- a/drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c
+++ b/drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c
@@ -369,6 +369,7 @@
dev_info->capabilities = bbdev_capabilities;
dev_info->cpu_flag_reqs = NULL;
dev_info->data_endianness = RTE_LITTLE_ENDIAN;
+ dev_info->device_status = RTE_BBDEV_DEV_NOT_SUPPORTED;
/* Calculates number of queues assigned to device */
dev_info->max_num_queues = 0;
diff --git a/drivers/baseband/fpga_lte_fec/fpga_lte_fec.c
b/drivers/baseband/fpga_lte_fec/fpga_lte_fec.c
index 21d3529..2a330c4 100644
--- a/drivers/baseband/fpga_lte_fec/fpga_lte_fec.c
+++ b/drivers/baseband/fpga_lte_fec/fpga_lte_fec.c
@@ -645,6 +645,7 @@ struct __rte_cache_aligned fpga_queue {
dev_info->capabilities = bbdev_capabilities;
dev_info->cpu_flag_reqs = NULL;
dev_info->data_endianness = RTE_LITTLE_ENDIAN;
+ dev_info->device_status = RTE_BBDEV_DEV_NOT_SUPPORTED;
/* Calculates number of queues assigned to device */
dev_info->max_num_queues = 0;
diff --git a/drivers/baseband/la12xx/bbdev_la12xx.c
b/drivers/baseband/la12xx/bbdev_la12xx.c
index 4d1bd16..c1f88c6 100644
--- a/drivers/baseband/la12xx/bbdev_la12xx.c
+++ b/drivers/baseband/la12xx/bbdev_la12xx.c
@@ -100,6 +100,7 @@ struct bbdev_la12xx_params {
dev_info->capabilities = bbdev_capabilities;
dev_info->cpu_flag_reqs = NULL;
dev_info->min_alignment = 64;
+ dev_info->device_status = RTE_BBDEV_DEV_NOT_SUPPORTED;
rte_bbdev_log_debug("got device info from %u", dev->data->dev_id);
}
diff --git a/drivers/baseband/null/bbdev_null.c
b/drivers/baseband/null/bbdev_null.c
index 248e129..94a1976 100644
--- a/drivers/baseband/null/bbdev_null.c
+++ b/drivers/baseband/null/bbdev_null.c
@@ -82,6 +82,7 @@ struct bbdev_queue {
* here for code completeness.
*/
dev_info->data_endianness = RTE_LITTLE_ENDIAN;
+ dev_info->device_status = RTE_BBDEV_DEV_NOT_SUPPORTED;
rte_bbdev_log_debug("got device info from %u", dev->data->dev_id);
}
diff --git a/drivers/baseband/turbo_sw/bbdev_turbo_software.c
b/drivers/baseband/turbo_sw/bbdev_turbo_software.c
index af7bc41..dbc5524 100644
--- a/drivers/baseband/turbo_sw/bbdev_turbo_software.c
+++ b/drivers/baseband/turbo_sw/bbdev_turbo_software.c
@@ -254,6 +254,7 @@ struct turbo_sw_queue {
dev_info->min_alignment = 64;
dev_info->harq_buffer_size = 0;
dev_info->data_endianness = RTE_LITTLE_ENDIAN;
+ dev_info->device_status = RTE_BBDEV_DEV_NOT_SUPPORTED;
rte_bbdev_log_debug("got device info from %u\n", dev->data->dev_id);
}
diff --git a/lib/bbdev/rte_bbdev.c b/lib/bbdev/rte_bbdev.c
index 22bd894..555bda9 100644
--- a/lib/bbdev/rte_bbdev.c
+++ b/lib/bbdev/rte_bbdev.c
@@ -25,6 +25,8 @@
/* Number of supported operation types */
#define BBDEV_OP_TYPE_COUNT 5
+/* Number of supported device status */
+#define BBDEV_DEV_STATUS_COUNT 9
/* BBDev library logging ID */
RTE_LOG_REGISTER_DEFAULT(bbdev_logtype, NOTICE);
@@ -1132,3 +1134,25 @@ struct rte_mempool *
rte_bbdev_log(ERR, "Invalid operation type");
return NULL;
}
+
+const char *
+rte_bbdev_device_status_str(enum rte_bbdev_device_status status)
+{
+ static const char * const dev_sta_string[] = {
+ "RTE_BBDEV_DEV_NOSTATUS",
+ "RTE_BBDEV_DE
Re: [PATCH v4 3/7] bbdev: add device info on queue topology
On 7/5/22 5:23 PM, Nicolas Chautru wrote:
Adding more options in the API to expose the number
of queues exposed and related priority.
Signed-off-by: Nicolas Chautru
---
lib/bbdev/rte_bbdev.h | 4
1 file changed, 4 insertions(+)
diff --git a/lib/bbdev/rte_bbdev.h b/lib/bbdev/rte_bbdev.h
index 9b1ffa4..ac941d6 100644
--- a/lib/bbdev/rte_bbdev.h
+++ b/lib/bbdev/rte_bbdev.h
@@ -289,6 +289,10 @@ struct rte_bbdev_driver_info {
/** Maximum number of queues supported by the device */
unsigned int max_num_queues;
+ /** Maximum number of queues supported per operation type */
+ unsigned int num_queues[RTE_BBDEV_OP_TYPE_PADDED_MAX];
+ /** Priority level supported per operation type */
+ unsigned int queue_priority[RTE_BBDEV_OP_TYPE_PADDED_MAX];
It is better to add new elements to the end of a structure for better
backward compatiblity
Tom
/** Queue size limit (queue size must also be power of 2) */
uint32_t queue_size_lim;
/** Set if device off-loads operation to hardware */
Re: [PATCH v4 4/7] drivers/baseband: update PMDs to expose queue per operation
On 7/5/22 5:23 PM, Nicolas Chautru wrote:
Add support in existing bbdev PMDs for the explicit number of queue
and priority for each operation type configured on the device.
Signed-off-by: Nicolas Chautru
---
drivers/baseband/acc100/rte_acc100_pmd.c | 29 +-
drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c | 8 ++
drivers/baseband/fpga_lte_fec/fpga_lte_fec.c | 8 ++
drivers/baseband/la12xx/bbdev_la12xx.c | 7 ++
drivers/baseband/turbo_sw/bbdev_turbo_software.c | 11
5 files changed, 51 insertions(+), 12 deletions(-)
diff --git a/drivers/baseband/acc100/rte_acc100_pmd.c
b/drivers/baseband/acc100/rte_acc100_pmd.c
index 17ba798..d568d0d 100644
--- a/drivers/baseband/acc100/rte_acc100_pmd.c
+++ b/drivers/baseband/acc100/rte_acc100_pmd.c
@@ -966,6 +966,7 @@
struct rte_bbdev_driver_info *dev_info)
{
struct acc100_device *d = dev->data->dev_private;
+ int i;
static const struct rte_bbdev_op_cap bbdev_capabilities[] = {
{
@@ -1062,19 +1063,23 @@
fetch_acc100_config(dev);
dev_info->device_status = RTE_BBDEV_DEV_NOT_SUPPORTED;
- /* This isn't ideal because it reports the maximum number of queues but
-* does not provide info on how many can be uplink/downlink or different
-* priorities
-*/
- dev_info->max_num_queues =
- d->acc100_conf.q_dl_5g.num_aqs_per_groups *
- d->acc100_conf.q_dl_5g.num_qgroups +
- d->acc100_conf.q_ul_5g.num_aqs_per_groups *
- d->acc100_conf.q_ul_5g.num_qgroups +
- d->acc100_conf.q_dl_4g.num_aqs_per_groups *
- d->acc100_conf.q_dl_4g.num_qgroups +
- d->acc100_conf.q_ul_4g.num_aqs_per_groups *
+ /* Expose number of queues */
+ dev_info->num_queues[RTE_BBDEV_OP_NONE] = 0;
+ dev_info->num_queues[RTE_BBDEV_OP_TURBO_DEC] =
d->acc100_conf.q_ul_4g.num_aqs_per_groups *
d->acc100_conf.q_ul_4g.num_qgroups;
+ dev_info->num_queues[RTE_BBDEV_OP_TURBO_ENC] =
d->acc100_conf.q_dl_4g.num_aqs_per_groups *
+ d->acc100_conf.q_dl_4g.num_qgroups;
+ dev_info->num_queues[RTE_BBDEV_OP_LDPC_DEC] =
d->acc100_conf.q_ul_5g.num_aqs_per_groups *
+ d->acc100_conf.q_ul_5g.num_qgroups;
+ dev_info->num_queues[RTE_BBDEV_OP_LDPC_ENC] =
d->acc100_conf.q_dl_5g.num_aqs_per_groups *
+ d->acc100_conf.q_dl_5g.num_qgroups;
+ dev_info->queue_priority[RTE_BBDEV_OP_TURBO_DEC] =
d->acc100_conf.q_ul_4g.num_qgroups;
+ dev_info->queue_priority[RTE_BBDEV_OP_TURBO_ENC] =
d->acc100_conf.q_dl_4g.num_qgroups;
+ dev_info->queue_priority[RTE_BBDEV_OP_LDPC_DEC] =
d->acc100_conf.q_ul_5g.num_qgroups;
+ dev_info->queue_priority[RTE_BBDEV_OP_LDPC_ENC] =
d->acc100_conf.q_dl_5g.num_qgroups;
+ dev_info->max_num_queues = 0;
+ for (i = RTE_BBDEV_OP_TURBO_DEC; i < RTE_BBDEV_OP_LDPC_ENC; i++)
should this be i <= ?
+ dev_info->max_num_queues += dev_info->num_queues[i];
dev_info->queue_size_lim = ACC100_MAX_QUEUE_DEPTH;
dev_info->hardware_accelerated = true;
dev_info->max_dl_queue_priority =
diff --git a/drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c
b/drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c
index 57b12af..b4982af 100644
--- a/drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c
+++ b/drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c
@@ -379,6 +379,14 @@
if (hw_q_id != FPGA_INVALID_HW_QUEUE_ID)
dev_info->max_num_queues++;
}
+ /* Expose number of queue per operation type */
+ dev_info->num_queues[RTE_BBDEV_OP_NONE] = 0;
+ dev_info->num_queues[RTE_BBDEV_OP_TURBO_DEC] = 0;
+ dev_info->num_queues[RTE_BBDEV_OP_TURBO_ENC] = 0;
+ dev_info->num_queues[RTE_BBDEV_OP_LDPC_DEC] = dev_info->max_num_queues
/ 2;
+ dev_info->num_queues[RTE_BBDEV_OP_LDPC_ENC] = dev_info->max_num_queues
/ 2;
+ dev_info->queue_priority[RTE_BBDEV_OP_LDPC_DEC] = 1;
+ dev_info->queue_priority[RTE_BBDEV_OP_LDPC_ENC] = 1;
}
/**
diff --git a/drivers/baseband/fpga_lte_fec/fpga_lte_fec.c
b/drivers/baseband/fpga_lte_fec/fpga_lte_fec.c
index 2a330c4..dc7f479 100644
--- a/drivers/baseband/fpga_lte_fec/fpga_lte_fec.c
+++ b/drivers/baseband/fpga_lte_fec/fpga_lte_fec.c
@@ -655,6 +655,14 @@ struct __rte_cache_aligned fpga_queue {
if (hw_q_id != FPGA_INVALID_HW_QUEUE_ID)
dev_info->max_num_queues++;
}
+ /* Expose number of queue per operation type */
+ dev_info->num_queues[RTE_BBDEV_OP_NONE] = 0;
+ dev_info->num_queues[RTE_BBDEV_OP_TURBO_DEC] = dev_info->max_num_queues
/ 2;
+ dev_info->num_queues[RTE_BBDEV_OP_TURBO_ENC] = dev_info->max_num_queues
/ 2;
+ dev_info->num_q
Re: [PATCH v4 5/7] bbdev: add new operation for FFT processing
On 7/5/22 5:23 PM, Nicolas Chautru wrote:
Extension of bbdev operation to support FFT based operations.
Signed-off-by: Nicolas Chautru
Acked-by: Hemant Agrawal
---
doc/guides/prog_guide/bbdev.rst | 130 +++
lib/bbdev/rte_bbdev.c | 11 ++-
lib/bbdev/rte_bbdev.h | 76
lib/bbdev/rte_bbdev_op.h| 149
lib/bbdev/version.map | 4 ++
5 files changed, 369 insertions(+), 1 deletion(-)
diff --git a/doc/guides/prog_guide/bbdev.rst b/doc/guides/prog_guide/bbdev.rst
index 70fa01a..4a055b5 100644
--- a/doc/guides/prog_guide/bbdev.rst
+++ b/doc/guides/prog_guide/bbdev.rst
@@ -1118,6 +1118,136 @@ Figure :numref:`figure_turbo_tb_decode` above
showing the Turbo decoding of CBs using BBDEV interface in TB-mode
is also valid for LDPC decode.
+BBDEV FFT Operation
+
+
+This operation allows to run a combination of DFT and/or IDFT and/or
time-domain windowing.
+These can be used in a modular fashion (using bypass modes) or as a processing
pipeline
+which can be used for FFT-based baseband signal processing.
+In more details it allows :
+- to process the data first through an IDFT of adjustable size and padding;
+- to perform the windowing as a programmable cyclic shift offset of the data
followed by a
+pointwise multiplication by a time domain window;
+- to process the related data through a DFT of adjustable size and depadding
for each such cyclic
+shift output.
+
+A flexible number of Rx antennas are being processed in parallel with the same
configuration.
+The API allows more generally for flexibility in what the PMD may support
(cabability flags) and
+flexibility to adjust some of the parameters of the processing.
+
+The operation/capability flags that can be set for each FFT 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 FFT capability flags |
+++
+|RTE_BBDEV_FFT_WINDOWING |
+| Set to enable/support windowing in time domain |
+++
+|RTE_BBDEV_FFT_CS_ADJUSTMENT |
+| Set to enable/support the cyclic shift time offset adjustment |
+++
+|RTE_BBDEV_FFT_DFT_BYPASS|
+| Set to bypass the DFT and use directly the IDFT as an option |
+++
+|RTE_BBDEV_FFT_IDFT_BYPASS |
+| Set to bypass the IDFT and use directly the DFT as an option |
+++
+|RTE_BBDEV_FFT_WINDOWING_BYPASS |
+| Set to bypass the time domain windowing as an option |
+++
+|RTE_BBDEV_FFT_POWER_MEAS
Other flags are not truncated, should be
RTE_BBDEV_FFT_POWER_MEASUREMENT
|
+| Set to provide an optional power measument of the DFT output |
+++
measurement
+|RTE_BBDEV_FFT_FP16_INPUT|
+| Set if the input data shall use FP16 format instead of INT16 |
+++
+|RTE_BBDEV_FFT_FP16_OUTPUT |
+| Set if the output data shall use FP16 format instead of INT16 |
+++
+
+The structure passed for each FFT operation is given below,
+with the operation flags forming a bitmask in the ``op_flags`` field.
+
+.. code-block:: c
+
+struct rte_bbdev_op_fft {
+struct rte_bbdev_op_data base_input;
+struct rte_bbdev_op_data base_output;
+struct rte_bbdev_op_data power_meas_output;
similar to above, meas -> measurement
+uint32_t op_flags;
+uint16_t input_sequence_size;
Could these be future proofed by increasing small int size's to uint32_t ?
+uint16_t input_leading_padding;
+uint16_t output_sequence_size;
+uint16_t output_leading_depadding;
+uint8_t window_index[RTE_BBDEV_MAX_CS_2];
+uint16_t cs_bitmap;
+uint8_t num_antennas_log2;
+uint8_t idft_log2;
+uint8_t dft_log2;
is _log2 needed in variable
Re: [PATCH v4 6/7] bbdev: add queue related warning and status information
On 7/5/22 5:23 PM, Nicolas Chautru wrote:
This allows to expose more information with regards to any
queue related failure and warning which cannot be supported
in existing API.
Signed-off-by: Nicolas Chautru
---
app/test-bbdev/test_bbdev_perf.c | 2 ++
lib/bbdev/rte_bbdev.c| 21 +
lib/bbdev/rte_bbdev.h| 34 ++
lib/bbdev/version.map| 1 +
4 files changed, 58 insertions(+)
diff --git a/app/test-bbdev/test_bbdev_perf.c b/app/test-bbdev/test_bbdev_perf.c
index 1abda2d..653b21f 100644
--- a/app/test-bbdev/test_bbdev_perf.c
+++ b/app/test-bbdev/test_bbdev_perf.c
@@ -4360,6 +4360,8 @@ typedef int (test_case_function)(struct active_device *ad,
stats->dequeued_count = q_stats->dequeued_count;
stats->enqueue_err_count = q_stats->enqueue_err_count;
stats->dequeue_err_count = q_stats->dequeue_err_count;
+ stats->enqueue_warning_count = q_stats->enqueue_warning_count;
+ stats->dequeue_warning_count = q_stats->dequeue_warning_count;
stats->acc_offload_cycles = q_stats->acc_offload_cycles;
return 0;
diff --git a/lib/bbdev/rte_bbdev.c b/lib/bbdev/rte_bbdev.c
index 28b105d..ddad464 100644
--- a/lib/bbdev/rte_bbdev.c
+++ b/lib/bbdev/rte_bbdev.c
@@ -27,6 +27,8 @@
#define BBDEV_OP_TYPE_COUNT 6
/* Number of supported device status */
#define BBDEV_DEV_STATUS_COUNT 9
+/* Number of supported enqueue status */
+#define BBDEV_ENQ_STATUS_COUNT 4
/* BBDev library logging ID */
RTE_LOG_REGISTER_DEFAULT(bbdev_logtype, NOTICE);
@@ -723,6 +725,8 @@ struct rte_bbdev *
stats->dequeued_count += q_stats->dequeued_count;
stats->enqueue_err_count += q_stats->enqueue_err_count;
stats->dequeue_err_count += q_stats->dequeue_err_count;
+ stats->enqueue_warn_count += q_stats->enqueue_warn_count;
+ stats->dequeue_warn_count += q_stats->dequeue_warn_count;
}
rte_bbdev_log_debug("Got stats on %u", dev->data->dev_id);
}
@@ -1165,3 +1169,20 @@ struct rte_mempool *
rte_bbdev_log(ERR, "Invalid device status");
return NULL;
}
+
+const char *
+rte_bbdev_enqueue_status_str(enum rte_bbdev_enqueue_status status)
+{
+ static const char * const enq_sta_string[] = {
+ "RTE_BBDEV_ENQ_STATUS_NONE",
+ "RTE_BBDEV_ENQ_STATUS_QUEUE_FULL",
+ "RTE_BBDEV_ENQ_STATUS_RING_FULL",
+ "RTE_BBDEV_ENQ_STATUS_INVALID_OP",
+ };
+
+ if (status < BBDEV_ENQ_STATUS_COUNT)
Single use of #define, could just be an array size check and remove the
#define
+ return enq_sta_string[status];
+
+ rte_bbdev_log(ERR, "Invalid enqueue status");
+ return NULL;
+}
diff --git a/lib/bbdev/rte_bbdev.h b/lib/bbdev/rte_bbdev.h
index ed528b8..b7ecf94 100644
--- a/lib/bbdev/rte_bbdev.h
+++ b/lib/bbdev/rte_bbdev.h
@@ -224,6 +224,19 @@ struct rte_bbdev_queue_conf {
rte_bbdev_queue_stop(uint16_t dev_id, uint16_t queue_id);
/**
+ * Flags indicate the reason why a previous enqueue may not have
+ * consumed all requested operations
+ * In case of multiple reasons the latter superdes a previous one
+ */
+enum rte_bbdev_enqueue_status {
+ RTE_BBDEV_ENQ_STATUS_NONE, /**< Nothing to report */
+ RTE_BBDEV_ENQ_STATUS_QUEUE_FULL, /**< Not enough room in queue */
+ RTE_BBDEV_ENQ_STATUS_RING_FULL,/**< Not enough room in ring */
+ RTE_BBDEV_ENQ_STATUS_INVALID_OP, /**< Operation was rejected as
invalid */
+ RTE_BBDEV_ENQ_STATUS_PADDED_MAX = 6, /**< Maximum enq status number
including padding */
Pad to 8 like the other patch ?
+};
+
+/**
* Flags indicate the status of the device
*/
enum rte_bbdev_device_status {
@@ -246,6 +259,12 @@ struct rte_bbdev_stats {
uint64_t enqueue_err_count;
/** Total error count on operations dequeued */
uint64_t dequeue_err_count;
+ /** Total warning count on operations enqueued */
+ uint64_t enqueue_warn_count;
+ /** Total warning count on operations dequeued */
+ uint64_t dequeue_warn_count;
+ /** Total enqueue status count based on rte_bbdev_enqueue_status enum */
+ uint64_t enqueue_status_count[RTE_BBDEV_ENQ_STATUS_PADDED_MAX];
This element is not used in this patch, is it needed ?
/** CPU cycles consumed by the (HW/SW) accelerator device to offload
* the enqueue request to its internal queues.
* - For a HW device this is the cycles consumed in MMIO write
@@ -386,6 +405,7 @@ struct rte_bbdev_queue_data {
void *queue_private; /**< Driver-specific per-queue data */
struct rte_bbdev_queue_conf conf; /**< Current configuration */
struct rte_bbdev_stats queue_stats; /**< Queue statistics */
+ enum rte_bbdev_enqueue_status enqueue_status; /**< Enqueue status when
op is rejected */
This element is not used in this pa
Re: [PATCH v4 7/7] bbdev: add a lock option for enqueue/dequeue operation
On 7/5/22 5:23 PM, Nicolas Chautru wrote:
Locking is not explicitly required but can be valuable
in case the application cannot guarantee to be thread-safe,
or specifically is at risk of using the same queue from multiple threads.
This is an option for PMD to use this.
Signed-off-by: Nicolas Chautru
---
lib/bbdev/rte_bbdev.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/lib/bbdev/rte_bbdev.h b/lib/bbdev/rte_bbdev.h
index b7ecf94..8e7ca86 100644
--- a/lib/bbdev/rte_bbdev.h
+++ b/lib/bbdev/rte_bbdev.h
@@ -407,6 +407,8 @@ struct rte_bbdev_queue_data {
struct rte_bbdev_stats queue_stats; /**< Queue statistics */
enum rte_bbdev_enqueue_status enqueue_status; /**< Enqueue status when
op is rejected */
bool started; /**< Queue state */
+ rte_rwlock_t lock_enq; /**< lock protection for the Enqueue */
+ rte_rwlock_t lock_deq; /**< lock protection for the Dequeue */
No.
This is a good idea but needs a use before introducing another element,
particularly a complicated one like locking
Tom
};
/** @internal Enqueue encode operations for processing on queue of a device. */
Re: [PATCH v4 7/7] bbdev: add a lock option for enqueue/dequeue operation
On 7/6/22 1:21 PM, Chautru, Nicolas wrote:
Hi Stephen, Tom.,
-Original Message-
From: Stephen Hemminger
On Wed, 6 Jul 2022 12:01:19 -0700
Tom Rix wrote:
On 7/5/22 5:23 PM, Nicolas Chautru wrote:
Locking is not explicitly required but can be valuable in case the
application cannot guarantee to be thread-safe, or specifically is
at risk of using the same queue from multiple threads.
This is an option for PMD to use this.
Signed-off-by: Nicolas Chautru
---
lib/bbdev/rte_bbdev.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/lib/bbdev/rte_bbdev.h b/lib/bbdev/rte_bbdev.h index
b7ecf94..8e7ca86 100644
--- a/lib/bbdev/rte_bbdev.h
+++ b/lib/bbdev/rte_bbdev.h
@@ -407,6 +407,8 @@ struct rte_bbdev_queue_data {
struct rte_bbdev_stats queue_stats; /**< Queue statistics */
enum rte_bbdev_enqueue_status enqueue_status; /**< Enqueue
status when op is rejected */
bool started; /**< Queue state */
+ rte_rwlock_t lock_enq; /**< lock protection for the Enqueue */
+ rte_rwlock_t lock_deq; /**< lock protection for the Dequeue */
No.
This is a good idea but needs a use before introducing another
element, particularly a complicated one like locking
Tom
The actual usage would be implemented within the PMD. Basically this to prevent
the corner case when a queue is being accessed from multiple thread for which
there is no protection in DPDK (but application does not necessarily behaves
well).
In normal operation there would never be a case when there is a conflict on the
lock.
This is not something which was considered for any other PMD?
From DPDK doc : "If multiple threads are to use the same hardware queue on the same
NIC port, then locking, or some other form of mutual exclusion, is necessary."
Basically for AC100 we would purely enforce the lock for any enqueue/dequeue
operation for a given queue (distinct lock for enqueue and dequeue, since these
would run on different threads).
I am fine with locking, just have to use them.
For me, this would mean adding them to every public interface so the
changes would be involved.
This is a big change and if pressed to get this patchset into 22.11,
then defer this patch to later.
Tom
Having two locks on same cacheline will create lots of ping/pong false sharing.
You would recommend to purely spread them within the structure? Or something
else?
Also, unless the reader is holding the lock for a significant fraction of the
time a
regular spin lock will be faster.
OK Thanks. It should in principle never have to wait for the lock for the usage
above, only to catch misbehaving application risk.
Nic
Re: [PATCH v4 5/7] bbdev: add new operation for FFT processing
Nic, Not all my comments were addressed. The one I am most interested in is the default type / size and how it interacts with fp16. Please see the others below On 7/6/22 2:04 PM, Chautru, Nicolas wrote: Hi Tom, -Original Message- From: Tom Rix > On 7/5/22 5:23 PM, Nicolas Chautru wrote: Extension of bbdev operation to support FFT based operations. Signed-off-by: Nicolas Chautru Acked-by: Hemant Agrawal --- doc/guides/prog_guide/bbdev.rst | 130 +++ lib/bbdev/rte_bbdev.c | 11 ++- lib/bbdev/rte_bbdev.h | 76 lib/bbdev/rte_bbdev_op.h| 149 lib/bbdev/version.map | 4 ++ 5 files changed, 369 insertions(+), 1 deletion(-) diff --git a/doc/guides/prog_guide/bbdev.rst b/doc/guides/prog_guide/bbdev.rst index 70fa01a..4a055b5 100644 --- a/doc/guides/prog_guide/bbdev.rst +++ b/doc/guides/prog_guide/bbdev.rst @@ -1118,6 +1118,136 @@ Figure :numref:`figure_turbo_tb_decode` above showing the Turbo decoding of CBs using BBDEV interface in TB-mode is also valid for LDPC decode. +BBDEV FFT Operation + + +This operation allows to run a combination of DFT and/or IDFT and/or time- domain windowing. +These can be used in a modular fashion (using bypass modes) or as a +processing pipeline which can be used for FFT-based baseband signal processing. +In more details it allows : +- to process the data first through an IDFT of adjustable size and +padding; +- to perform the windowing as a programmable cyclic shift offset of +the data followed by a pointwise multiplication by a time domain +window; +- to process the related data through a DFT of adjustable size and +depadding for each such cyclic shift output. + +A flexible number of Rx antennas are being processed in parallel with the same configuration. +The API allows more generally for flexibility in what the PMD may +support (cabability flags) and flexibility to adjust some of the parameters of the processing. + +The operation/capability flags that can be set for each FFT 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 FFT capability flags | ++=== = +++ +|RTE_BBDEV_FFT_WINDOWING | +| Set to enable/support windowing in time domain | +++ +|RTE_BBDEV_FFT_CS_ADJUSTMENT | +| Set to enable/support the cyclic shift time offset adjustment | +++ +|RTE_BBDEV_FFT_DFT_BYPASS| +| Set to bypass the DFT and use directly the IDFT as an option | +++ +|RTE_BBDEV_FFT_IDFT_BYPASS | +| Set to bypass the IDFT and use directly the DFT as an option | +++ +|RTE_BBDEV_FFT_WINDOWING_BYPASS | +| Set to bypass the time domain windowing as an option | +++ +|RTE_BBDEV_FFT_POWER_MEAS Other flags are not truncated, should be RTE_BBDEV_FFT_POWER_MEASUREMENT The intention from DPDK recommendation is for these to be kept shortnames, isn't it? Above we use many acronyms to keep it short (CS, etc...) Even in current BBDEV API we use many truncation to keep names short: OUT, ENC/DEC, HQ, RM on top of acronyms. I believe this is still super explicit with that name? Some of other identifier have longer names than this. If you wanted to keep things short, drop the last _ Generally the use of acronyms should be avoided because they add a layer of jargon that makes the code less readable to all but writer. | +| Set to provide an optional power measument of the DFT output | +++ measurement OK Thanks +|RTE_BBDEV_FFT_FP16_INPUT| +| Set if the input data shall use FP16 format instead of INT16 | +++ +|RTE_BBDEV_FFT_FP16_OUTPUT | +| Set if the output data shall use FP16 format instead
Re: [PATCH v4 4/7] drivers/baseband: update PMDs to expose queue per operation
On 7/6/22 2:10 PM, Chautru, Nicolas wrote:
Hi Tom,
-Original Message-
From: Tom Rix
Sent: Wednesday, July 6, 2022 9:15 AM
To: Chautru, Nicolas ; dev@dpdk.org;
tho...@monjalon.net; gak...@marvell.com; hemant.agra...@nxp.com
Cc: maxime.coque...@redhat.com; m...@ashroe.eu; Richardson, Bruce
; david.march...@redhat.com;
step...@networkplumber.org
Subject: Re: [PATCH v4 4/7] drivers/baseband: update PMDs to expose queue
per operation
On 7/5/22 5:23 PM, Nicolas Chautru wrote:
Add support in existing bbdev PMDs for the explicit number of queue
and priority for each operation type configured on the device.
Signed-off-by: Nicolas Chautru
---
drivers/baseband/acc100/rte_acc100_pmd.c | 29 +--
---
drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c | 8 ++
drivers/baseband/fpga_lte_fec/fpga_lte_fec.c | 8 ++
drivers/baseband/la12xx/bbdev_la12xx.c | 7 ++
drivers/baseband/turbo_sw/bbdev_turbo_software.c | 11
5 files changed, 51 insertions(+), 12 deletions(-)
diff --git a/drivers/baseband/acc100/rte_acc100_pmd.c
b/drivers/baseband/acc100/rte_acc100_pmd.c
index 17ba798..d568d0d 100644
--- a/drivers/baseband/acc100/rte_acc100_pmd.c
+++ b/drivers/baseband/acc100/rte_acc100_pmd.c
@@ -966,6 +966,7 @@
struct rte_bbdev_driver_info *dev_info)
{
struct acc100_device *d = dev->data->dev_private;
+ int i;
static const struct rte_bbdev_op_cap bbdev_capabilities[] = {
{
@@ -1062,19 +1063,23 @@
fetch_acc100_config(dev);
dev_info->device_status = RTE_BBDEV_DEV_NOT_SUPPORTED;
- /* This isn't ideal because it reports the maximum number of queues
but
-* does not provide info on how many can be uplink/downlink or
different
-* priorities
-*/
- dev_info->max_num_queues =
- d->acc100_conf.q_dl_5g.num_aqs_per_groups *
- d->acc100_conf.q_dl_5g.num_qgroups +
- d->acc100_conf.q_ul_5g.num_aqs_per_groups *
- d->acc100_conf.q_ul_5g.num_qgroups +
- d->acc100_conf.q_dl_4g.num_aqs_per_groups *
- d->acc100_conf.q_dl_4g.num_qgroups +
- d->acc100_conf.q_ul_4g.num_aqs_per_groups *
+ /* Expose number of queues */
+ dev_info->num_queues[RTE_BBDEV_OP_NONE] = 0;
+ dev_info->num_queues[RTE_BBDEV_OP_TURBO_DEC] =
+d->acc100_conf.q_ul_4g.num_aqs_per_groups *
d->acc100_conf.q_ul_4g.num_qgroups;
+ dev_info->num_queues[RTE_BBDEV_OP_TURBO_ENC] = d-
acc100_conf.q_dl_4g.num_aqs_per_groups *
+ d->acc100_conf.q_dl_4g.num_qgroups;
+ dev_info->num_queues[RTE_BBDEV_OP_LDPC_DEC] = d-
acc100_conf.q_ul_5g.num_aqs_per_groups *
+ d->acc100_conf.q_ul_5g.num_qgroups;
+ dev_info->num_queues[RTE_BBDEV_OP_LDPC_ENC] = d-
acc100_conf.q_dl_5g.num_aqs_per_groups *
+ d->acc100_conf.q_dl_5g.num_qgroups;
+ dev_info->queue_priority[RTE_BBDEV_OP_TURBO_DEC] = d-
acc100_conf.q_ul_4g.num_qgroups;
+ dev_info->queue_priority[RTE_BBDEV_OP_TURBO_ENC] = d-
acc100_conf.q_dl_4g.num_qgroups;
+ dev_info->queue_priority[RTE_BBDEV_OP_LDPC_DEC] = d-
acc100_conf.q_ul_5g.num_qgroups;
+ dev_info->queue_priority[RTE_BBDEV_OP_LDPC_ENC] = d-
acc100_conf.q_dl_5g.num_qgroups;
+ dev_info->max_num_queues = 0;
+ for (i = RTE_BBDEV_OP_TURBO_DEC; i < RTE_BBDEV_OP_LDPC_ENC;
i++)
should this be i <= ?
Thanks
+ dev_info->max_num_queues += dev_info->num_queues[i];
dev_info->queue_size_lim = ACC100_MAX_QUEUE_DEPTH;
dev_info->hardware_accelerated = true;
dev_info->max_dl_queue_priority =
diff --git a/drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c
b/drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c
index 57b12af..b4982af 100644
--- a/drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c
+++ b/drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c
@@ -379,6 +379,14 @@
if (hw_q_id != FPGA_INVALID_HW_QUEUE_ID)
dev_info->max_num_queues++;
}
+ /* Expose number of queue per operation type */
+ dev_info->num_queues[RTE_BBDEV_OP_NONE] = 0;
+ dev_info->num_queues[RTE_BBDEV_OP_TURBO_DEC] = 0;
+ dev_info->num_queues[RTE_BBDEV_OP_TURBO_ENC] = 0;
+ dev_info->num_queues[RTE_BBDEV_OP_LDPC_DEC] = dev_info-
max_num_queues / 2;
+ dev_info->num_queues[RTE_BBDEV_OP_LDPC_ENC] = dev_info-
max_num_queues / 2;
+ dev_info->queue_priority[RTE_BBDEV_OP_LDPC_DEC] = 1;
+ dev_info->queue_priority[RTE_BBDEV_OP_LDPC_ENC] = 1;
}
/**
diff --git a/drivers/baseband/fpga_lte_fec/fpga_lte_fec.c
b/drivers/baseband/fpga_lte_fec/fpga_lte_fec.c
index 2a330c4..dc7f47
Re: [PATCH v4 3/7] bbdev: add device info on queue topology
On 7/6/22 2:12 PM, Chautru, Nicolas wrote:
Hi Tom,
-Original Message-
From: Tom Rix
Subject: Re: [PATCH v4 3/7] bbdev: add device info on queue topology
On 7/5/22 5:23 PM, Nicolas Chautru wrote:
Adding more options in the API to expose the number of queues exposed
and related priority.
Signed-off-by: Nicolas Chautru
---
lib/bbdev/rte_bbdev.h | 4
1 file changed, 4 insertions(+)
diff --git a/lib/bbdev/rte_bbdev.h b/lib/bbdev/rte_bbdev.h index
9b1ffa4..ac941d6 100644
--- a/lib/bbdev/rte_bbdev.h
+++ b/lib/bbdev/rte_bbdev.h
@@ -289,6 +289,10 @@ struct rte_bbdev_driver_info {
/** Maximum number of queues supported by the device */
unsigned int max_num_queues;
+ /** Maximum number of queues supported per operation type */
+ unsigned int num_queues[RTE_BBDEV_OP_TYPE_PADDED_MAX];
+ /** Priority level supported per operation type */
+ unsigned int queue_priority[RTE_BBDEV_OP_TYPE_PADDED_MAX];
It is better to add new elements to the end of a structure for better backward
compatibility
All that serie is not ABI compatible (sizes change etc...). I don’t believe
there is such a recommendation, is there?
Depends on what users expect, a dynamically linked old application would
at best core here. If the elements were added to the end, yes the size
would change but the old dynamically linked application would not use
them. Dynamically linking is nice because problems in the library can
be fixed and shipped without forcing the user recompile. Though the
user may not realize it, this change forces them to recompile.
Tom
Tom
/** Queue size limit (queue size must also be power of 2) */
uint32_t queue_size_lim;
/** Set if device off-loads operation to hardware */
Re: [PATCH v4 2/7] bbdev: add device status info
On 7/6/22 2:16 PM, Chautru, Nicolas wrote:
-Original Message-
From: Tom Rix
Subject: Re: [PATCH v4 2/7] bbdev: add device status info
On 7/5/22 5:23 PM, Nicolas Chautru wrote:
Added device status information, so that the PMD can expose
information related to the underlying accelerator device status.
Minor order change in structure to fit into padding hole.
Signed-off-by: Nicolas Chautru
---
drivers/baseband/acc100/rte_acc100_pmd.c | 1 +
drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c | 1 +
drivers/baseband/fpga_lte_fec/fpga_lte_fec.c | 1 +
drivers/baseband/la12xx/bbdev_la12xx.c | 1 +
drivers/baseband/null/bbdev_null.c | 1 +
drivers/baseband/turbo_sw/bbdev_turbo_software.c | 1 +
lib/bbdev/rte_bbdev.c | 24 +++
lib/bbdev/rte_bbdev.h | 35
--
lib/bbdev/version.map | 6
9 files changed, 69 insertions(+), 2 deletions(-)
diff --git a/drivers/baseband/acc100/rte_acc100_pmd.c
b/drivers/baseband/acc100/rte_acc100_pmd.c
index de7e4bc..17ba798 100644
--- a/drivers/baseband/acc100/rte_acc100_pmd.c
+++ b/drivers/baseband/acc100/rte_acc100_pmd.c
@@ -1060,6 +1060,7 @@
/* Read and save the populated config from ACC100 registers */
fetch_acc100_config(dev);
+ dev_info->device_status = RTE_BBDEV_DEV_NOT_SUPPORTED;
/* This isn't ideal because it reports the maximum number of queues
but
* does not provide info on how many can be uplink/downlink or
different diff --git
a/drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c
b/drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c
index 82ae6ba..57b12af 100644
--- a/drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c
+++ b/drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c
@@ -369,6 +369,7 @@
dev_info->capabilities = bbdev_capabilities;
dev_info->cpu_flag_reqs = NULL;
dev_info->data_endianness = RTE_LITTLE_ENDIAN;
+ dev_info->device_status = RTE_BBDEV_DEV_NOT_SUPPORTED;
/* Calculates number of queues assigned to device */
dev_info->max_num_queues = 0;
diff --git a/drivers/baseband/fpga_lte_fec/fpga_lte_fec.c
b/drivers/baseband/fpga_lte_fec/fpga_lte_fec.c
index 21d3529..2a330c4 100644
--- a/drivers/baseband/fpga_lte_fec/fpga_lte_fec.c
+++ b/drivers/baseband/fpga_lte_fec/fpga_lte_fec.c
@@ -645,6 +645,7 @@ struct __rte_cache_aligned fpga_queue {
dev_info->capabilities = bbdev_capabilities;
dev_info->cpu_flag_reqs = NULL;
dev_info->data_endianness = RTE_LITTLE_ENDIAN;
+ dev_info->device_status = RTE_BBDEV_DEV_NOT_SUPPORTED;
/* Calculates number of queues assigned to device */
dev_info->max_num_queues = 0;
diff --git a/drivers/baseband/la12xx/bbdev_la12xx.c
b/drivers/baseband/la12xx/bbdev_la12xx.c
index 4d1bd16..c1f88c6 100644
--- a/drivers/baseband/la12xx/bbdev_la12xx.c
+++ b/drivers/baseband/la12xx/bbdev_la12xx.c
@@ -100,6 +100,7 @@ struct bbdev_la12xx_params {
dev_info->capabilities = bbdev_capabilities;
dev_info->cpu_flag_reqs = NULL;
dev_info->min_alignment = 64;
+ dev_info->device_status = RTE_BBDEV_DEV_NOT_SUPPORTED;
rte_bbdev_log_debug("got device info from %u", dev->data->dev_id);
}
diff --git a/drivers/baseband/null/bbdev_null.c
b/drivers/baseband/null/bbdev_null.c
index 248e129..94a1976 100644
--- a/drivers/baseband/null/bbdev_null.c
+++ b/drivers/baseband/null/bbdev_null.c
@@ -82,6 +82,7 @@ struct bbdev_queue {
* here for code completeness.
*/
dev_info->data_endianness = RTE_LITTLE_ENDIAN;
+ dev_info->device_status = RTE_BBDEV_DEV_NOT_SUPPORTED;
rte_bbdev_log_debug("got device info from %u", dev->data->dev_id);
}
diff --git a/drivers/baseband/turbo_sw/bbdev_turbo_software.c
b/drivers/baseband/turbo_sw/bbdev_turbo_software.c
index af7bc41..dbc5524 100644
--- a/drivers/baseband/turbo_sw/bbdev_turbo_software.c
+++ b/drivers/baseband/turbo_sw/bbdev_turbo_software.c
@@ -254,6 +254,7 @@ struct turbo_sw_queue {
dev_info->min_alignment = 64;
dev_info->harq_buffer_size = 0;
dev_info->data_endianness = RTE_LITTLE_ENDIAN;
+ dev_info->device_status = RTE_BBDEV_DEV_NOT_SUPPORTED;
rte_bbdev_log_debug("got device info from %u\n", dev->data-
dev_id);
}
diff --git a/lib/bbdev/rte_bbdev.c b/lib/bbdev/rte_bbdev.c index
22bd894..555bda9 100644
--- a/lib/bbdev/rte_bbdev.c
+++ b/lib/bbdev/rte_bbdev.c
@@ -25,6 +25,8 @@
/* Number of supported operation types */
#define BBDEV_OP_TYPE_COUNT 5
+/* Number of supported device status */ #define
+BBDEV_DEV_STATUS_COUNT 9
/* BBDev library logging ID */
RTE_LOG_REGISTER_DEFAULT(bbdev_logtype, NOTICE); @@ -1132,3
+1134,25
@@ s
Re: [PATCH v2 1/5] baseband/acc100: introduce PMD for ACC101
This is a good start reusing code, but I think it needs to do more reuse. These cards should be very close and likely represent a family of cards. On 4/27/22 11:16 AM, Nicolas Chautru wrote: Support for ACC101 as a derivative of ACC100. Reusing existing code when possible. Signed-off-by: Nicolas Chautru --- doc/guides/bbdevs/acc101.rst | 237 +++ doc/guides/bbdevs/features/acc101.ini| 13 ++ doc/guides/bbdevs/index.rst | 1 + doc/guides/rel_notes/release_22_07.rst | 4 + drivers/baseband/acc100/rte_acc100_pmd.c | 194 - drivers/baseband/acc100/rte_acc100_pmd.h | 6 + drivers/baseband/acc100/rte_acc101_pmd.h | 61 7 files changed, 511 insertions(+), 5 deletions(-) create mode 100644 doc/guides/bbdevs/acc101.rst create mode 100644 doc/guides/bbdevs/features/acc101.ini create mode 100644 drivers/baseband/acc100/rte_acc101_pmd.h diff --git a/doc/guides/bbdevs/acc101.rst b/doc/guides/bbdevs/acc101.rst new file mode 100644 index 000..46c310b --- /dev/null +++ b/doc/guides/bbdevs/acc101.rst @@ -0,0 +1,237 @@ +.. SPDX-License-Identifier: BSD-3-Clause +Copyright(c) 2020 Intel Corporation + +Intel(R) ACC101 5G/4G FEC Poll Mode Driver +== + +The BBDEV ACC101 5G/4G FEC poll mode driver (PMD) supports an +implementation of a VRAN FEC wireless acceleration function. +This device is also known as Mount Cirrus. +This is a follow-up to Mount Bryce (ACC100) and includes fixes, improved +feature set for error scenarios and performance capacity increase. includes fixes, better error handling and increased performance. A quick look at acc100.rst and the bulk of acc101.rst looks the same. Consider a user of the acc100 is upgrading to acc101, they will want to know what is the same and what has changed and test accordingly. These two documents should be combined. + +Features + + +ACC101 5G/4G FEC PMD supports the following features: + +- LDPC Encode in the DL (5GNR) +- LDPC Decode in the UL (5GNR) +- Turbo Encode in the DL (4G) +- Turbo Decode in the UL (4G) +- 16 VFs per PF (physical device) +- Maximum of 128 queues per VF +- PCIe Gen-3 x16 Interface +- MSI +- SR-IOV + +ACC101 5G/4G FEC PMD supports the following BBDEV capabilities: + +* For the LDPC encode operation: + - ``RTE_BBDEV_LDPC_CRC_24B_ATTACH`` : set to attach CRC24B to CB(s) + - ``RTE_BBDEV_LDPC_RATE_MATCH`` : if set then do not do Rate Match bypass + - ``RTE_BBDEV_LDPC_INTERLEAVER_BYPASS`` : if set then bypass interleaver + +* For the LDPC decode operation: + - ``RTE_BBDEV_LDPC_CRC_TYPE_24B_CHECK`` : check CRC24B from CB(s) + - ``RTE_BBDEV_LDPC_ITERATION_STOP_ENABLE`` : disable early termination + - ``RTE_BBDEV_LDPC_CRC_TYPE_24B_DROP`` : drops CRC24B bits appended while decoding + - ``RTE_BBDEV_LDPC_HQ_COMBINE_IN_ENABLE`` : provides an input for HARQ combining + - ``RTE_BBDEV_LDPC_HQ_COMBINE_OUT_ENABLE`` : provides an input for HARQ combining + - ``RTE_BBDEV_LDPC_INTERNAL_HARQ_MEMORY_IN_ENABLE`` : HARQ memory input is internal + - ``RTE_BBDEV_LDPC_INTERNAL_HARQ_MEMORY_OUT_ENABLE`` : HARQ memory output is internal + - ``RTE_BBDEV_LDPC_INTERNAL_HARQ_MEMORY_LOOPBACK`` : loopback data to/from HARQ memory + - ``RTE_BBDEV_LDPC_INTERNAL_HARQ_MEMORY_FILLERS`` : HARQ memory includes the fillers bits + - ``RTE_BBDEV_LDPC_DEC_SCATTER_GATHER`` : supports scatter-gather for input/output data + - ``RTE_BBDEV_LDPC_HARQ_6BIT_COMPRESSION`` : supports compression of the HARQ input/output + - ``RTE_BBDEV_LDPC_LLR_COMPRESSION`` : supports LLR input compression + +* For the turbo encode operation: + - ``RTE_BBDEV_TURBO_CRC_24B_ATTACH`` : set to attach CRC24B to CB(s) + - ``RTE_BBDEV_TURBO_RATE_MATCH`` : if set then do not do Rate Match bypass + - ``RTE_BBDEV_TURBO_ENC_INTERRUPTS`` : set for encoder dequeue interrupts + - ``RTE_BBDEV_TURBO_RV_INDEX_BYPASS`` : set to bypass RV index + - ``RTE_BBDEV_TURBO_ENC_SCATTER_GATHER`` : supports scatter-gather for input/output data + +* For the turbo decode operation: + - ``RTE_BBDEV_TURBO_CRC_TYPE_24B`` : check CRC24B from CB(s) + - ``RTE_BBDEV_TURBO_SUBBLOCK_DEINTERLEAVE`` : perform subblock de-interleave + - ``RTE_BBDEV_TURBO_DEC_INTERRUPTS`` : set for decoder dequeue interrupts + - ``RTE_BBDEV_TURBO_NEG_LLR_1_BIT_IN`` : set if negative LLR encoder i/p is supported + - ``RTE_BBDEV_TURBO_POS_LLR_1_BIT_IN`` : set if positive LLR encoder i/p is supported + - ``RTE_BBDEV_TURBO_DEC_TB_CRC_24B_KEEP`` : keep CRC24B bits appended while decoding + - ``RTE_BBDEV_TURBO_DEC_CRC_24B_DROP`` : option to drop the code block CRC after decoding + - ``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 granul
Re: [PATCH v2 2/5] baseband/acc100: modify validation code for ACC101
On 4/27/22 11:17 AM, Nicolas Chautru wrote:
The validation requirement is different for the two
devices.
Signed-off-by: Nicolas Chautru
---
drivers/baseband/acc100/rte_acc100_pmd.c | 40 ++--
1 file changed, 28 insertions(+), 12 deletions(-)
diff --git a/drivers/baseband/acc100/rte_acc100_pmd.c
b/drivers/baseband/acc100/rte_acc100_pmd.c
index fca27ef..daf2ce0 100644
--- a/drivers/baseband/acc100/rte_acc100_pmd.c
+++ b/drivers/baseband/acc100/rte_acc100_pmd.c
@@ -1293,6 +1293,14 @@
return (q->d->device_variant == ACC100_VARIANT);
}
+#ifdef RTE_LIBRTE_BBDEV_DEBUG
+static inline bool
+validate_op_required(struct acc100_queue *q)
There isn't an #else case so this will fail to build.
This i believe could be another function in private data fops i
suggested in the first patch.
Tom
+{
+ return is_acc100(q);
+}
+#endif
+
Re: [PATCH v2 3/5] baseband/acc100: configuration of ACC101 from PF
On 4/27/22 11:17 AM, Nicolas Chautru wrote:
Adding companion function specific to ACC100 and it
can be called from bbdev-test when running from PF.
Signed-off-by: Nicolas Chautru
---
app/test-bbdev/test_bbdev_perf.c | 57 ++
drivers/baseband/acc100/rte_acc100_cfg.h | 17 ++
drivers/baseband/acc100/rte_acc100_pmd.c | 302 +++
drivers/baseband/acc100/version.map | 2 +-
4 files changed, 377 insertions(+), 1 deletion(-)
diff --git a/app/test-bbdev/test_bbdev_perf.c b/app/test-bbdev/test_bbdev_perf.c
index 0fa119a..baf5f6d 100644
--- a/app/test-bbdev/test_bbdev_perf.c
+++ b/app/test-bbdev/test_bbdev_perf.c
@@ -63,6 +63,8 @@
#define ACC100_QMGR_INVALID_IDX -1
#define ACC100_QMGR_RR 1
#define ACC100_QOS_GBR 0
+#define ACC101PF_DRIVER_NAME ("intel_acc101_pf")
+#define ACC101VF_DRIVER_NAME ("intel_acc101_vf")
A dup from patch 1
#endif
#define OPS_CACHE_SIZE 256U
@@ -765,6 +767,61 @@ typedef int (test_case_function)(struct active_device *ad,
"Failed to configure ACC100 PF for bbdev %s",
info->dev_name);
}
+ if ((get_init_device() == true) &&
+ (!strcmp(info->drv.driver_name, ACC101PF_DRIVER_NAME))) {
+ struct rte_acc100_conf conf;
Mixing up acc100 and acc101 ?
If this actually works, combine the two.
+ unsigned int i;
+
+ printf("Configure ACC101 FEC Driver %s with default values\n",
+ info->drv.driver_name);
+
+ /* clear default configuration before initialization */
+ memset(&conf, 0, sizeof(struct rte_acc100_conf));
+
+ /* Always set in PF mode for built-in configuration */
+ conf.pf_mode_en = true;
+ for (i = 0; i < RTE_ACC100_NUM_VFS; ++i) {
+ conf.arb_dl_4g[i].gbr_threshold1 = ACC100_QOS_GBR;
+ conf.arb_dl_4g[i].gbr_threshold1 = ACC100_QOS_GBR;
+ conf.arb_dl_4g[i].round_robin_weight = ACC100_QMGR_RR;
+ conf.arb_ul_4g[i].gbr_threshold1 = ACC100_QOS_GBR;
+ conf.arb_ul_4g[i].gbr_threshold1 = ACC100_QOS_GBR;
+ conf.arb_ul_4g[i].round_robin_weight = ACC100_QMGR_RR;
+ conf.arb_dl_5g[i].gbr_threshold1 = ACC100_QOS_GBR;
+ conf.arb_dl_5g[i].gbr_threshold1 = ACC100_QOS_GBR;
+ conf.arb_dl_5g[i].round_robin_weight = ACC100_QMGR_RR;
+ conf.arb_ul_5g[i].gbr_threshold1 = ACC100_QOS_GBR;
+ conf.arb_ul_5g[i].gbr_threshold1 = ACC100_QOS_GBR;
+ conf.arb_ul_5g[i].round_robin_weight = ACC100_QMGR_RR;
+ }
+
+ conf.input_pos_llr_1_bit = true;
+ conf.output_pos_llr_1_bit = true;
+ conf.num_vf_bundles = 1; /**< Number of VF bundles to setup */
+
+ conf.q_ul_4g.num_qgroups = ACC100_QMGR_NUM_QGS;
+ conf.q_ul_4g.first_qgroup_index = ACC100_QMGR_INVALID_IDX;
+ conf.q_ul_4g.num_aqs_per_groups = ACC100_QMGR_NUM_AQS;
+ conf.q_ul_4g.aq_depth_log2 = ACC100_QMGR_AQ_DEPTH;
+ conf.q_dl_4g.num_qgroups = ACC100_QMGR_NUM_QGS;
+ conf.q_dl_4g.first_qgroup_index = ACC100_QMGR_INVALID_IDX;
+ conf.q_dl_4g.num_aqs_per_groups = ACC100_QMGR_NUM_AQS;
+ conf.q_dl_4g.aq_depth_log2 = ACC100_QMGR_AQ_DEPTH;
+ conf.q_ul_5g.num_qgroups = ACC100_QMGR_NUM_QGS;
+ conf.q_ul_5g.first_qgroup_index = ACC100_QMGR_INVALID_IDX;
+ conf.q_ul_5g.num_aqs_per_groups = ACC100_QMGR_NUM_AQS;
+ conf.q_ul_5g.aq_depth_log2 = ACC100_QMGR_AQ_DEPTH;
+ conf.q_dl_5g.num_qgroups = ACC100_QMGR_NUM_QGS;
+ conf.q_dl_5g.first_qgroup_index = ACC100_QMGR_INVALID_IDX;
+ conf.q_dl_5g.num_aqs_per_groups = ACC100_QMGR_NUM_AQS;
+ conf.q_dl_5g.aq_depth_log2 = ACC100_QMGR_AQ_DEPTH;
+
+ /* setup PF with configuration information */
+ ret = rte_acc101_configure(info->dev_name, &conf);
+ TEST_ASSERT_SUCCESS(ret,
+ "Failed to configure ACC101 PF for bbdev %s",
+ info->dev_name);
+ }
#endif
/* Let's refresh this now this is configured */
rte_bbdev_info_get(dev_id, info);
diff --git a/drivers/baseband/acc100/rte_acc100_cfg.h
b/drivers/baseband/acc100/rte_acc100_cfg.h
index d233e42..2e3c43f 100644
--- a/drivers/baseband/acc100/rte_acc100_cfg.h
+++ b/drivers/baseband/acc100/rte_acc100_cfg.h
This file marks its API as experimental though the acc100 has been used
in production for some time.
It is important that the API be stable.
Is this an oversight ?
Or what is needed to stabilize the API ?
@@ -106,6 +106,23 @@ struct rte_acc100
Re: [PATCH v2 4/5] baseband/acc100: start explicitly PF Monitor from PMD
On 4/27/22 11:17 AM, Nicolas Chautru wrote:
Ensure the performance monitor is restarted in case this
is reset after VF FLR.
Signed-off-by: Nicolas Chautru
---
drivers/baseband/acc100/rte_acc100_pmd.c | 4
drivers/baseband/acc100/rte_acc100_pmd.h | 6 ++
2 files changed, 10 insertions(+)
diff --git a/drivers/baseband/acc100/rte_acc100_pmd.c
b/drivers/baseband/acc100/rte_acc100_pmd.c
index b03cedc..b588f5f 100644
--- a/drivers/baseband/acc100/rte_acc100_pmd.c
+++ b/drivers/baseband/acc100/rte_acc100_pmd.c
@@ -263,6 +263,10 @@
& 0xF;
}
+ /* Start Pmon */
+ acc100_reg_write(d, reg_addr->pmon_ctrl_a, 0x2);
+ acc100_reg_write(d, reg_addr->pmon_ctrl_b, 0x2);
This looks like an acc100 bug fix, so it should be split from the acc101
pathset.
Where this code is added is fetch_acc100_config, a function that does reads.
Though convenient, this is likely not the best place to put the writes
Tom
+
/* Read PF mode */
if (d->pf_device) {
reg_mode = acc100_reg_read(d, HWPfHiPfMode);
diff --git a/drivers/baseband/acc100/rte_acc100_pmd.h
b/drivers/baseband/acc100/rte_acc100_pmd.h
index 6438031..f126cc0 100644
--- a/drivers/baseband/acc100/rte_acc100_pmd.h
+++ b/drivers/baseband/acc100/rte_acc100_pmd.h
@@ -475,6 +475,8 @@ struct acc100_registry_addr {
unsigned int depth_log1_offset;
unsigned int qman_group_func;
unsigned int ddr_range;
+ unsigned int pmon_ctrl_a;
+ unsigned int pmon_ctrl_b;
};
/* Structure holding registry addresses for PF */
@@ -504,6 +506,8 @@ struct acc100_registry_addr {
.depth_log1_offset = HWPfQmgrGrpDepthLog21Vf,
.qman_group_func = HWPfQmgrGrpFunction0,
.ddr_range = HWPfDmaVfDdrBaseRw,
+ .pmon_ctrl_a = HWPfPermonACntrlRegVf,
+ .pmon_ctrl_b = HWPfPermonBCntrlRegVf,
};
/* Structure holding registry addresses for VF */
@@ -533,6 +537,8 @@ struct acc100_registry_addr {
.depth_log1_offset = HWVfQmgrGrpDepthLog21Vf,
.qman_group_func = HWVfQmgrGrpFunction0Vf,
.ddr_range = HWVfDmaDdrBaseRangeRoVf,
+ .pmon_ctrl_a = HWVfPmACntrlRegVf,
+ .pmon_ctrl_b = HWVfPmBCntrlRegVf,
};
/* Structure associated with each queue. */
Re: [PATCH v2 5/5] baseband/acc100: add protection for some negative scenario
On 4/27/22 11:17 AM, Nicolas Chautru wrote:
Catch exception in PMD in case of invalid input parameter.
It is not clear if this is 1 fix or 2.
But it does look like an acc100 fix so it should be split from the
acc101 patchset.
Signed-off-by: Nicolas Chautru
---
drivers/baseband/acc100/rte_acc100_pmd.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/baseband/acc100/rte_acc100_pmd.c
b/drivers/baseband/acc100/rte_acc100_pmd.c
index b588f5f..a13966c 100644
--- a/drivers/baseband/acc100/rte_acc100_pmd.c
+++ b/drivers/baseband/acc100/rte_acc100_pmd.c
@@ -1241,6 +1241,8 @@
return (bg == 1 ? ACC100_K0_3_1 : ACC100_K0_3_2) * z_c;
}
/* LBRM case - includes a division by N */
+ if (unlikely(z_c == 0))
+ return 0;
This check should be moved to earlier, if 'n' is set to 0 in the
statement above, there is div by 0 later
Tom
if (rv_index == 1)
return (((bg == 1 ? ACC100_K0_1_1 : ACC100_K0_1_2) * n_cb)
/ n) * z_c;
@@ -1916,6 +1918,10 @@ static inline uint32_t hq_index(uint32_t offset)
/* Soft output */
if (check_bit(op->turbo_dec.op_flags, RTE_BBDEV_TURBO_SOFT_OUTPUT)) {
+ if (op->turbo_dec.soft_output.data == 0) {
+ rte_bbdev_log(ERR, "Soft output is not defined");
+ return -1;
+ }
if (check_bit(op->turbo_dec.op_flags,
RTE_BBDEV_TURBO_EQUALIZER))
*s_out_length = e;
Re: [PATCH v2 1/5] baseband/acc100: introduce PMD for ACC101
On 5/9/22 2:23 PM, Chautru, Nicolas wrote: Hi Tom, -Original Message- From: Tom Rix Sent: Sunday, May 8, 2022 6:03 AM To: Chautru, Nicolas ; dev@dpdk.org; gak...@marvell.com Cc: tho...@monjalon.net; Kinsella, Ray ; Richardson, Bruce ; hemant.agra...@nxp.com; Zhang, Mingshan ; david.march...@redhat.com Subject: Re: [PATCH v2 1/5] baseband/acc100: introduce PMD for ACC101 This is a good start reusing code, but I think it needs to do more reuse. These cards should be very close and likely represent a family of cards. On 4/27/22 11:16 AM, Nicolas Chautru wrote: Support for ACC101 as a derivative of ACC100. Reusing existing code when possible. Signed-off-by: Nicolas Chautru --- doc/guides/bbdevs/acc101.rst | 237 +++ doc/guides/bbdevs/features/acc101.ini| 13 ++ doc/guides/bbdevs/index.rst | 1 + doc/guides/rel_notes/release_22_07.rst | 4 + drivers/baseband/acc100/rte_acc100_pmd.c | 194 - drivers/baseband/acc100/rte_acc100_pmd.h | 6 + drivers/baseband/acc100/rte_acc101_pmd.h | 61 7 files changed, 511 insertions(+), 5 deletions(-) create mode 100644 doc/guides/bbdevs/acc101.rst create mode 100644 doc/guides/bbdevs/features/acc101.ini create mode 100644 drivers/baseband/acc100/rte_acc101_pmd.h diff --git a/doc/guides/bbdevs/acc101.rst b/doc/guides/bbdevs/acc101.rst new file mode 100644 index 000..46c310b --- /dev/null +++ b/doc/guides/bbdevs/acc101.rst @@ -0,0 +1,237 @@ +.. SPDX-License-Identifier: BSD-3-Clause +Copyright(c) 2020 Intel Corporation + +Intel(R) ACC101 5G/4G FEC Poll Mode Driver +== + +The BBDEV ACC101 5G/4G FEC poll mode driver (PMD) supports an +implementation of a VRAN FEC wireless acceleration function. +This device is also known as Mount Cirrus. +This is a follow-up to Mount Bryce (ACC100) and includes fixes, +improved feature set for error scenarios and performance capacity increase. includes fixes, better error handling and increased performance. A quick look at acc100.rst and the bulk of acc101.rst looks the same. Consider a user of the acc100 is upgrading to acc101, they will want to know what is the same and what has changed and test accordingly. These two documents should be combined. Well in term of documentation, for the users it helps to be able to follow steps as they are for a given variant. As opposed to have to have multiple options through the document when using ACC100 vs ACC101. Except if they are other objections, I would see this more useful for the user as is and less source of errors. My perspective is having existing acc100 users that are upgrading and/or having to support both acc100 and acc101 for a very long time. In the first case users of existing acc100 users will want to know only the parts that have changed. In the second, later changes that are common to both acc100 and acc101 and later accXXX will be have to fixed in multiple places. As myself or someone at Red Hat will be on the hook for both, I would prefer if the refactoring of the common parts acc100,acc101 were in good shape over the expediency of having acc101 sooner. + +Features + + index 000..0e2c21a --- /dev/null +++ b/doc/guides/bbdevs/features/acc101.ini @@ -0,0 +1,13 @@ +; +; Supported features of the 'acc101' bbdev driver. +; +; Refer to default.ini for the full list of available PMD features. +; +[Features] +Turbo Decoder (4G) = Y +Turbo Encoder (4G) = Y +LDPC Decoder (5G) = Y +LDPC Encoder (5G) = Y +LLR/HARQ Compression = Y +External DDR Access= Y +HW Accelerated = Y This is the same as acc100.ini, why do we need 2 ? This is a different product, needs to be consistent. ok diff --git a/doc/guides/bbdevs/index.rst b/doc/guides/bbdevs/index.rst index cedd706..e76883c 100644 --- a/doc/guides/bbdevs/index.rst +++ b/doc/guides/bbdevs/index.rst @@ -14,4 +14,5 @@ Baseband Device Drivers fpga_lte_fec fpga_5gnr_fec acc100 +acc101 la12xx diff --git a/doc/guides/rel_notes/release_22_07.rst b/doc/guides/rel_notes/release_22_07.rst index 42a5f2d..ef9906b 100644 --- a/doc/guides/rel_notes/release_22_07.rst +++ b/doc/guides/rel_notes/release_22_07.rst @@ -55,6 +55,10 @@ New Features Also, make sure to start the actual text at the margin. === +* **Added Intel ACC101 baseband PMD.** + + * Added a new baseband PMD for Intel ACC101 device (Mount Cirrus). + * See the :doc:`../bbdevs/acc101` for more details. Removed Items - diff --git a/drivers/baseband/acc100/rte_acc100_pmd.c b/drivers/baseband/acc100/rte_acc100_pmd.c index de7e4bc..fca27ef 100644 --- a/drivers/baseband/acc100/rte_acc100_pmd.c +++ b/drivers/baseband/acc100/rte_acc100_pmd.c @@ -22,6 +22,7 @@ #include #include #include "r
Re: [PATCH v2 3/5] baseband/acc100: configuration of ACC101 from PF
On 5/9/22 2:36 PM, Chautru, Nicolas wrote:
-Original Message-
From: Tom Rix
Sent: Sunday, May 8, 2022 6:38 AM
To: Chautru, Nicolas ; dev@dpdk.org;
gak...@marvell.com
Cc: tho...@monjalon.net; Kinsella, Ray ; Richardson,
Bruce ; hemant.agra...@nxp.com; Zhang,
Mingshan ; david.march...@redhat.com
Subject: Re: [PATCH v2 3/5] baseband/acc100: configuration of ACC101 from
PF
On 4/27/22 11:17 AM, Nicolas Chautru wrote:
Adding companion function specific to ACC100 and it can be called from
bbdev-test when running from PF.
Signed-off-by: Nicolas Chautru
---
app/test-bbdev/test_bbdev_perf.c | 57 ++
drivers/baseband/acc100/rte_acc100_cfg.h | 17 ++
drivers/baseband/acc100/rte_acc100_pmd.c | 302
+++
drivers/baseband/acc100/version.map | 2 +-
4 files changed, 377 insertions(+), 1 deletion(-)
diff --git a/app/test-bbdev/test_bbdev_perf.c
b/app/test-bbdev/test_bbdev_perf.c
index 0fa119a..baf5f6d 100644
--- a/app/test-bbdev/test_bbdev_perf.c
+++ b/app/test-bbdev/test_bbdev_perf.c
@@ -63,6 +63,8 @@
#define ACC100_QMGR_INVALID_IDX -1
#define ACC100_QMGR_RR 1
#define ACC100_QOS_GBR 0
+#define ACC101PF_DRIVER_NAME ("intel_acc101_pf")
+#define ACC101VF_DRIVER_NAME ("intel_acc101_vf")
A dup from patch 1
#endif
#define OPS_CACHE_SIZE 256U
@@ -765,6 +767,61 @@ typedef int (test_case_function)(struct
active_device *ad,
"Failed to configure ACC100 PF for bbdev %s",
info->dev_name);
}
+ if ((get_init_device() == true) &&
+ (!strcmp(info->drv.driver_name, ACC101PF_DRIVER_NAME)))
{
+ struct rte_acc100_conf conf;
Mixing up acc100 and acc101 ?
If this actually works, combine the two.
The configuration file template is the same but not the configuration file. I
can combine a bit more that part.
+ unsigned int i;
+
+ printf("Configure ACC101 FEC Driver %s with default values\n",
+ info->drv.driver_name);
+
+ /* clear default configuration before initialization */
+ memset(&conf, 0, sizeof(struct rte_acc100_conf));
+
+ /* Always set in PF mode for built-in configuration */
+ conf.pf_mode_en = true;
+ for (i = 0; i < RTE_ACC100_NUM_VFS; ++i) {
+ conf.arb_dl_4g[i].gbr_threshold1 =
ACC100_QOS_GBR;
+ conf.arb_dl_4g[i].gbr_threshold1 =
ACC100_QOS_GBR;
+ conf.arb_dl_4g[i].round_robin_weight =
ACC100_QMGR_RR;
+ conf.arb_ul_4g[i].gbr_threshold1 =
ACC100_QOS_GBR;
+ conf.arb_ul_4g[i].gbr_threshold1 =
ACC100_QOS_GBR;
+ conf.arb_ul_4g[i].round_robin_weight =
ACC100_QMGR_RR;
+ conf.arb_dl_5g[i].gbr_threshold1 =
ACC100_QOS_GBR;
+ conf.arb_dl_5g[i].gbr_threshold1 =
ACC100_QOS_GBR;
+ conf.arb_dl_5g[i].round_robin_weight =
ACC100_QMGR_RR;
+ conf.arb_ul_5g[i].gbr_threshold1 =
ACC100_QOS_GBR;
+ conf.arb_ul_5g[i].gbr_threshold1 =
ACC100_QOS_GBR;
+ conf.arb_ul_5g[i].round_robin_weight =
ACC100_QMGR_RR;
+ }
+
+ conf.input_pos_llr_1_bit = true;
+ conf.output_pos_llr_1_bit = true;
+ conf.num_vf_bundles = 1; /**< Number of VF bundles to setup
*/
+
+ conf.q_ul_4g.num_qgroups = ACC100_QMGR_NUM_QGS;
+ conf.q_ul_4g.first_qgroup_index =
ACC100_QMGR_INVALID_IDX;
+ conf.q_ul_4g.num_aqs_per_groups =
ACC100_QMGR_NUM_AQS;
+ conf.q_ul_4g.aq_depth_log2 = ACC100_QMGR_AQ_DEPTH;
+ conf.q_dl_4g.num_qgroups = ACC100_QMGR_NUM_QGS;
+ conf.q_dl_4g.first_qgroup_index =
ACC100_QMGR_INVALID_IDX;
+ conf.q_dl_4g.num_aqs_per_groups =
ACC100_QMGR_NUM_AQS;
+ conf.q_dl_4g.aq_depth_log2 = ACC100_QMGR_AQ_DEPTH;
+ conf.q_ul_5g.num_qgroups = ACC100_QMGR_NUM_QGS;
+ conf.q_ul_5g.first_qgroup_index =
ACC100_QMGR_INVALID_IDX;
+ conf.q_ul_5g.num_aqs_per_groups =
ACC100_QMGR_NUM_AQS;
+ conf.q_ul_5g.aq_depth_log2 = ACC100_QMGR_AQ_DEPTH;
+ conf.q_dl_5g.num_qgroups = ACC100_QMGR_NUM_QGS;
+ conf.q_dl_5g.first_qgroup_index =
ACC100_QMGR_INVALID_IDX;
+ conf.q_dl_5g.num_aqs_per_groups =
ACC100_QMGR_NUM_AQS;
+ conf.q_dl_5g.aq_depth_log2 = ACC100_QMGR_AQ_DEPTH;
+
+ /* setup PF with configuration information */
+ ret = rte_acc101_configure(info->dev_name, &conf);
+ TEST_ASSERT_SUCCESS(ret,
+ "Failed to configure ACC101 PF for bbdev %s",
+
Re: [PATCH v2 5/5] baseband/acc100: add protection for some negative scenario
On 5/9/22 2:45 PM, Chautru, Nicolas wrote:
Hi Tom,
-Original Message-
From: Tom Rix
Sent: Sunday, May 8, 2022 6:56 AM
To: Chautru, Nicolas ; dev@dpdk.org;
gak...@marvell.com
Cc: tho...@monjalon.net; Kinsella, Ray ; Richardson,
Bruce ; hemant.agra...@nxp.com; Zhang,
Mingshan ; david.march...@redhat.com
Subject: Re: [PATCH v2 5/5] baseband/acc100: add protection for some
negative scenario
On 4/27/22 11:17 AM, Nicolas Chautru wrote:
Catch exception in PMD in case of invalid input parameter.
It is not clear if this is 1 fix or 2.
But it does look like an acc100 fix so it should be split from the
acc101 patchset.
What is the concern? This is a different commit related to acc100.
Bisecting patchsets.
A patchset like this that enables a new device should just enable the
new device.
Not enable a new device and random other stuff.
If the patchset had to be reverted, the revert would wipe out the fixes.
That work is done by someone else without deep knowledge or time to
analyze every patchset for misc parts.
The fixes are more important than the new device, so they should be
submitted first.
Tom
Signed-off-by: Nicolas Chautru
---
drivers/baseband/acc100/rte_acc100_pmd.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/baseband/acc100/rte_acc100_pmd.c
b/drivers/baseband/acc100/rte_acc100_pmd.c
index b588f5f..a13966c 100644
--- a/drivers/baseband/acc100/rte_acc100_pmd.c
+++ b/drivers/baseband/acc100/rte_acc100_pmd.c
@@ -1241,6 +1241,8 @@
return (bg == 1 ? ACC100_K0_3_1 : ACC100_K0_3_2)
* z_c;
}
/* LBRM case - includes a division by N */
+ if (unlikely(z_c == 0))
+ return 0;
This check should be moved to earlier, if 'n' is set to 0 in the statement
above,
there is div by 0 later
N is purely a factor of z_c, I don’t see the concern is order.
Tom
if (rv_index == 1)
return (((bg == 1 ? ACC100_K0_1_1 : ACC100_K0_1_2) *
n_cb)
/ n) * z_c;
@@ -1916,6 +1918,10 @@ static inline uint32_t hq_index(uint32_t
offset)
/* Soft output */
if (check_bit(op->turbo_dec.op_flags,
RTE_BBDEV_TURBO_SOFT_OUTPUT))
{
+ if (op->turbo_dec.soft_output.data == 0) {
+ rte_bbdev_log(ERR, "Soft output is not defined");
+ return -1;
+ }
if (check_bit(op->turbo_dec.op_flags,
RTE_BBDEV_TURBO_EQUALIZER))
*s_out_length = e;
Re: [PATCH v3 0/4] drivers/baseband: PMD to support ACC101 device
On 5/16/22 1:48 PM, Nicolas Chautru wrote: v3: Feedback from Tom Rix: missing copyright, refactor bbdev-test section calling the configure companion function for ACC100/101, taking the Pmon commit out which is not directly required. These address some of my comments. The others, mostly around the treating accXXX as a family of devices and refactoring the common parts out have not been. Tom v2: Based on good feedback from Thomas and David, now implementing the ACC101 PMD as a close derivative from existing ACC100 PMD with hooks to have different behaviour based on variant. This prevents code duplication and only rely on different functions and behaviour when hardware requires or support differences. Note that these are pending changes for ACC100 which would be specific to that device and not ACC101 but these can be managed based on the new implementation, ie. is_acc100() etc... (such incremental changes for ACC100 trending 22.11 but confirming this is future proof). The serie also includes commits which were meant for ACC101 but are also valuable for ACC100. v1: This serie introduces the PMD for the new bbdev device ACC101 (aka Mount Cirrus). This is a derivative from previous Mount Bryce ACC100 which includes silicon improvement, bug fixes, capacity improvement for 5GNR and feature improvement. Nicolas Chautru (4): baseband/acc100: introduce PMD for ACC101 baseband/acc100: modify validation code for ACC101 baseband/acc100: configuration of ACC101 from PF baseband/acc100: add protection for some negative scenario app/test-bbdev/test_bbdev_perf.c | 22 +- doc/guides/bbdevs/acc101.rst | 237 ++ doc/guides/bbdevs/features/acc101.ini| 13 + doc/guides/bbdevs/index.rst | 1 + doc/guides/rel_notes/release_22_07.rst | 4 + drivers/baseband/acc100/rte_acc100_cfg.h | 17 + drivers/baseband/acc100/rte_acc100_pmd.c | 542 ++- drivers/baseband/acc100/rte_acc100_pmd.h | 6 + drivers/baseband/acc100/rte_acc101_pmd.h | 65 drivers/baseband/acc100/version.map | 2 +- 10 files changed, 885 insertions(+), 24 deletions(-) create mode 100644 doc/guides/bbdevs/acc101.rst create mode 100644 doc/guides/bbdevs/features/acc101.ini create mode 100644 drivers/baseband/acc100/rte_acc101_pmd.h
Re: [dpdk-dev] [PATCH v2 1/6] bbdev: add capability for CRC16 check
On 9/1/21 8:00 AM, Chautru, Nicolas wrote:
-Original Message-
From: Tom Rix
Sent: Wednesday, September 1, 2021 6:37 AM
To: Chautru, Nicolas ; dev@dpdk.org;
gak...@marvell.com
Cc: tho...@monjalon.net; hemant.agra...@nxp.com; Zhang, Mingshan
; Joshi, Arun
Subject: Re: [PATCH v2 1/6] bbdev: add capability for CRC16 check
On 8/19/21 2:10 PM, Nicolas Chautru wrote:
Adding a missing operation when CRC16
is being used for TB CRC check.
Signed-off-by: Nicolas Chautru
---
app/test-bbdev/test_bbdev_vector.c | 2 ++
doc/guides/prog_guide/bbdev.rst| 3 +++
doc/guides/rel_notes/release_21_11.rst | 1 +
lib/bbdev/rte_bbdev_op.h | 34 ++--
--
4 files changed, 24 insertions(+), 16 deletions(-)
diff --git a/app/test-bbdev/test_bbdev_vector.c
b/app/test-bbdev/test_bbdev_vector.c
index 614dbd1..8d796b1 100644
--- a/app/test-bbdev/test_bbdev_vector.c
+++ b/app/test-bbdev/test_bbdev_vector.c
@@ -167,6 +167,8 @@
*op_flag_value = RTE_BBDEV_LDPC_CRC_TYPE_24B_CHECK;
else if (!strcmp(token, "RTE_BBDEV_LDPC_CRC_TYPE_24B_DROP"))
*op_flag_value = RTE_BBDEV_LDPC_CRC_TYPE_24B_DROP;
+ else if (!strcmp(token, "RTE_BBDEV_LDPC_CRC_TYPE_16_CHECK"))
+ *op_flag_value = RTE_BBDEV_LDPC_CRC_TYPE_16_CHECK;
else if (!strcmp(token,
"RTE_BBDEV_LDPC_DEINTERLEAVER_BYPASS"))
*op_flag_value =
RTE_BBDEV_LDPC_DEINTERLEAVER_BYPASS;
else if (!strcmp(token,
"RTE_BBDEV_LDPC_HQ_COMBINE_IN_ENABLE"))
diff --git a/doc/guides/prog_guide/bbdev.rst
b/doc/guides/prog_guide/bbdev.rst index 9619280..8bd7cba 100644
--- a/doc/guides/prog_guide/bbdev.rst
+++ b/doc/guides/prog_guide/bbdev.rst
@@ -891,6 +891,9 @@ given below.
|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|
++
diff --git a/doc/guides/rel_notes/release_21_11.rst
b/doc/guides/rel_notes/release_21_11.rst
index d707a55..69dd518 100644
--- a/doc/guides/rel_notes/release_21_11.rst
+++ b/doc/guides/rel_notes/release_21_11.rst
@@ -84,6 +84,7 @@ API Changes
Also, make sure to start the actual text at the margin.
===
+* bbdev: Added capability related to more comprehensive CRC options.
ABI Changes
---
diff --git a/lib/bbdev/rte_bbdev_op.h b/lib/bbdev/rte_bbdev_op.h index
f946842..7c44ddd 100644
--- a/lib/bbdev/rte_bbdev_op.h
+++ b/lib/bbdev/rte_bbdev_op.h
@@ -142,51 +142,53 @@ enum rte_bbdev_op_ldpcdec_flag_bitmasks {
RTE_BBDEV_LDPC_CRC_TYPE_24B_CHECK = (1ULL << 1),
/** Set to drop the last CRC bits decoding output */
RTE_BBDEV_LDPC_CRC_TYPE_24B_DROP = (1ULL << 2),
+ /** Set for transport block CRC-16 checking */
+ RTE_BBDEV_LDPC_CRC_TYPE_16_CHECK = (1ULL << 3),
Changing these enums will break the abi backwards.
Why not add the new one at the end ?
To keep all the CRC related flags next to each other for better readability and
logical clarity. The ABI is still marked as experimental.
Ok
Tom
/** Set for bit-level de-interleaver bypass on Rx stream. */
- RTE_BBDEV_LDPC_DEINTERLEAVER_BYPASS = (1ULL << 3),
+ RTE_BBDEV_LDPC_DEINTERLEAVER_BYPASS = (1ULL << 4),
/** Set for HARQ combined input stream enable. */
- RTE_BBDEV_LDPC_HQ_COMBINE_IN_ENABLE = (1ULL << 4),
+ RTE_BBDEV_LDPC_HQ_COMBINE_IN_ENABLE = (1ULL << 5),
/** Set for HARQ combined output stream enable. */
- RTE_BBDEV_LDPC_HQ_COMBINE_OUT_ENABLE = (1ULL << 5),
+ RTE_BBDEV_LDPC_HQ_COMBINE_OUT_ENABLE = (1ULL << 6),
/** Set for LDPC decoder bypass.
* RTE_BBDEV_LDPC_HQ_COMBINE_OUT_ENABLE must be set.
*/
- RTE_BBDEV_LDPC_DECODE_BYPASS = (1ULL << 6),
+ RTE_BBDEV_LDPC_DECODE_BYPASS = (1ULL << 7),
/** Set for soft-output stream enable */
- RTE_BBDEV_LDPC_SOFT_OUT_ENABLE = (1ULL << 7),
+ RTE_BBDEV_LDPC_SOFT_OUT_ENABLE = (1ULL << 8),
/** Set for Rate-Matching bypass on soft-out stream. */
- RTE_BBDEV_LDPC_SOFT_OUT_RM_BYPASS = (1ULL << 8),
+ RTE_BBDEV_LDPC_SOFT_OUT_RM_BYPASS = (1ULL << 9),
/** Set for bit-level de-interleaver bypass on soft-output stream. */
- RTE_BBDEV_LDPC_SOFT_OUT_DEINTERL
Re: [dpdk-dev] [PATCH v2 4/6] baseband/acc100: add support for 4G CRC drop
On 9/7/21 6:04 PM, Chautru, Nicolas wrote:
-Original Message-
From: Tom Rix
Sent: Wednesday, September 1, 2021 7:20 AM
To: Chautru, Nicolas ; dev@dpdk.org;
gak...@marvell.com
Cc: tho...@monjalon.net; hemant.agra...@nxp.com; Zhang, Mingshan
; Joshi, Arun
Subject: Re: [PATCH v2 4/6] baseband/acc100: add support for 4G CRC drop
On 8/19/21 2:10 PM, Nicolas Chautru wrote:
This implements in PMD the option to drop the CB CRC after 4G decoding
to help transport block concatenation.
Signed-off-by: Nicolas Chautru
---
doc/guides/bbdevs/acc100.rst | 1 +
doc/guides/rel_notes/release_21_11.rst | 4
drivers/baseband/acc100/rte_acc100_pmd.c | 12 +---
3 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/doc/guides/bbdevs/acc100.rst
b/doc/guides/bbdevs/acc100.rst index ff0fa4b..9fff6ab 100644
--- a/doc/guides/bbdevs/acc100.rst
+++ b/doc/guides/bbdevs/acc100.rst
@@ -58,6 +58,7 @@ ACC100 5G/4G FEC PMD supports the following BBDEV
capabilities:
- ``RTE_BBDEV_TURBO_NEG_LLR_1_BIT_IN`` : set if negative LLR
encoder i/p is supported
- ``RTE_BBDEV_TURBO_POS_LLR_1_BIT_IN`` : set if positive LLR encoder
i/p is supported
- ``RTE_BBDEV_TURBO_DEC_TB_CRC_24B_KEEP`` : keep CRC24B bits
appended while decoding
+ - ``RTE_BBDEV_TURBO_DEC_CRC_24B_DROP`` : option to drop the code
+ block CRC after decoding
- ``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 diff --git a/doc/guides/rel_notes/release_21_11.rst
b/doc/guides/rel_notes/release_21_11.rst
index 8ca59b7..f7843bc 100644
--- a/doc/guides/rel_notes/release_21_11.rst
+++ b/doc/guides/rel_notes/release_21_11.rst
@@ -59,6 +59,10 @@ New Features
Added support for more comprehensive CRC options.
+* **Updated the ACC100 bbdev PMD.**
+
+ Added support for more comprehensive CRC options.
+
Removed Items
-
diff --git a/drivers/baseband/acc100/rte_acc100_pmd.c
b/drivers/baseband/acc100/rte_acc100_pmd.c
index 68ba523..891be81 100644
--- a/drivers/baseband/acc100/rte_acc100_pmd.c
+++ b/drivers/baseband/acc100/rte_acc100_pmd.c
@@ -980,6 +980,7 @@
RTE_BBDEV_TURBO_NEG_LLR_1_BIT_IN |
RTE_BBDEV_TURBO_MAP_DEC |
RTE_BBDEV_TURBO_DEC_TB_CRC_24B_KEEP |
+
RTE_BBDEV_TURBO_DEC_CRC_24B_DROP |
RTE_BBDEV_TURBO_DEC_SCATTER_GATHER,
.max_llr_modulus = INT8_MAX,
.num_buffers_src =
@@ -1708,8 +1709,12 @@
}
if ((op->turbo_dec.code_block_mode ==
RTE_BBDEV_TRANSPORT_BLOCK)
- && !check_bit(op->turbo_dec.op_flags,
- RTE_BBDEV_TURBO_DEC_TB_CRC_24B_KEEP))
+ && !check_bit(op->turbo_dec.op_flags,
+ RTE_BBDEV_TURBO_DEC_TB_CRC_24B_KEEP))
+ crc24_overlap = 24;
+ if ((op->turbo_dec.code_block_mode == RTE_BBDEV_CODE_BLOCK)
These two if-statements can be combined.
They could but really when I tried that became arguably unreadable, I thought
it was still better this way.
Ok
Tom
+ && check_bit(op->turbo_dec.op_flags,
+ RTE_BBDEV_TURBO_DEC_CRC_24B_DROP))
crc24_overlap = 24;
/* Calculates circular buffer size.
@@ -1744,7 +1749,8 @@
next_triplet = acc100_dma_fill_blk_type_out(
desc, h_output, *h_out_offset,
- k >> 3, next_triplet,
ACC100_DMA_BLKID_OUT_HARD);
+ (k - crc24_overlap) >> 3, next_triplet,
crc24_overlap had been set before this patch in the above if-statement for
crc_24b_keep.
so this looks like a bug.
If it is a bug, it should be separated out as its own patch.
Ok fair enough, will do. Thanks
Tom
+ ACC100_DMA_BLKID_OUT_HARD);
if (unlikely(next_triplet < 0)) {
rte_bbdev_log(ERR,
"Mismatch between data to process and
mbuf data length in
bbdev_op: %p",
Re: [dpdk-dev] [PATCH v1] baseband/acc100: fix 4GUL outbound size when CRC is dropped
On 9/7/21 6:39 PM, Nicolas Chautru wrote:
This patch fixes the issue by adjusting the outbound size after
turbodecoding when the appended CRC is meant to be dropped.
Fixes: f404dfe35cc3 ("baseband/acc100: support 4G processing")
Cc: sta...@dpdk.org
Signed-off-by: Nicolas Chautru
---
drivers/baseband/acc100/rte_acc100_pmd.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/baseband/acc100/rte_acc100_pmd.c
b/drivers/baseband/acc100/rte_acc100_pmd.c
index 68ba523..b0485e7 100644
--- a/drivers/baseband/acc100/rte_acc100_pmd.c
+++ b/drivers/baseband/acc100/rte_acc100_pmd.c
@@ -1744,7 +1744,8 @@
next_triplet = acc100_dma_fill_blk_type_out(
desc, h_output, *h_out_offset,
- k >> 3, next_triplet, ACC100_DMA_BLKID_OUT_HARD);
+ (k - crc24_overlap) >> 3, next_triplet,
+ ACC100_DMA_BLKID_OUT_HARD);
if (unlikely(next_triplet < 0)) {
rte_bbdev_log(ERR,
"Mismatch between data to process and mbuf data
length in bbdev_op: %p",
Thanks for this change, looks good.
Reviewed-by: Tom Rix
Re: [dpdk-dev] [PATCH v3 1/6] bbdev: add capability for CRC16 check
catter-gather functionality. */ - RTE_BBDEV_LDPC_DEC_SCATTER_GATHER = (1ULL << 12), + RTE_BBDEV_LDPC_DEC_SCATTER_GATHER = (1ULL << 13), /** Set if a device supports input/output HARQ compression. */ - RTE_BBDEV_LDPC_HARQ_6BIT_COMPRESSION = (1ULL << 13), + RTE_BBDEV_LDPC_HARQ_6BIT_COMPRESSION = (1ULL << 14), /** Set if a device supports input LLR compression. */ - RTE_BBDEV_LDPC_LLR_COMPRESSION = (1ULL << 14), + RTE_BBDEV_LDPC_LLR_COMPRESSION = (1ULL << 15), /** Set if a device supports HARQ input from * device's internal memory. */ - RTE_BBDEV_LDPC_INTERNAL_HARQ_MEMORY_IN_ENABLE = (1ULL << 15), + RTE_BBDEV_LDPC_INTERNAL_HARQ_MEMORY_IN_ENABLE = (1ULL << 16), /** Set if a device supports HARQ output to * device's internal memory. */ - RTE_BBDEV_LDPC_INTERNAL_HARQ_MEMORY_OUT_ENABLE = (1ULL << 16), + RTE_BBDEV_LDPC_INTERNAL_HARQ_MEMORY_OUT_ENABLE = (1ULL << 17), /** Set if a device supports loop-back access to * HARQ internal memory. Intended for troubleshooting. */ - RTE_BBDEV_LDPC_INTERNAL_HARQ_MEMORY_LOOPBACK = (1ULL << 17), + RTE_BBDEV_LDPC_INTERNAL_HARQ_MEMORY_LOOPBACK = (1ULL << 18), /** Set if a device includes LLR filler bits in the circular buffer * for HARQ memory. If not set, it is assumed the filler bits are not * in HARQ memory and handled directly by the LDPC decoder. */ - RTE_BBDEV_LDPC_INTERNAL_HARQ_MEMORY_FILLERS = (1ULL << 18) + RTE_BBDEV_LDPC_INTERNAL_HARQ_MEMORY_FILLERS = (1ULL << 19) The fiddling in the middle is fine since bbdev api is experimental Look good. Reviewed-by: Tom Rix }; /** Flags for LDPC encoder operation and capability structure */
Re: [dpdk-dev] [PATCH v3 2/6] baseband/turbo_sw: add support for CRC16
On 9/7/21 6:15 PM, Nicolas Chautru wrote:
This is to support the case for operation
where CRC16 is to be appended or checked.
Signed-off-by: Nicolas Chautru
---
doc/guides/rel_notes/release_21_11.rst | 3 +++
drivers/baseband/turbo_sw/bbdev_turbo_software.c | 16
2 files changed, 19 insertions(+)
diff --git a/doc/guides/rel_notes/release_21_11.rst
b/doc/guides/rel_notes/release_21_11.rst
index 69dd518..8ca59b7 100644
--- a/doc/guides/rel_notes/release_21_11.rst
+++ b/doc/guides/rel_notes/release_21_11.rst
@@ -55,6 +55,9 @@ New Features
Also, make sure to start the actual text at the margin.
===
+* **Updated the turbo_sw bbdev PMD.**
+
+ Added support for more comprehensive CRC options.
Removed Items
-
diff --git a/drivers/baseband/turbo_sw/bbdev_turbo_software.c
b/drivers/baseband/turbo_sw/bbdev_turbo_software.c
index 77e9a2e..e1db2bf 100644
--- a/drivers/baseband/turbo_sw/bbdev_turbo_software.c
+++ b/drivers/baseband/turbo_sw/bbdev_turbo_software.c
@@ -199,6 +199,7 @@ struct turbo_sw_queue {
.cap.ldpc_enc = {
.capability_flags =
RTE_BBDEV_LDPC_RATE_MATCH |
+ RTE_BBDEV_LDPC_CRC_16_ATTACH |
RTE_BBDEV_LDPC_CRC_24A_ATTACH |
RTE_BBDEV_LDPC_CRC_24B_ATTACH,
.num_buffers_src =
@@ -211,6 +212,7 @@ struct turbo_sw_queue {
.type = RTE_BBDEV_OP_LDPC_DEC,
.cap.ldpc_dec = {
.capability_flags =
+ RTE_BBDEV_LDPC_CRC_TYPE_16_CHECK |
RTE_BBDEV_LDPC_CRC_TYPE_24B_CHECK |
RTE_BBDEV_LDPC_CRC_TYPE_24A_CHECK |
RTE_BBDEV_LDPC_CRC_TYPE_24B_DROP |
@@ -880,6 +882,12 @@ struct turbo_sw_queue {
crc_req.len = in_length_in_bits - 24;
crc_resp.data = q->enc_in;
bblib_lte_crc24b_gen(&crc_req, &crc_resp);
+ } else if (enc->op_flags & RTE_BBDEV_LDPC_CRC_16_ATTACH) {
+ rte_memcpy(q->enc_in, in, in_length_in_bytes - 2);
+ crc_req.data = in;
+ crc_req.len = in_length_in_bits - 16;
+ crc_resp.data = q->enc_in;
+ bblib_lte_crc16_gen(&crc_req, &crc_resp);
} else
rte_memcpy(q->enc_in, in, in_length_in_bytes);
@@ -1491,6 +1499,14 @@ struct turbo_sw_queue {
bblib_lte_crc24a_check(&crc_req, &crc_resp);
if (!crc_resp.check_passed)
op->status |= 1 << RTE_BBDEV_CRC_ERROR;
+ } else if (check_bit(dec->op_flags, RTE_BBDEV_LDPC_CRC_TYPE_16_CHECK)) {
+ crc_req.data = adapter_input;
+ crc_req.len = K - dec->n_filler - 16;
+ crc_resp.check_passed = false;
+ crc_resp.data = adapter_input;
+ bblib_lte_crc16_check(&crc_req, &crc_resp);
+ if (!crc_resp.check_passed)
+ op->status |= 1 << RTE_BBDEV_CRC_ERROR;
}
Thanks for the else-if() change.
Looks good.
Reviewed-by: Tom Rix
#ifdef RTE_BBDEV_OFFLOAD_COST
Re: [dpdk-dev] [PATCH v3 3/6] bbdev: add capability for 4G CB CRC DROP
On 9/7/21 6:15 PM, Nicolas Chautru wrote:
Adding option to drop CRC24B to align with existing
feature for 5G
Signed-off-by: Nicolas Chautru
---
app/test-bbdev/test_bbdev_vector.c | 2 ++
lib/bbdev/rte_bbdev_op.h | 5 -
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/app/test-bbdev/test_bbdev_vector.c
b/app/test-bbdev/test_bbdev_vector.c
index 8d796b1..f020836 100644
--- a/app/test-bbdev/test_bbdev_vector.c
+++ b/app/test-bbdev/test_bbdev_vector.c
@@ -149,6 +149,8 @@
*op_flag_value = RTE_BBDEV_TURBO_DEC_SCATTER_GATHER;
else if (!strcmp(token, "RTE_BBDEV_TURBO_DEC_TB_CRC_24B_KEEP"))
*op_flag_value = RTE_BBDEV_TURBO_DEC_TB_CRC_24B_KEEP;
+ else if (!strcmp(token, "RTE_BBDEV_TURBO_DEC_CRC_24B_DROP"))
+ *op_flag_value = RTE_BBDEV_TURBO_DEC_CRC_24B_DROP;
else {
printf("The given value is not a turbo decoder flag\n");
return -1;
diff --git a/lib/bbdev/rte_bbdev_op.h b/lib/bbdev/rte_bbdev_op.h
index 7c44ddd..5512859 100644
--- a/lib/bbdev/rte_bbdev_op.h
+++ b/lib/bbdev/rte_bbdev_op.h
@@ -114,7 +114,10 @@ enum rte_bbdev_op_td_flag_bitmasks {
/** Set to keep CRC24B bits appended while decoding. Only usable when
* decoding Transport Block mode.
*/
- RTE_BBDEV_TURBO_DEC_TB_CRC_24B_KEEP = (1ULL << 16)
+ RTE_BBDEV_TURBO_DEC_TB_CRC_24B_KEEP = (1ULL << 16),
+ /** Set to drop CRC24B bits not to be appended while decoding.
+*/
+ RTE_BBDEV_TURBO_DEC_CRC_24B_DROP = (1ULL << 17)
};
This is ok, thanks.
Reviewed-by: Tom Rix
Re: [dpdk-dev] [PATCH v3 4/6] baseband/acc100: add support for 4G CRC drop
On 9/7/21 6:15 PM, Nicolas Chautru wrote:
This implements in PMD the option to drop the CB CRC
after 4G decoding to help transport block concatenation.
Signed-off-by: Nicolas Chautru
---
doc/guides/bbdevs/acc100.rst | 1 +
doc/guides/rel_notes/release_21_11.rst | 4
drivers/baseband/acc100/rte_acc100_pmd.c | 12 +---
3 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/doc/guides/bbdevs/acc100.rst b/doc/guides/bbdevs/acc100.rst
index ff0fa4b..9fff6ab 100644
--- a/doc/guides/bbdevs/acc100.rst
+++ b/doc/guides/bbdevs/acc100.rst
@@ -58,6 +58,7 @@ ACC100 5G/4G FEC PMD supports the following BBDEV
capabilities:
- ``RTE_BBDEV_TURBO_NEG_LLR_1_BIT_IN`` : set if negative LLR encoder i/p
is supported
- ``RTE_BBDEV_TURBO_POS_LLR_1_BIT_IN`` : set if positive LLR encoder i/p
is supported
- ``RTE_BBDEV_TURBO_DEC_TB_CRC_24B_KEEP`` : keep CRC24B bits appended
while decoding
+ - ``RTE_BBDEV_TURBO_DEC_CRC_24B_DROP`` : option to drop the code block CRC
after decoding
- ``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
diff --git a/doc/guides/rel_notes/release_21_11.rst
b/doc/guides/rel_notes/release_21_11.rst
index 8ca59b7..f7843bc 100644
--- a/doc/guides/rel_notes/release_21_11.rst
+++ b/doc/guides/rel_notes/release_21_11.rst
@@ -59,6 +59,10 @@ New Features
Added support for more comprehensive CRC options.
+* **Updated the ACC100 bbdev PMD.**
+
+ Added support for more comprehensive CRC options.
+
Removed Items
-
diff --git a/drivers/baseband/acc100/rte_acc100_pmd.c b/drivers/baseband/acc100/rte_acc100_pmd.c
index 68ba523..2e9ce92 100644
--- a/drivers/baseband/acc100/rte_acc100_pmd.c
+++ b/drivers/baseband/acc100/rte_acc100_pmd.c
@@ -980,6 +980,7 @@
RTE_BBDEV_TURBO_NEG_LLR_1_BIT_IN |
RTE_BBDEV_TURBO_MAP_DEC |
RTE_BBDEV_TURBO_DEC_TB_CRC_24B_KEEP |
+ RTE_BBDEV_TURBO_DEC_CRC_24B_DROP |
RTE_BBDEV_TURBO_DEC_SCATTER_GATHER,
.max_llr_modulus = INT8_MAX,
.num_buffers_src =
@@ -1708,8 +1709,12 @@
}
if ((op->turbo_dec.code_block_mode == RTE_BBDEV_TRANSPORT_BLOCK)
- && !check_bit(op->turbo_dec.op_flags,
- RTE_BBDEV_TURBO_DEC_TB_CRC_24B_KEEP))
+ && !check_bit(op->turbo_dec.op_flags,
+ RTE_BBDEV_TURBO_DEC_TB_CRC_24B_KEEP))
+ crc24_overlap = 24;
+ if ((op->turbo_dec.code_block_mode == RTE_BBDEV_CODE_BLOCK)
+ && check_bit(op->turbo_dec.op_flags,
+ RTE_BBDEV_TURBO_DEC_CRC_24B_DROP))
crc24_overlap = 24;
ok if this isn't combined.
the bug moved to its own patch.
Looks good.
Reviewed-by: Tom Rix
/* Calculates circular buffer size.
@@ -1744,7 +1749,8 @@
next_triplet = acc100_dma_fill_blk_type_out(
desc, h_output, *h_out_offset,
- k >> 3, next_triplet, ACC100_DMA_BLKID_OUT_HARD);
+ k >> 3, next_triplet,
+ ACC100_DMA_BLKID_OUT_HARD);
if (unlikely(next_triplet < 0)) {
rte_bbdev_log(ERR,
"Mismatch between data to process and mbuf data
length in bbdev_op: %p",
Re: [dpdk-dev] [PATCH v3 5/6] doc: clarification of usage of HARQ in bbdev doc
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 --- 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:: +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 not 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 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. Fine. Reviewed-by: Tom Rix
Re: [dpdk-dev] [PATCH v3 6/6] bbdev: reduce warning level for one scenario
On 9/7/21 6:15 PM, Nicolas Chautru wrote:
Queue setup may genuinely fail when adding incremental queues
for a given priority level. In that case application would
attempt to configure a queue at a different priority level.
Not an actual error.
Signed-off-by: Nicolas Chautru
---
lib/bbdev/rte_bbdev.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/lib/bbdev/rte_bbdev.c b/lib/bbdev/rte_bbdev.c
index fc37236..defddcf 100644
--- a/lib/bbdev/rte_bbdev.c
+++ b/lib/bbdev/rte_bbdev.c
@@ -528,9 +528,10 @@ struct rte_bbdev *
ret = dev->dev_ops->queue_setup(dev, queue_id, (conf != NULL) ?
conf : &dev_info.default_queue_conf);
if (ret < 0) {
- rte_bbdev_log(ERR,
- "Device %u queue %u setup failed", dev_id,
- queue_id);
+ /* This may happen when trying different priority levels */
+ rte_bbdev_log(INFO,
+ "Device %u queue %u setup failed",
+ dev_id, queue_id);
This change is just changing the log level, which is fine.
I am looking at how the error handling is done for the function.
It seems like the bailing is done in the middle of change the queue state.
ex/ the block above this one
/* Release existing queue ... */
Does this leave the queue in a bad state ?
Tom
return ret;
}
Re: [dpdk-dev] [PATCH v3 6/6] bbdev: reduce warning level for one scenario
On 9/13/21 10:03 AM, Chautru, Nicolas wrote:
-Original Message-
From: Tom Rix
Sent: Sunday, September 12, 2021 5:55 AM
To: Chautru, Nicolas ; dev@dpdk.org;
gak...@marvell.com
Cc: tho...@monjalon.net; hemant.agra...@nxp.com; Zhang, Mingshan
; Joshi, Arun
Subject: Re: [PATCH v3 6/6] bbdev: reduce warning level for one scenario
On 9/7/21 6:15 PM, Nicolas Chautru wrote:
Queue setup may genuinely fail when adding incremental queues for a
given priority level. In that case application would attempt to
configure a queue at a different priority level.
Not an actual error.
Signed-off-by: Nicolas Chautru
---
lib/bbdev/rte_bbdev.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/lib/bbdev/rte_bbdev.c b/lib/bbdev/rte_bbdev.c index
fc37236..defddcf 100644
--- a/lib/bbdev/rte_bbdev.c
+++ b/lib/bbdev/rte_bbdev.c
@@ -528,9 +528,10 @@ struct rte_bbdev *
ret = dev->dev_ops->queue_setup(dev, queue_id, (conf != NULL) ?
conf : &dev_info.default_queue_conf);
if (ret < 0) {
- rte_bbdev_log(ERR,
- "Device %u queue %u setup failed", dev_id,
- queue_id);
+ /* This may happen when trying different priority levels */
+ rte_bbdev_log(INFO,
+ "Device %u queue %u setup failed",
+ dev_id, queue_id);
This change is just changing the log level, which is fine.
I am looking at how the error handling is done for the function.
It seems like the bailing is done in the middle of change the queue state.
ex/ the block above this one
/* Release existing queue ... */
Does this leave the queue in a bad state ?
Hi Tom,
That would not be related to that change indeed.
The queue would end up in a not configured when rte_bbdev_queue_configure()
fails but then can still be configured again without limitation (worst thing
than can happen is that queue_release is called, hence leaves the queue in a
deterministic state, unconfigured but ready to be configured).
Note that queue_release() just removes the configuration of the queue, but the
queue is still there and can be configured again (actual total number of queues
unchanged, based on number previously set with rte_bbdev_setup_queues()).
So its in a bad state, but outside the scope of this commit.
Reviewed-by: Tom Rix
Tom
Thanks
Nic
Tom
return ret;
}
Re: [dpdk-dev] [PATCH v1] bbdev: adding explicit enum for code block mode
else
> ret = dequeue_dec_one_op_cb(q, &ops[i], dequeued_cbs);
> diff --git a/drivers/baseband/turbo_sw/bbdev_turbo_software.c
> b/drivers/baseband/turbo_sw/bbdev_turbo_software.c
> index aa7f122..85cf93d 100644
> --- a/drivers/baseband/turbo_sw/bbdev_turbo_software.c
> +++ b/drivers/baseband/turbo_sw/bbdev_turbo_software.c
> @@ -578,7 +578,7 @@ struct turbo_sw_queue {
>
> /* CRC24A (for TB) */
> if ((enc->op_flags & RTE_BBDEV_TURBO_CRC_24A_ATTACH) &&
> - (enc->code_block_mode == 1)) {
> + (enc->code_block_mode == RTE_BBDEV_CODE_BLOCK)) {
> #ifdef RTE_LIBRTE_BBDEV_DEBUG
> ret = is_enc_input_valid(k - 24, k_idx, in_length);
> if (ret != 0) {
> @@ -1007,7 +1007,7 @@ struct turbo_sw_queue {
> (enc->op_flags & RTE_BBDEV_TURBO_CRC_24A_ATTACH))
> crc24_bits = 24;
>
> - if (enc->code_block_mode == 0) { /* For Transport Block mode */
> + if (enc->code_block_mode == RTE_BBDEV_TRANSPORT_BLOCK) {
> c = enc->tb_params.c;
> r = enc->tb_params.r;
> } else {/* For Code Block mode */
> @@ -1019,7 +1019,7 @@ struct turbo_sw_queue {
>
> seg_total_left = rte_pktmbuf_data_len(m_in) - in_offset;
>
> - if (enc->code_block_mode == 0) {
> + if (enc->code_block_mode == RTE_BBDEV_TRANSPORT_BLOCK) {
> k = (r < enc->tb_params.c_neg) ?
> enc->tb_params.k_neg : enc->tb_params.k_pos;
> ncb = (r < enc->tb_params.c_neg) ?
> @@ -1101,7 +1101,7 @@ struct turbo_sw_queue {
> (enc->op_flags & RTE_BBDEV_TURBO_CRC_24A_ATTACH))
> crc24_bits = 24;
>
> - if (enc->code_block_mode == 0) { /* For Transport Block mode */
> + if (enc->code_block_mode == RTE_BBDEV_TRANSPORT_BLOCK) {
> c = enc->tb_params.c;
> r = enc->tb_params.r;
> } else { /* For Code Block mode */
> @@ -1113,7 +1113,7 @@ struct turbo_sw_queue {
>
> seg_total_left = rte_pktmbuf_data_len(m_in) - in_offset;
>
> - if (enc->code_block_mode == 0) {
> + if (enc->code_block_mode == RTE_BBDEV_TRANSPORT_BLOCK) {
> e = (r < enc->tb_params.cab) ?
> enc->tb_params.ea : enc->tb_params.eb;
> } else {
> @@ -1570,7 +1570,7 @@ struct turbo_sw_queue {
> return;
> }
>
> - if (dec->code_block_mode == 0) { /* For Transport Block mode */
> + if (dec->code_block_mode == RTE_BBDEV_TRANSPORT_BLOCK) {
> c = dec->tb_params.c;
> } else { /* For Code Block mode */
> k = dec->cb_params.k;
> @@ -1582,7 +1582,7 @@ struct turbo_sw_queue {
> crc24_overlap = 24;
>
> while (mbuf_total_left > 0) {
> - if (dec->code_block_mode == 0)
> + if (dec->code_block_mode == RTE_BBDEV_TRANSPORT_BLOCK)
> k = (r < dec->tb_params.c_neg) ?
> dec->tb_params.k_neg : dec->tb_params.k_pos;
>
> @@ -1658,7 +1658,7 @@ struct turbo_sw_queue {
> return;
> }
>
> - if (dec->code_block_mode == 0) { /* For Transport Block mode */
> + if (dec->code_block_mode == RTE_BBDEV_TRANSPORT_BLOCK) {
> c = dec->tb_params.c;
> e = dec->tb_params.ea;
> } else { /* For Code Block mode */
> @@ -1673,7 +1673,7 @@ struct turbo_sw_queue {
> out_length = ((out_length - crc24_overlap - dec->n_filler) >> 3);
>
> while (mbuf_total_left > 0) {
> - if (dec->code_block_mode == 0)
> + if (dec->code_block_mode == RTE_BBDEV_TRANSPORT_BLOCK)
> e = (r < dec->tb_params.cab) ?
> dec->tb_params.ea : dec->tb_params.eb;
> /* Special case handling when overusing mbuf */
> diff --git a/lib/librte_bbdev/rte_bbdev_op.h b/lib/librte_bbdev/rte_bbdev_op.h
> index f726d73..f946842 100644
> --- a/lib/librte_bbdev/rte_bbdev_op.h
> +++ b/lib/librte_bbdev/rte_bbdev_op.h
> @@ -112,7 +112,7 @@ enum rte_bbdev_op_td_flag_bitmasks {
> /** Set if a device supports scatter-gather functionality */
> RTE_BBDEV_TURBO_DEC_SCATTER_GATHER = (1ULL << 15),
> /** Set to keep CRC24B bits appended while decoding. Only usable when
> - * decoding Transport Blocks (code_block_mode = 0).
> + * decoding Transport Block mode.
>*/
> RTE_BBDEV_TURBO_DEC_TB_CRC_24B_KEEP = (1ULL << 16)
> };
> @@ -209,6 +209,14 @@ enum rte_bbdev_op_ldpcenc_flag_bitmasks {
> RTE_BBDEV_LDPC_ENC_CONCATENATION = (1ULL << 7)
> };
>
> +/** Flags for the Code Block/Transport block mode */
> +enum rte_bbdev_op_cb_mode {
> + /** One operation is one or fraction of one transport block */
> + RTE_BBDEV_TRANSPORT_BLOCK = 0,
> + /** One operation is one code block mode */
> + RTE_BBDEV_CODE_BLOCK = 1,
> +};
Look good.
Thanks for the change,
Reviewed-by: Tom Rix
> +
> /** Data input and output buffer for BBDEV operations */
> struct rte_bbdev_op_data {
> /** The mbuf data structure representing the data for BBDEV operation.
Re: [PATCH v1 00/10] baseband/acc200
On 9/1/22 1:34 PM, Chautru, Nicolas wrote: Hi Tom, -Original Message- From: Tom Rix Sent: Thursday, September 1, 2022 6:49 AM To: Chautru, Nicolas ; Maxime Coquelin ; dev@dpdk.org; tho...@monjalon.net; gak...@marvell.com; hemant.agra...@nxp.com; Vargas, Hernan Cc: m...@ashroe.eu; Richardson, Bruce ; david.march...@redhat.com; step...@networkplumber.org Subject: Re: [PATCH v1 00/10] baseband/acc200 On 8/31/22 6:26 PM, Chautru, Nicolas wrote: Hi Tom, -Original Message- From: Tom Rix Sent: Wednesday, August 31, 2022 5:28 PM To: Chautru, Nicolas ; Maxime Coquelin ; dev@dpdk.org; tho...@monjalon.net; gak...@marvell.com; hemant.agra...@nxp.com; Vargas, Hernan Cc: m...@ashroe.eu; Richardson, Bruce ; david.march...@redhat.com; step...@networkplumber.org Subject: Re: [PATCH v1 00/10] baseband/acc200 On 8/31/22 3:37 PM, Chautru, Nicolas wrote: Hi Thomas, Tom, -Original Message- From: Tom Rix Sent: Wednesday, August 31, 2022 12:26 PM To: Chautru, Nicolas ; Maxime Coquelin ; dev@dpdk.org; tho...@monjalon.net; gak...@marvell.com; hemant.agra...@nxp.com; Vargas, Hernan Cc: m...@ashroe.eu; Richardson, Bruce ; david.march...@redhat.com; step...@networkplumber.org Subject: Re: [PATCH v1 00/10] baseband/acc200 On 8/30/22 12:45 PM, Chautru, Nicolas wrote: Hi Maxime, -Original Message- From: Maxime Coquelin Sent: Tuesday, August 30, 2022 12:45 AM To: Chautru, Nicolas ; dev@dpdk.org; tho...@monjalon.net; gak...@marvell.com; hemant.agra...@nxp.com; t...@redhat.com; Vargas, Hernan Cc: m...@ashroe.eu; Richardson, Bruce ; david.march...@redhat.com; step...@networkplumber.org Subject: Re: [PATCH v1 00/10] baseband/acc200 Hi Nicolas, On 7/12/22 15:48, Maxime Coquelin wrote: Hi Nicolas, Hernan, (Adding Hernan in the recipients list) On 7/8/22 02:01, Nicolas Chautru wrote: This is targeting 22.11 and includes the PMD for the integrated accelerator on Intel Xeon SPR-EEC. There is a dependency on that parallel serie still in-flight which extends the bbdev api https://patches.dpdk.org/project/dpdk/list/?series=23894 I will be offline for a few weeks for the summer break but Hernan will cover for me during that time if required. Thanks Nic Nicolas Chautru (10): baseband/acc200: introduce PMD for ACC200 baseband/acc200: add HW register definitions baseband/acc200: add info get function baseband/acc200: add queue configuration baseband/acc200: add LDPC processing functions baseband/acc200: add LTE processing functions baseband/acc200: add support for FFT operations baseband/acc200: support interrupt baseband/acc200: add device status and vf2pf comms baseband/acc200: add PF configure companion function MAINTAINERS | 3 + app/test-bbdev/meson.build | 3 + app/test-bbdev/test_bbdev_perf.c | 76 + doc/guides/bbdevs/acc200.rst | 244 ++ doc/guides/bbdevs/index.rst | 1 + drivers/baseband/acc200/acc200_pf_enum.h | 468 +++ drivers/baseband/acc200/acc200_pmd.h | 690 drivers/baseband/acc200/acc200_vf_enum.h | 89 + drivers/baseband/acc200/meson.build | 8 + drivers/baseband/acc200/rte_acc200_cfg.h | 115 + drivers/baseband/acc200/rte_acc200_pmd.c | 5403 ++ drivers/baseband/acc200/version.map | 10 + drivers/baseband/meson.build | 1 + 13 files changed, 7111 insertions(+) create mode 100644 doc/guides/bbdevs/acc200.rst create mode 100644 drivers/baseband/acc200/acc200_pf_enum.h create mode 100644 drivers/baseband/acc200/acc200_pmd.h create mode 100644 drivers/baseband/acc200/acc200_vf_enum.h create mode 100644 drivers/baseband/acc200/meson.build create mode 100644 drivers/baseband/acc200/rte_acc200_cfg.h create mode 100644 drivers/baseband/acc200/rte_acc200_pmd.c create mode 100644 drivers/baseband/acc200/version.map Comparing ACC200 & ACC100 header files, I understand ACC200 is an evolution of the ACC10x family. The FEC bits are really close, ACC200 main addition seems to be FFT acceleration which could be handled in ACC10x driver based on device ID. I think both drivers have to be merged in order to avoid code duplication. That's how other families of devices (e.g. i40e) are handled. I haven't seen your reply on this point. Do you confirm you are working on a single driver for ACC family in order to avoid code duplication? The implementation is based on distinct ACC100 and ACC200 drivers. The 2 devices are fundamentally different generation, processes and IP. MountBryce is an eASIC device over PCIe while ACC200 is an integrated accelerator on Xeon CPU. The actual implementation are not the same, underlying IP are all distinct even if many of the descriptor format have similarities. The actua
Re: [dpdk-dev] [PATCH v9] bbdev: add device info related to data endianness assumption
On 10/6/21 1:58 PM, Nicolas Chautru wrote:
Adding device information to capture explicitly the assumption
of the input/output data byte endianness being processed.
Signed-off-by: Nicolas Chautru
---
doc/guides/rel_notes/release_21_11.rst | 1 +
drivers/baseband/acc100/rte_acc100_pmd.c | 1 +
drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c | 1 +
drivers/baseband/fpga_lte_fec/fpga_lte_fec.c | 1 +
Missed bbdev_null.c
If this was intentional data_endianness is uninitialized or implicitly
big endian.
It would be better to say it is unknown. which may mean another enum is
needed.
drivers/baseband/turbo_sw/bbdev_turbo_software.c | 1 +
lib/bbdev/rte_bbdev.h | 8
6 files changed, 13 insertions(+)
diff --git a/doc/guides/rel_notes/release_21_11.rst
b/doc/guides/rel_notes/release_21_11.rst
index a8900a3..f0b3006 100644
--- a/doc/guides/rel_notes/release_21_11.rst
+++ b/doc/guides/rel_notes/release_21_11.rst
@@ -191,6 +191,7 @@ API Changes
* bbdev: Added capability related to more comprehensive CRC options.
+* bbdev: Added device info related to data byte endianness processing assumption.
ABI Changes
---
diff --git a/drivers/baseband/acc100/rte_acc100_pmd.c
b/drivers/baseband/acc100/rte_acc100_pmd.c
index 4e2feef..eb2c6c1 100644
--- a/drivers/baseband/acc100/rte_acc100_pmd.c
+++ b/drivers/baseband/acc100/rte_acc100_pmd.c
@@ -1089,6 +1089,7 @@
#else
dev_info->harq_buffer_size = 0;
#endif
+ dev_info->data_endianness = RTE_BBDEV_LITTLE_ENDIAN;
acc100_check_ir(d);
}
diff --git a/drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c b/drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c
index 6485cc8..c7f15c0 100644
--- a/drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c
+++ b/drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c
@@ -372,6 +372,7 @@
dev_info->default_queue_conf = default_queue_conf;
dev_info->capabilities = bbdev_capabilities;
dev_info->cpu_flag_reqs = NULL;
+ dev_info->data_endianness = RTE_BBDEV_LITTLE_ENDIAN;
/* Calculates number of queues assigned to device */
dev_info->max_num_queues = 0;
diff --git a/drivers/baseband/fpga_lte_fec/fpga_lte_fec.c
b/drivers/baseband/fpga_lte_fec/fpga_lte_fec.c
index 350c424..72e213e 100644
--- a/drivers/baseband/fpga_lte_fec/fpga_lte_fec.c
+++ b/drivers/baseband/fpga_lte_fec/fpga_lte_fec.c
@@ -644,6 +644,7 @@ struct __rte_cache_aligned fpga_queue {
dev_info->default_queue_conf = default_queue_conf;
dev_info->capabilities = bbdev_capabilities;
dev_info->cpu_flag_reqs = NULL;
+ dev_info->data_endianness = RTE_BBDEV_LITTLE_ENDIAN;
/* Calculates number of queues assigned to device */
dev_info->max_num_queues = 0;
diff --git a/drivers/baseband/turbo_sw/bbdev_turbo_software.c
b/drivers/baseband/turbo_sw/bbdev_turbo_software.c
index e1db2bf..0cab91a 100644
--- a/drivers/baseband/turbo_sw/bbdev_turbo_software.c
+++ b/drivers/baseband/turbo_sw/bbdev_turbo_software.c
@@ -253,6 +253,7 @@ struct turbo_sw_queue {
dev_info->capabilities = bbdev_capabilities;
dev_info->min_alignment = 64;
dev_info->harq_buffer_size = 0;
+ dev_info->data_endianness = RTE_BBDEV_LITTLE_ENDIAN;
rte_bbdev_log_debug("got device info from %u\n", dev->data->dev_id);
}
diff --git a/lib/bbdev/rte_bbdev.h b/lib/bbdev/rte_bbdev.h
index 3ebf62e..b3f3000 100644
--- a/lib/bbdev/rte_bbdev.h
+++ b/lib/bbdev/rte_bbdev.h
@@ -49,6 +49,12 @@ enum rte_bbdev_state {
RTE_BBDEV_INITIALIZED
};
+/** Definitions of device data byte endianness types */
+enum rte_bbdev_endianness {
+ RTE_BBDEV_BIG_ENDIAN,/**< Data with byte-endianness BE */
+ RTE_BBDEV_LITTLE_ENDIAN, /**< Data with byte-endianness LE */
+};
Could RTE_BIG|LITTLE_ENDIAN be reused ?
Tom
+
/**
* Get the total number of devices that have been successfully initialised.
*
@@ -309,6 +315,8 @@ struct rte_bbdev_driver_info {
uint16_t min_alignment;
/** HARQ memory available in kB */
uint32_t harq_buffer_size;
+ /** Byte endianness assumption for input/output data */
+ enum rte_bbdev_endianness data_endianness;
/** Default queue configuration used if none is supplied */
struct rte_bbdev_queue_conf default_queue_conf;
/** Device operation capabilities */
Re: [dpdk-dev] [PATCH v2 1/6] bbdev: add capability for CRC16 check
On 8/19/21 2:10 PM, Nicolas Chautru wrote:
Adding a missing operation when CRC16
is being used for TB CRC check.
Signed-off-by: Nicolas Chautru
---
app/test-bbdev/test_bbdev_vector.c | 2 ++
doc/guides/prog_guide/bbdev.rst| 3 +++
doc/guides/rel_notes/release_21_11.rst | 1 +
lib/bbdev/rte_bbdev_op.h | 34 ++
4 files changed, 24 insertions(+), 16 deletions(-)
diff --git a/app/test-bbdev/test_bbdev_vector.c
b/app/test-bbdev/test_bbdev_vector.c
index 614dbd1..8d796b1 100644
--- a/app/test-bbdev/test_bbdev_vector.c
+++ b/app/test-bbdev/test_bbdev_vector.c
@@ -167,6 +167,8 @@
*op_flag_value = RTE_BBDEV_LDPC_CRC_TYPE_24B_CHECK;
else if (!strcmp(token, "RTE_BBDEV_LDPC_CRC_TYPE_24B_DROP"))
*op_flag_value = RTE_BBDEV_LDPC_CRC_TYPE_24B_DROP;
+ else if (!strcmp(token, "RTE_BBDEV_LDPC_CRC_TYPE_16_CHECK"))
+ *op_flag_value = RTE_BBDEV_LDPC_CRC_TYPE_16_CHECK;
else if (!strcmp(token, "RTE_BBDEV_LDPC_DEINTERLEAVER_BYPASS"))
*op_flag_value = RTE_BBDEV_LDPC_DEINTERLEAVER_BYPASS;
else if (!strcmp(token, "RTE_BBDEV_LDPC_HQ_COMBINE_IN_ENABLE"))
diff --git a/doc/guides/prog_guide/bbdev.rst b/doc/guides/prog_guide/bbdev.rst
index 9619280..8bd7cba 100644
--- a/doc/guides/prog_guide/bbdev.rst
+++ b/doc/guides/prog_guide/bbdev.rst
@@ -891,6 +891,9 @@ given below.
|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|
++
diff --git a/doc/guides/rel_notes/release_21_11.rst
b/doc/guides/rel_notes/release_21_11.rst
index d707a55..69dd518 100644
--- a/doc/guides/rel_notes/release_21_11.rst
+++ b/doc/guides/rel_notes/release_21_11.rst
@@ -84,6 +84,7 @@ API Changes
Also, make sure to start the actual text at the margin.
===
+* bbdev: Added capability related to more comprehensive CRC options.
ABI Changes
---
diff --git a/lib/bbdev/rte_bbdev_op.h b/lib/bbdev/rte_bbdev_op.h
index f946842..7c44ddd 100644
--- a/lib/bbdev/rte_bbdev_op.h
+++ b/lib/bbdev/rte_bbdev_op.h
@@ -142,51 +142,53 @@ enum rte_bbdev_op_ldpcdec_flag_bitmasks {
RTE_BBDEV_LDPC_CRC_TYPE_24B_CHECK = (1ULL << 1),
/** Set to drop the last CRC bits decoding output */
RTE_BBDEV_LDPC_CRC_TYPE_24B_DROP = (1ULL << 2),
+ /** Set for transport block CRC-16 checking */
+ RTE_BBDEV_LDPC_CRC_TYPE_16_CHECK = (1ULL << 3),
Changing these enums will break the abi backwards.
Why not add the new one at the end ?
Tom
/** Set for bit-level de-interleaver bypass on Rx stream. */
- RTE_BBDEV_LDPC_DEINTERLEAVER_BYPASS = (1ULL << 3),
+ RTE_BBDEV_LDPC_DEINTERLEAVER_BYPASS = (1ULL << 4),
/** Set for HARQ combined input stream enable. */
- RTE_BBDEV_LDPC_HQ_COMBINE_IN_ENABLE = (1ULL << 4),
+ RTE_BBDEV_LDPC_HQ_COMBINE_IN_ENABLE = (1ULL << 5),
/** Set for HARQ combined output stream enable. */
- RTE_BBDEV_LDPC_HQ_COMBINE_OUT_ENABLE = (1ULL << 5),
+ RTE_BBDEV_LDPC_HQ_COMBINE_OUT_ENABLE = (1ULL << 6),
/** Set for LDPC decoder bypass.
* RTE_BBDEV_LDPC_HQ_COMBINE_OUT_ENABLE must be set.
*/
- RTE_BBDEV_LDPC_DECODE_BYPASS = (1ULL << 6),
+ RTE_BBDEV_LDPC_DECODE_BYPASS = (1ULL << 7),
/** Set for soft-output stream enable */
- RTE_BBDEV_LDPC_SOFT_OUT_ENABLE = (1ULL << 7),
+ RTE_BBDEV_LDPC_SOFT_OUT_ENABLE = (1ULL << 8),
/** Set for Rate-Matching bypass on soft-out stream. */
- RTE_BBDEV_LDPC_SOFT_OUT_RM_BYPASS = (1ULL << 8),
+ RTE_BBDEV_LDPC_SOFT_OUT_RM_BYPASS = (1ULL << 9),
/** Set for bit-level de-interleaver bypass on soft-output stream. */
- RTE_BBDEV_LDPC_SOFT_OUT_DEINTERLEAVER_BYPASS = (1ULL << 9),
+ RTE_BBDEV_LDPC_SOFT_OUT_DEINTERLEAVER_BYPASS = (1ULL << 10),
/** Set for iteration stopping on successful decode condition
* i.e. a successful syndrome check.
*/
- RTE_BBDEV_LDPC_ITERATION_STOP_ENABLE = (1ULL << 10),
+ RTE_BBDEV_LDPC_ITERATION_STOP_ENABLE = (1ULL << 11),
/** Set if a device supports decoder dequeue interrupts. */
- RTE_BBDEV_LDPC_DEC_INTERRUPTS = (1ULL << 11),
+ RTE_BBDEV_LDPC_DEC_INTERRUPTS = (1ULL << 12),
/** Set if a device supports scatter-gather functionality. */
- RTE_BBDEV_LDPC_DEC_SCATTER_GA
Re: [dpdk-dev] [PATCH v2 2/6] baseband/turbo_sw: add support for CRC16
On 8/19/21 2:10 PM, Nicolas Chautru wrote:
This is to support the case for operation
where CRC16 is to be appended or checked.
Signed-off-by: Nicolas Chautru
---
doc/guides/rel_notes/release_21_11.rst | 3 +++
drivers/baseband/turbo_sw/bbdev_turbo_software.c | 17 +
2 files changed, 20 insertions(+)
diff --git a/doc/guides/rel_notes/release_21_11.rst
b/doc/guides/rel_notes/release_21_11.rst
index 69dd518..8ca59b7 100644
--- a/doc/guides/rel_notes/release_21_11.rst
+++ b/doc/guides/rel_notes/release_21_11.rst
@@ -55,6 +55,9 @@ New Features
Also, make sure to start the actual text at the margin.
===
+* **Updated the turbo_sw bbdev PMD.**
+
+ Added support for more comprehensive CRC options.
Removed Items
-
diff --git a/drivers/baseband/turbo_sw/bbdev_turbo_software.c
b/drivers/baseband/turbo_sw/bbdev_turbo_software.c
index 77e9a2e..e570044 100644
--- a/drivers/baseband/turbo_sw/bbdev_turbo_software.c
+++ b/drivers/baseband/turbo_sw/bbdev_turbo_software.c
@@ -199,6 +199,7 @@ struct turbo_sw_queue {
.cap.ldpc_enc = {
.capability_flags =
RTE_BBDEV_LDPC_RATE_MATCH |
+ RTE_BBDEV_LDPC_CRC_16_ATTACH |
RTE_BBDEV_LDPC_CRC_24A_ATTACH |
RTE_BBDEV_LDPC_CRC_24B_ATTACH,
.num_buffers_src =
@@ -211,6 +212,7 @@ struct turbo_sw_queue {
.type = RTE_BBDEV_OP_LDPC_DEC,
.cap.ldpc_dec = {
.capability_flags =
+ RTE_BBDEV_LDPC_CRC_TYPE_16_CHECK |
RTE_BBDEV_LDPC_CRC_TYPE_24B_CHECK |
RTE_BBDEV_LDPC_CRC_TYPE_24A_CHECK |
RTE_BBDEV_LDPC_CRC_TYPE_24B_DROP |
@@ -880,6 +882,12 @@ struct turbo_sw_queue {
crc_req.len = in_length_in_bits - 24;
crc_resp.data = q->enc_in;
bblib_lte_crc24b_gen(&crc_req, &crc_resp);
+ } else if (enc->op_flags & RTE_BBDEV_LDPC_CRC_16_ATTACH) {
The 'else if' assumes the new flag is mutually exclusive wrt the other
crc flags.
At least a debug check should be added to verify.
+ rte_memcpy(q->enc_in, in, in_length_in_bytes - 2);
+ crc_req.data = in;
+ crc_req.len = in_length_in_bits - 16;
+ crc_resp.data = q->enc_in;
+ bblib_lte_crc16_gen(&crc_req, &crc_resp);
} else
rte_memcpy(q->enc_in, in, in_length_in_bytes);
@@ -1492,6 +1500,15 @@ struct turbo_sw_queue {
if (!crc_resp.check_passed)
op->status |= 1 << RTE_BBDEV_CRC_ERROR;
}
+ if (check_bit(dec->op_flags, RTE_BBDEV_LDPC_CRC_TYPE_16_CHECK)) {
The series of 'if-statements' means the new flag is not mutually
exclusive wrt the other crc flags.
doing both 24a and 16 would create a mess.
this should likely change to an else-if-statement similar to above.
Tom
+ crc_req.data = adapter_input;
+ crc_req.len = K - dec->n_filler - 16;
+ crc_resp.check_passed = false;
+ crc_resp.data = adapter_input;
+ bblib_lte_crc16_check(&crc_req, &crc_resp);
+ if (!crc_resp.check_passed)
+ op->status |= 1 << RTE_BBDEV_CRC_ERROR;
+ }
#ifdef RTE_BBDEV_OFFLOAD_COST
q_stats->acc_offload_cycles += rte_rdtsc_precise() - start_time;
Re: [dpdk-dev] [PATCH v2 4/6] baseband/acc100: add support for 4G CRC drop
On 8/19/21 2:10 PM, Nicolas Chautru wrote:
This implements in PMD the option to drop the CB CRC
after 4G decoding to help transport block concatenation.
Signed-off-by: Nicolas Chautru
---
doc/guides/bbdevs/acc100.rst | 1 +
doc/guides/rel_notes/release_21_11.rst | 4
drivers/baseband/acc100/rte_acc100_pmd.c | 12 +---
3 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/doc/guides/bbdevs/acc100.rst b/doc/guides/bbdevs/acc100.rst
index ff0fa4b..9fff6ab 100644
--- a/doc/guides/bbdevs/acc100.rst
+++ b/doc/guides/bbdevs/acc100.rst
@@ -58,6 +58,7 @@ ACC100 5G/4G FEC PMD supports the following BBDEV
capabilities:
- ``RTE_BBDEV_TURBO_NEG_LLR_1_BIT_IN`` : set if negative LLR encoder i/p
is supported
- ``RTE_BBDEV_TURBO_POS_LLR_1_BIT_IN`` : set if positive LLR encoder i/p
is supported
- ``RTE_BBDEV_TURBO_DEC_TB_CRC_24B_KEEP`` : keep CRC24B bits appended
while decoding
+ - ``RTE_BBDEV_TURBO_DEC_CRC_24B_DROP`` : option to drop the code block CRC
after decoding
- ``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
diff --git a/doc/guides/rel_notes/release_21_11.rst
b/doc/guides/rel_notes/release_21_11.rst
index 8ca59b7..f7843bc 100644
--- a/doc/guides/rel_notes/release_21_11.rst
+++ b/doc/guides/rel_notes/release_21_11.rst
@@ -59,6 +59,10 @@ New Features
Added support for more comprehensive CRC options.
+* **Updated the ACC100 bbdev PMD.**
+
+ Added support for more comprehensive CRC options.
+
Removed Items
-
diff --git a/drivers/baseband/acc100/rte_acc100_pmd.c b/drivers/baseband/acc100/rte_acc100_pmd.c
index 68ba523..891be81 100644
--- a/drivers/baseband/acc100/rte_acc100_pmd.c
+++ b/drivers/baseband/acc100/rte_acc100_pmd.c
@@ -980,6 +980,7 @@
RTE_BBDEV_TURBO_NEG_LLR_1_BIT_IN |
RTE_BBDEV_TURBO_MAP_DEC |
RTE_BBDEV_TURBO_DEC_TB_CRC_24B_KEEP |
+ RTE_BBDEV_TURBO_DEC_CRC_24B_DROP |
RTE_BBDEV_TURBO_DEC_SCATTER_GATHER,
.max_llr_modulus = INT8_MAX,
.num_buffers_src =
@@ -1708,8 +1709,12 @@
}
if ((op->turbo_dec.code_block_mode == RTE_BBDEV_TRANSPORT_BLOCK)
- && !check_bit(op->turbo_dec.op_flags,
- RTE_BBDEV_TURBO_DEC_TB_CRC_24B_KEEP))
+ && !check_bit(op->turbo_dec.op_flags,
+ RTE_BBDEV_TURBO_DEC_TB_CRC_24B_KEEP))
+ crc24_overlap = 24;
+ if ((op->turbo_dec.code_block_mode == RTE_BBDEV_CODE_BLOCK)
These two if-statements can be combined.
+ && check_bit(op->turbo_dec.op_flags,
+ RTE_BBDEV_TURBO_DEC_CRC_24B_DROP))
crc24_overlap = 24;
/* Calculates circular buffer size.
@@ -1744,7 +1749,8 @@
next_triplet = acc100_dma_fill_blk_type_out(
desc, h_output, *h_out_offset,
- k >> 3, next_triplet, ACC100_DMA_BLKID_OUT_HARD);
+ (k - crc24_overlap) >> 3, next_triplet,
crc24_overlap had been set before this patch in the above if-statement
for crc_24b_keep.
so this looks like a bug.
If it is a bug, it should be separated out as its own patch.
Tom
+ ACC100_DMA_BLKID_OUT_HARD);
if (unlikely(next_triplet < 0)) {
rte_bbdev_log(ERR,
"Mismatch between data to process and mbuf data
length in bbdev_op: %p",
Re: [dpdk-dev] [PATCH v2 6/6] bbdev: reduce warning level for one scenario
On 8/19/21 2:10 PM, Nicolas Chautru wrote:
Queue setup may genuinely fail when adding incremental queues
for a given priority level. In that case application would
attempt to configure a queue at a different priority level.
Not an actual error.
Signed-off-by: Nicolas Chautru
---
lib/bbdev/rte_bbdev.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/lib/bbdev/rte_bbdev.c b/lib/bbdev/rte_bbdev.c
index fc37236..defddcf 100644
--- a/lib/bbdev/rte_bbdev.c
+++ b/lib/bbdev/rte_bbdev.c
@@ -528,9 +528,10 @@ struct rte_bbdev *
ret = dev->dev_ops->queue_setup(dev, queue_id, (conf != NULL) ?
conf : &dev_info.default_queue_conf);
if (ret < 0) {
- rte_bbdev_log(ERR,
- "Device %u queue %u setup failed", dev_id,
- queue_id);
+ /* This may happen when trying different priority levels */
+ rte_bbdev_log(INFO,
+ "Device %u queue %u setup failed",
+ dev_id, queue_id);
Earlier code tears down the exiting plumbing.
If it is ok to fail, should this block move earlier before the teardown ?
Tom
return ret;
}
Re: [PATCH v1 00/10] baseband/acc200
On 7/14/22 11:49 AM, Vargas, Hernan wrote: Hi Tom, Maxime, Could you please review the v5 series that Nic submitted last week? https://patches.dpdk.org/project/dpdk/list/?series=23912 Thanks, Hernan Hernan, For this patch series for the acc200, will you be able to refactor it so acc has a common base ? Or will this be on hold until Nic is back ? Tom -Original Message- From: Maxime Coquelin Sent: Tuesday, July 12, 2022 8:49 AM To: Chautru, Nicolas ; dev@dpdk.org; tho...@monjalon.net; gak...@marvell.com; hemant.agra...@nxp.com; t...@redhat.com; Vargas, Hernan Cc: m...@ashroe.eu; Richardson, Bruce ; david.march...@redhat.com; step...@networkplumber.org Subject: Re: [PATCH v1 00/10] baseband/acc200 Hi Nicolas, Hernan, (Adding Hernan in the recipients list) On 7/8/22 02:01, Nicolas Chautru wrote: This is targeting 22.11 and includes the PMD for the integrated accelerator on Intel Xeon SPR-EEC. There is a dependency on that parallel serie still in-flight which extends the bbdev api https://patches.dpdk.org/project/dpdk/list/?series=23894 I will be offline for a few weeks for the summer break but Hernan will cover for me during that time if required. Thanks Nic Nicolas Chautru (10): baseband/acc200: introduce PMD for ACC200 baseband/acc200: add HW register definitions baseband/acc200: add info get function baseband/acc200: add queue configuration baseband/acc200: add LDPC processing functions baseband/acc200: add LTE processing functions baseband/acc200: add support for FFT operations baseband/acc200: support interrupt baseband/acc200: add device status and vf2pf comms baseband/acc200: add PF configure companion function MAINTAINERS |3 + app/test-bbdev/meson.build |3 + app/test-bbdev/test_bbdev_perf.c | 76 + doc/guides/bbdevs/acc200.rst | 244 ++ doc/guides/bbdevs/index.rst |1 + drivers/baseband/acc200/acc200_pf_enum.h | 468 +++ drivers/baseband/acc200/acc200_pmd.h | 690 drivers/baseband/acc200/acc200_vf_enum.h | 89 + drivers/baseband/acc200/meson.build |8 + drivers/baseband/acc200/rte_acc200_cfg.h | 115 + drivers/baseband/acc200/rte_acc200_pmd.c | 5403 ++ drivers/baseband/acc200/version.map | 10 + drivers/baseband/meson.build |1 + 13 files changed, 7111 insertions(+) create mode 100644 doc/guides/bbdevs/acc200.rst create mode 100644 drivers/baseband/acc200/acc200_pf_enum.h create mode 100644 drivers/baseband/acc200/acc200_pmd.h create mode 100644 drivers/baseband/acc200/acc200_vf_enum.h create mode 100644 drivers/baseband/acc200/meson.build create mode 100644 drivers/baseband/acc200/rte_acc200_cfg.h create mode 100644 drivers/baseband/acc200/rte_acc200_pmd.c create mode 100644 drivers/baseband/acc200/version.map Comparing ACC200 & ACC100 header files, I understand ACC200 is an evolution of the ACC10x family. The FEC bits are really close, ACC200 main addition seems to be FFT acceleration which could be handled in ACC10x driver based on device ID. I think both drivers have to be merged in order to avoid code duplication. That's how other families of devices (e.g. i40e) are handled. Thanks, Maxime
Re: [PATCH v4 3/7] bbdev: add device info on queue topology
On 7/7/22 10:13 AM, Chautru, Nicolas wrote:
Hi Tom,
-Original Message-
From: Tom Rix
Sent: Thursday, July 7, 2022 6:34 AM
To: Chautru, Nicolas ; dev@dpdk.org;
tho...@monjalon.net; gak...@marvell.com; hemant.agra...@nxp.com
Cc: maxime.coque...@redhat.com; m...@ashroe.eu; Richardson, Bruce
; david.march...@redhat.com;
step...@networkplumber.org
Subject: Re: [PATCH v4 3/7] bbdev: add device info on queue topology
On 7/6/22 2:12 PM, Chautru, Nicolas wrote:
Hi Tom,
-Original Message-
From: Tom Rix
Subject: Re: [PATCH v4 3/7] bbdev: add device info on queue topology
On 7/5/22 5:23 PM, Nicolas Chautru wrote:
Adding more options in the API to expose the number of queues
exposed and related priority.
Signed-off-by: Nicolas Chautru
---
lib/bbdev/rte_bbdev.h | 4
1 file changed, 4 insertions(+)
diff --git a/lib/bbdev/rte_bbdev.h b/lib/bbdev/rte_bbdev.h index
9b1ffa4..ac941d6 100644
--- a/lib/bbdev/rte_bbdev.h
+++ b/lib/bbdev/rte_bbdev.h
@@ -289,6 +289,10 @@ struct rte_bbdev_driver_info {
/** Maximum number of queues supported by the device */
unsigned int max_num_queues;
+ /** Maximum number of queues supported per operation type */
+ unsigned int num_queues[RTE_BBDEV_OP_TYPE_PADDED_MAX];
+ /** Priority level supported per operation type */
+ unsigned int queue_priority[RTE_BBDEV_OP_TYPE_PADDED_MAX];
It is better to add new elements to the end of a structure for better
backward compatibility
All that serie is not ABI compatible (sizes change etc...). I don’t believe
there
is such a recommendation, is there?
Depends on what users expect, a dynamically linked old application would at
best core here. If the elements were added to the end, yes the size would
change but the old dynamically linked application would not use
them. Dynamically linking is nice because problems in the library can be fixed
and shipped without forcing the user recompile. Though the user may not
realize it, this change forces them to recompile.
Tom
Thanks Tom. In that very context, the change are big enough not to have any
form of compatibility. This a new ABI version, and user knows they will have to
recompile.
Still it would be great to capture a recommendation in DPDK coding guideline in
case there is such a BKM, I have heard multiple arguments for different
preference, if we want to harmonize such things let's capture in coding guide
lines, it would not hurt. Maybe one for Thomas?
When sw is deployed, how would a user know ?
For that matter, how would a developer know without a deep reading of
header files ?
I am not asking for a compatibility testsuite here, just the placement
of new elements (the same code) at the end of structures. As a library
writer, please consider the users of the library. Your improvements are
amplified by all of the library's users. The user's code quality is
based on this library's code quality.
My expectation is a new ABI introduces new functionality without
breaking old binaries. Or if it does, it is for a good reason.
There is no good reason for putting new elements into the middle of an
existing structure.
Tom
Tom
/** Queue size limit (queue size must also be power of 2) */
uint32_t queue_size_lim;
/** Set if device off-loads operation to hardware */
Re: [PATCH v4 2/7] bbdev: add device status info
On 7/7/22 10:15 AM, Chautru, Nicolas wrote:
Hi Tom,
-Original Message-
From: Tom Rix
Sent: Thursday, July 7, 2022 6:37 AM
To: Chautru, Nicolas ; dev@dpdk.org;
tho...@monjalon.net; gak...@marvell.com; hemant.agra...@nxp.com
Cc: maxime.coque...@redhat.com; m...@ashroe.eu; Richardson, Bruce
; david.march...@redhat.com;
step...@networkplumber.org
Subject: Re: [PATCH v4 2/7] bbdev: add device status info
On 7/6/22 2:16 PM, Chautru, Nicolas wrote:
-Original Message-
From: Tom Rix
Subject: Re: [PATCH v4 2/7] bbdev: add device status info
On 7/5/22 5:23 PM, Nicolas Chautru wrote:
Added device status information, so that the PMD can expose
information related to the underlying accelerator device status.
Minor order change in structure to fit into padding hole.
Signed-off-by: Nicolas Chautru
---
drivers/baseband/acc100/rte_acc100_pmd.c | 1 +
drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c | 1 +
drivers/baseband/fpga_lte_fec/fpga_lte_fec.c | 1 +
drivers/baseband/la12xx/bbdev_la12xx.c | 1 +
drivers/baseband/null/bbdev_null.c | 1 +
drivers/baseband/turbo_sw/bbdev_turbo_software.c | 1 +
lib/bbdev/rte_bbdev.c | 24 +++
lib/bbdev/rte_bbdev.h | 35
--
lib/bbdev/version.map | 6
9 files changed, 69 insertions(+), 2 deletions(-)
diff --git a/drivers/baseband/acc100/rte_acc100_pmd.c
b/drivers/baseband/acc100/rte_acc100_pmd.c
index de7e4bc..17ba798 100644
--- a/drivers/baseband/acc100/rte_acc100_pmd.c
+++ b/drivers/baseband/acc100/rte_acc100_pmd.c
@@ -1060,6 +1060,7 @@
/* Read and save the populated config from ACC100 registers */
fetch_acc100_config(dev);
+ dev_info->device_status = RTE_BBDEV_DEV_NOT_SUPPORTED;
/* This isn't ideal because it reports the maximum number of
queues
but
* does not provide info on how many can be uplink/downlink or
different diff --git
a/drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c
b/drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c
index 82ae6ba..57b12af 100644
--- a/drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c
+++ b/drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c
@@ -369,6 +369,7 @@
dev_info->capabilities = bbdev_capabilities;
dev_info->cpu_flag_reqs = NULL;
dev_info->data_endianness = RTE_LITTLE_ENDIAN;
+ dev_info->device_status = RTE_BBDEV_DEV_NOT_SUPPORTED;
/* Calculates number of queues assigned to device */
dev_info->max_num_queues = 0;
diff --git a/drivers/baseband/fpga_lte_fec/fpga_lte_fec.c
b/drivers/baseband/fpga_lte_fec/fpga_lte_fec.c
index 21d3529..2a330c4 100644
--- a/drivers/baseband/fpga_lte_fec/fpga_lte_fec.c
+++ b/drivers/baseband/fpga_lte_fec/fpga_lte_fec.c
@@ -645,6 +645,7 @@ struct __rte_cache_aligned fpga_queue {
dev_info->capabilities = bbdev_capabilities;
dev_info->cpu_flag_reqs = NULL;
dev_info->data_endianness = RTE_LITTLE_ENDIAN;
+ dev_info->device_status = RTE_BBDEV_DEV_NOT_SUPPORTED;
/* Calculates number of queues assigned to device */
dev_info->max_num_queues = 0;
diff --git a/drivers/baseband/la12xx/bbdev_la12xx.c
b/drivers/baseband/la12xx/bbdev_la12xx.c
index 4d1bd16..c1f88c6 100644
--- a/drivers/baseband/la12xx/bbdev_la12xx.c
+++ b/drivers/baseband/la12xx/bbdev_la12xx.c
@@ -100,6 +100,7 @@ struct bbdev_la12xx_params {
dev_info->capabilities = bbdev_capabilities;
dev_info->cpu_flag_reqs = NULL;
dev_info->min_alignment = 64;
+ dev_info->device_status = RTE_BBDEV_DEV_NOT_SUPPORTED;
rte_bbdev_log_debug("got device info from %u", dev->data->dev_id);
}
diff --git a/drivers/baseband/null/bbdev_null.c
b/drivers/baseband/null/bbdev_null.c
index 248e129..94a1976 100644
--- a/drivers/baseband/null/bbdev_null.c
+++ b/drivers/baseband/null/bbdev_null.c
@@ -82,6 +82,7 @@ struct bbdev_queue {
* here for code completeness.
*/
dev_info->data_endianness = RTE_LITTLE_ENDIAN;
+ dev_info->device_status = RTE_BBDEV_DEV_NOT_SUPPORTED;
rte_bbdev_log_debug("got device info from %u", dev->data->dev_id);
}
diff --git a/drivers/baseband/turbo_sw/bbdev_turbo_software.c
b/drivers/baseband/turbo_sw/bbdev_turbo_software.c
index af7bc41..dbc5524 100644
--- a/drivers/baseband/turbo_sw/bbdev_turbo_software.c
+++ b/drivers/baseband/turbo_sw/bbdev_turbo_software.c
@@ -254,6 +254,7 @@ struct turbo_sw_queue {
dev_info->min_alignment = 64;
dev_info->harq_buffer_size = 0;
dev_info->data_endianness = RTE_LITTLE_ENDIAN;
+ dev_info->device_status = RTE_BBDEV_DEV_NOT_SUPPORTED;
rte_bbdev_log_debug("got device info from %u\n", dev->data-
dev_id);
}
diff --git a/lib/bb
Re: [PATCH v4 4/7] drivers/baseband: update PMDs to expose queue per operation
On 7/7/22 10:19 AM, Chautru, Nicolas wrote:
Hi Tom,
-Original Message-
From: Tom Rix
Sent: Thursday, July 7, 2022 6:21 AM
To: Chautru, Nicolas ; dev@dpdk.org;
tho...@monjalon.net; gak...@marvell.com; hemant.agra...@nxp.com
Cc: maxime.coque...@redhat.com; m...@ashroe.eu; Richardson, Bruce
; david.march...@redhat.com;
step...@networkplumber.org
Subject: Re: [PATCH v4 4/7] drivers/baseband: update PMDs to expose queue
per operation
On 7/6/22 2:10 PM, Chautru, Nicolas wrote:
Hi Tom,
-Original Message-
From: Tom Rix
Sent: Wednesday, July 6, 2022 9:15 AM
To: Chautru, Nicolas ; dev@dpdk.org;
tho...@monjalon.net; gak...@marvell.com; hemant.agra...@nxp.com
Cc: maxime.coque...@redhat.com; m...@ashroe.eu; Richardson, Bruce
; david.march...@redhat.com;
step...@networkplumber.org
Subject: Re: [PATCH v4 4/7] drivers/baseband: update PMDs to expose
queue per operation
On 7/5/22 5:23 PM, Nicolas Chautru wrote:
Add support in existing bbdev PMDs for the explicit number of queue
and priority for each operation type configured on the device.
Signed-off-by: Nicolas Chautru
---
drivers/baseband/acc100/rte_acc100_pmd.c | 29 +--
---
drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c | 8 ++
drivers/baseband/fpga_lte_fec/fpga_lte_fec.c | 8 ++
drivers/baseband/la12xx/bbdev_la12xx.c | 7 ++
drivers/baseband/turbo_sw/bbdev_turbo_software.c | 11
5 files changed, 51 insertions(+), 12 deletions(-)
diff --git a/drivers/baseband/acc100/rte_acc100_pmd.c
b/drivers/baseband/acc100/rte_acc100_pmd.c
index 17ba798..d568d0d 100644
--- a/drivers/baseband/acc100/rte_acc100_pmd.c
+++ b/drivers/baseband/acc100/rte_acc100_pmd.c
@@ -966,6 +966,7 @@
struct rte_bbdev_driver_info *dev_info)
{
struct acc100_device *d = dev->data->dev_private;
+ int i;
static const struct rte_bbdev_op_cap bbdev_capabilities[] = {
{
@@ -1062,19 +1063,23 @@
fetch_acc100_config(dev);
dev_info->device_status = RTE_BBDEV_DEV_NOT_SUPPORTED;
- /* This isn't ideal because it reports the maximum number of queues
but
-* does not provide info on how many can be uplink/downlink or
different
-* priorities
-*/
- dev_info->max_num_queues =
- d->acc100_conf.q_dl_5g.num_aqs_per_groups *
- d->acc100_conf.q_dl_5g.num_qgroups +
- d->acc100_conf.q_ul_5g.num_aqs_per_groups *
- d->acc100_conf.q_ul_5g.num_qgroups +
- d->acc100_conf.q_dl_4g.num_aqs_per_groups *
- d->acc100_conf.q_dl_4g.num_qgroups +
- d->acc100_conf.q_ul_4g.num_aqs_per_groups *
+ /* Expose number of queues */
+ dev_info->num_queues[RTE_BBDEV_OP_NONE] = 0;
+ dev_info->num_queues[RTE_BBDEV_OP_TURBO_DEC] =
+d->acc100_conf.q_ul_4g.num_aqs_per_groups *
d->acc100_conf.q_ul_4g.num_qgroups;
+ dev_info->num_queues[RTE_BBDEV_OP_TURBO_ENC] = d-
acc100_conf.q_dl_4g.num_aqs_per_groups *
+ d->acc100_conf.q_dl_4g.num_qgroups;
+ dev_info->num_queues[RTE_BBDEV_OP_LDPC_DEC] = d-
acc100_conf.q_ul_5g.num_aqs_per_groups *
+ d->acc100_conf.q_ul_5g.num_qgroups;
+ dev_info->num_queues[RTE_BBDEV_OP_LDPC_ENC] = d-
acc100_conf.q_dl_5g.num_aqs_per_groups *
+ d->acc100_conf.q_dl_5g.num_qgroups;
+ dev_info->queue_priority[RTE_BBDEV_OP_TURBO_DEC] = d-
acc100_conf.q_ul_4g.num_qgroups;
+ dev_info->queue_priority[RTE_BBDEV_OP_TURBO_ENC] = d-
acc100_conf.q_dl_4g.num_qgroups;
+ dev_info->queue_priority[RTE_BBDEV_OP_LDPC_DEC] = d-
acc100_conf.q_ul_5g.num_qgroups;
+ dev_info->queue_priority[RTE_BBDEV_OP_LDPC_ENC] = d-
acc100_conf.q_dl_5g.num_qgroups;
+ dev_info->max_num_queues = 0;
+ for (i = RTE_BBDEV_OP_TURBO_DEC; i < RTE_BBDEV_OP_LDPC_ENC;
i++)
should this be i <= ?
Thanks
+ dev_info->max_num_queues += dev_info->num_queues[i];
dev_info->queue_size_lim = ACC100_MAX_QUEUE_DEPTH;
dev_info->hardware_accelerated = true;
dev_info->max_dl_queue_priority = diff --git
a/drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c
b/drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c
index 57b12af..b4982af 100644
--- a/drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c
+++ b/drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c
@@ -379,6 +379,14 @@
if (hw_q_id != FPGA_INVALID_HW_QUEUE_ID)
dev_info->max_num_queues++;
}
+ /* Expose number of queue per operation type */
+ dev_info->num_queues[RTE_BBDEV_OP_NONE] = 0;
+ dev_info->num_queues[RTE_BBDEV_OP_TURBO_DEC] = 0;
+ dev_info->num_queues[RTE_BBDEV_OP_
Re: [PATCH v4 5/7] bbdev: add new operation for FFT processing
On 7/7/22 9:57 AM, Chautru, Nicolas wrote: Hi Tom, -Original Message- From: Tom Rix Nic, Not all my comments were addressed. The one I am most interested in is the default type / size and how it interacts with fp16. My bad, I had replied to all that (and fixed some of them in the new version) but I must have NOT sent the latest draft of that email by mistake. Let me go through it again below and let me know if unclear. This seems like a pattern. In the future address all the issues raised in the review in the first response. Dribbling out responses looses the cohesion of the review. No reviewer has the time so chase down this-or-that point when the responses and changes are spread out over multiple reviews. Please see the others below On 7/6/22 2:04 PM, Chautru, Nicolas wrote: Hi Tom, -Original Message- From: Tom Rix > On 7/5/22 5:23 PM, Nicolas Chautru wrote: Extension of bbdev operation to support FFT based operations. Signed-off-by: Nicolas Chautru Acked-by: Hemant Agrawal --- doc/guides/prog_guide/bbdev.rst | 130 +++ lib/bbdev/rte_bbdev.c | 11 ++- lib/bbdev/rte_bbdev.h | 76 lib/bbdev/rte_bbdev_op.h| 149 lib/bbdev/version.map | 4 ++ 5 files changed, 369 insertions(+), 1 deletion(-) diff --git a/doc/guides/prog_guide/bbdev.rst b/doc/guides/prog_guide/bbdev.rst index 70fa01a..4a055b5 100644 --- a/doc/guides/prog_guide/bbdev.rst +++ b/doc/guides/prog_guide/bbdev.rst @@ -1118,6 +1118,136 @@ Figure :numref:`figure_turbo_tb_decode` above showing the Turbo decoding of CBs using BBDEV interface in TB-mode is also valid for LDPC decode. +BBDEV FFT Operation + + +This operation allows to run a combination of DFT and/or IDFT +and/or time- domain windowing. +These can be used in a modular fashion (using bypass modes) or as a +processing pipeline which can be used for FFT-based baseband signal processing. +In more details it allows : +- to process the data first through an IDFT of adjustable size and +padding; +- to perform the windowing as a programmable cyclic shift offset of +the data followed by a pointwise multiplication by a time domain +window; +- to process the related data through a DFT of adjustable size and +depadding for each such cyclic shift output. + +A flexible number of Rx antennas are being processed in parallel +with the same configuration. +The API allows more generally for flexibility in what the PMD may +support (cabability flags) and flexibility to adjust some of the +parameters of the processing. + +The operation/capability flags that can be set for each FFT +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 FFT capability flags | ++=== = +++ +|RTE_BBDEV_FFT_WINDOWING | +| Set to enable/support windowing in time domain | +++ +|RTE_BBDEV_FFT_CS_ADJUSTMENT | +| Set to enable/support the cyclic shift time offset adjustment | +++ +|RTE_BBDEV_FFT_DFT_BYPASS| +| Set to bypass the DFT and use directly the IDFT as an option | +++ +|RTE_BBDEV_FFT_IDFT_BYPASS | +| Set to bypass the IDFT and use directly the DFT as an option | +++ +|RTE_BBDEV_FFT_WINDOWING_BYPASS | +| Set to bypass the time domain windowing as an option | +++ +|RTE_BBDEV_FFT_POWER_MEAS Other flags are not truncated, should be RTE_BBDEV_FFT_POWER_MEASUREMENT The intention from DPDK recommendation is for these to be kept shortnames, isn't it? Above we use many acronyms to keep it short (CS, etc...) Even in current BBDEV API we use many truncation to keep names short: OUT, ENC/DEC, HQ, RM on top of acronyms. I believe this is still super explicit with that name? Some of other identifier have longer names than this. If you wanted to keep things short, drop the last _ Generally the use of acronyms should be avoided because they add a layer of jargon that makes the code less readable to all but writer
Re: [PATCH v1 00/10] baseband/acc200
Hernan The changes I requested in v4, were not addressed in v5. Can you make these changes for v6? Tom On 7/22/22 11:29 AM, Vargas, Hernan wrote: Hi Tom, The patch series for the ACC200 can wait until Nic's back. Our priority are the changes for the bbdev API here: https://patches.dpdk.org/project/dpdk/list/?series=23912 Thanks, Hernan -Original Message- From: Tom Rix Sent: Sunday, July 17, 2022 8:08 AM To: Vargas, Hernan ; Maxime Coquelin ; Chautru, Nicolas ; dev@dpdk.org; tho...@monjalon.net; gak...@marvell.com; hemant.agra...@nxp.com Cc: m...@ashroe.eu; Richardson, Bruce ; david.march...@redhat.com; step...@networkplumber.org Subject: Re: [PATCH v1 00/10] baseband/acc200 On 7/14/22 11:49 AM, Vargas, Hernan wrote: Hi Tom, Maxime, Could you please review the v5 series that Nic submitted last week? https://patches.dpdk.org/project/dpdk/list/?series=23912 Thanks, Hernan Hernan, For this patch series for the acc200, will you be able to refactor it so acc has a common base ? Or will this be on hold until Nic is back ? Tom -Original Message- From: Maxime Coquelin Sent: Tuesday, July 12, 2022 8:49 AM To: Chautru, Nicolas ; dev@dpdk.org; tho...@monjalon.net; gak...@marvell.com; hemant.agra...@nxp.com; t...@redhat.com; Vargas, Hernan Cc: m...@ashroe.eu; Richardson, Bruce ; david.march...@redhat.com; step...@networkplumber.org Subject: Re: [PATCH v1 00/10] baseband/acc200 Hi Nicolas, Hernan, (Adding Hernan in the recipients list) On 7/8/22 02:01, Nicolas Chautru wrote: This is targeting 22.11 and includes the PMD for the integrated accelerator on Intel Xeon SPR-EEC. There is a dependency on that parallel serie still in-flight which extends the bbdev api https://patches.dpdk.org/project/dpdk/list/?series=23894 I will be offline for a few weeks for the summer break but Hernan will cover for me during that time if required. Thanks Nic Nicolas Chautru (10): baseband/acc200: introduce PMD for ACC200 baseband/acc200: add HW register definitions baseband/acc200: add info get function baseband/acc200: add queue configuration baseband/acc200: add LDPC processing functions baseband/acc200: add LTE processing functions baseband/acc200: add support for FFT operations baseband/acc200: support interrupt baseband/acc200: add device status and vf2pf comms baseband/acc200: add PF configure companion function MAINTAINERS |3 + app/test-bbdev/meson.build |3 + app/test-bbdev/test_bbdev_perf.c | 76 + doc/guides/bbdevs/acc200.rst | 244 ++ doc/guides/bbdevs/index.rst |1 + drivers/baseband/acc200/acc200_pf_enum.h | 468 +++ drivers/baseband/acc200/acc200_pmd.h | 690 drivers/baseband/acc200/acc200_vf_enum.h | 89 + drivers/baseband/acc200/meson.build |8 + drivers/baseband/acc200/rte_acc200_cfg.h | 115 + drivers/baseband/acc200/rte_acc200_pmd.c | 5403 ++ drivers/baseband/acc200/version.map | 10 + drivers/baseband/meson.build |1 + 13 files changed, 7111 insertions(+) create mode 100644 doc/guides/bbdevs/acc200.rst create mode 100644 drivers/baseband/acc200/acc200_pf_enum.h create mode 100644 drivers/baseband/acc200/acc200_pmd.h create mode 100644 drivers/baseband/acc200/acc200_vf_enum.h create mode 100644 drivers/baseband/acc200/meson.build create mode 100644 drivers/baseband/acc200/rte_acc200_cfg.h create mode 100644 drivers/baseband/acc200/rte_acc200_pmd.c create mode 100644 drivers/baseband/acc200/version.map Comparing ACC200 & ACC100 header files, I understand ACC200 is an evolution of the ACC10x family. The FEC bits are really close, ACC200 main addition seems to be FFT acceleration which could be handled in ACC10x driver based on device ID. I think both drivers have to be merged in order to avoid code duplication. That's how other families of devices (e.g. i40e) are handled. Thanks, Maxime
Re: [PATCH v1 00/33] baseband/acc100: changes for 22.11
On 8/15/22 10:52 PM, Hernan Vargas wrote: Upstreaming ACC100 changes for 22.11. This patch series is dependant on series: https://patches.dpdk.org/project/dpdk/patch/1657150110-69957 Can you go into some more detail about these changes ? Ex/ which are the fixes and which are the features ? Tom Hernan Vargas (33): baseband/acc100: update dev close function baseband/acc100: quit queue setup for undef dev baseband/acc100: add default e value for FCW baseband/acc100: add LDPC encoder padding function baseband/acc100: add scatter-gather support baseband/acc100: add HARQ index helper function baseband/acc100: avoid mux for small inbound frames baseband/acc100: separate validation functions from debug baseband/acc100: add LDPC transport block support baseband/acc10x: limit cases for HARQ pruning baseband/acc100: update validate LDPC enc/dec baseband/acc100: add workaround for deRM corner cases baseband/acc100: enable vf2pf doorbell register baseband/acc100: add ring companion address baseband/acc100: configure PMON control registers baseband/acc100: configurable queue depth baseband/acc100: add queue stop operation basbeband/acc100: check turbo dec/enc input baseband/acc100: check for unlikely operation vals baseband/acc100: enforce additional check on FCW baseband/acc100: update uplink CB input length baseband/acc100: rename ldpc encode function arg baseband/acc100: update log messages baseband/acc100: allocate ring/queue mem when NULL baseband/acc100: store FCW from first CB descriptor baseband/acc100: remove input error check from enc baseband/acc100: make desc optimization optional baseband/acc100: update device info baseband/acc100: reduce input length for CRC24B baseband/acc100: initialize ring data value baseband/acc100: update debug print for LDPC FCW baseband/acc100: set device min alignment to 1 baseband/acc100: update meson file sdk dependency drivers/baseband/acc100/acc100_pmd.h | 41 +- drivers/baseband/acc100/acc100_vf_enum.h |6 + drivers/baseband/acc100/meson.build | 21 + drivers/baseband/acc100/rte_acc100_pmd.c | 1196 ++ 4 files changed, 1068 insertions(+), 196 deletions(-)
Re: [PATCH v1 00/10] baseband/acc200
On 8/30/22 12:45 PM, Chautru, Nicolas wrote: Hi Maxime, -Original Message- From: Maxime Coquelin Sent: Tuesday, August 30, 2022 12:45 AM To: Chautru, Nicolas ; dev@dpdk.org; tho...@monjalon.net; gak...@marvell.com; hemant.agra...@nxp.com; t...@redhat.com; Vargas, Hernan Cc: m...@ashroe.eu; Richardson, Bruce ; david.march...@redhat.com; step...@networkplumber.org Subject: Re: [PATCH v1 00/10] baseband/acc200 Hi Nicolas, On 7/12/22 15:48, Maxime Coquelin wrote: Hi Nicolas, Hernan, (Adding Hernan in the recipients list) On 7/8/22 02:01, Nicolas Chautru wrote: This is targeting 22.11 and includes the PMD for the integrated accelerator on Intel Xeon SPR-EEC. There is a dependency on that parallel serie still in-flight which extends the bbdev api https://patches.dpdk.org/project/dpdk/list/?series=23894 I will be offline for a few weeks for the summer break but Hernan will cover for me during that time if required. Thanks Nic Nicolas Chautru (10): baseband/acc200: introduce PMD for ACC200 baseband/acc200: add HW register definitions baseband/acc200: add info get function baseband/acc200: add queue configuration baseband/acc200: add LDPC processing functions baseband/acc200: add LTE processing functions baseband/acc200: add support for FFT operations baseband/acc200: support interrupt baseband/acc200: add device status and vf2pf comms baseband/acc200: add PF configure companion function MAINTAINERS | 3 + app/test-bbdev/meson.build | 3 + app/test-bbdev/test_bbdev_perf.c | 76 + doc/guides/bbdevs/acc200.rst | 244 ++ doc/guides/bbdevs/index.rst | 1 + drivers/baseband/acc200/acc200_pf_enum.h | 468 +++ drivers/baseband/acc200/acc200_pmd.h | 690 drivers/baseband/acc200/acc200_vf_enum.h | 89 + drivers/baseband/acc200/meson.build | 8 + drivers/baseband/acc200/rte_acc200_cfg.h | 115 + drivers/baseband/acc200/rte_acc200_pmd.c | 5403 ++ drivers/baseband/acc200/version.map | 10 + drivers/baseband/meson.build | 1 + 13 files changed, 7111 insertions(+) create mode 100644 doc/guides/bbdevs/acc200.rst create mode 100644 drivers/baseband/acc200/acc200_pf_enum.h create mode 100644 drivers/baseband/acc200/acc200_pmd.h create mode 100644 drivers/baseband/acc200/acc200_vf_enum.h create mode 100644 drivers/baseband/acc200/meson.build create mode 100644 drivers/baseband/acc200/rte_acc200_cfg.h create mode 100644 drivers/baseband/acc200/rte_acc200_pmd.c create mode 100644 drivers/baseband/acc200/version.map Comparing ACC200 & ACC100 header files, I understand ACC200 is an evolution of the ACC10x family. The FEC bits are really close, ACC200 main addition seems to be FFT acceleration which could be handled in ACC10x driver based on device ID. I think both drivers have to be merged in order to avoid code duplication. That's how other families of devices (e.g. i40e) are handled. I haven't seen your reply on this point. Do you confirm you are working on a single driver for ACC family in order to avoid code duplication? The implementation is based on distinct ACC100 and ACC200 drivers. The 2 devices are fundamentally different generation, processes and IP. MountBryce is an eASIC device over PCIe while ACC200 is an integrated accelerator on Xeon CPU. The actual implementation are not the same, underlying IP are all distinct even if many of the descriptor format have similarities. The actual capabilities of the acceleration are different and/or new. The workaround and silicon errata are also different causing different limitation and implementation in the driver (see the serie with ongoing changes for ACC100 in parallel). This is fundamentally distinct from ACC101 which was a derivative product from ACC100 and where it made sense to share implementation between ACC100 and ACC101. So in a nutshell these 2 devices and drivers are 2 different beasts and the intention is to keep them intentionally separate as in the serie. Let me know if unclear, thanks! Nic, I used a similarity checker to compare acc100 and acc200 https://dickgrune.com/Programs/similarity_tester/ l=simum.log if [ -f $l ]; then rm $l fi sim_c -s -R -o$l -R -p -P -a . There results are ./acc200/acc200_pf_enum.h consists for 100 % of ./acc100/acc100_pf_enum.h material ./acc100/acc100_pf_enum.h consists for 98 % of ./acc200/acc200_pf_enum.h material ./acc100/rte_acc100_pmd.h consists for 98 % of ./acc200/acc200_pmd.h material ./acc200/acc200_vf_enum.h consists for 95 % of ./acc100/acc100_pf_enum.h material ./acc200/acc200_pmd.h consists for 92 % of ./acc100/rte_acc100_pmd.h material ./acc200/rte_acc200_cfg.h consists for 92 % of ./acc100/rte_acc100_cfg.h material ./acc100/rte_acc100_pmd.c consists for 87 % of ./acc200/rte_acc200_pmd.c material ./acc100/acc100_vf_enum
Re: [PATCH v1 00/10] baseband/acc200
On 8/31/22 3:37 PM, Chautru, Nicolas wrote: Hi Thomas, Tom, -Original Message- From: Tom Rix Sent: Wednesday, August 31, 2022 12:26 PM To: Chautru, Nicolas ; Maxime Coquelin ; dev@dpdk.org; tho...@monjalon.net; gak...@marvell.com; hemant.agra...@nxp.com; Vargas, Hernan Cc: m...@ashroe.eu; Richardson, Bruce ; david.march...@redhat.com; step...@networkplumber.org Subject: Re: [PATCH v1 00/10] baseband/acc200 On 8/30/22 12:45 PM, Chautru, Nicolas wrote: Hi Maxime, -Original Message- From: Maxime Coquelin Sent: Tuesday, August 30, 2022 12:45 AM To: Chautru, Nicolas ; dev@dpdk.org; tho...@monjalon.net; gak...@marvell.com; hemant.agra...@nxp.com; t...@redhat.com; Vargas, Hernan Cc: m...@ashroe.eu; Richardson, Bruce ; david.march...@redhat.com; step...@networkplumber.org Subject: Re: [PATCH v1 00/10] baseband/acc200 Hi Nicolas, On 7/12/22 15:48, Maxime Coquelin wrote: Hi Nicolas, Hernan, (Adding Hernan in the recipients list) On 7/8/22 02:01, Nicolas Chautru wrote: This is targeting 22.11 and includes the PMD for the integrated accelerator on Intel Xeon SPR-EEC. There is a dependency on that parallel serie still in-flight which extends the bbdev api https://patches.dpdk.org/project/dpdk/list/?series=23894 I will be offline for a few weeks for the summer break but Hernan will cover for me during that time if required. Thanks Nic Nicolas Chautru (10): baseband/acc200: introduce PMD for ACC200 baseband/acc200: add HW register definitions baseband/acc200: add info get function baseband/acc200: add queue configuration baseband/acc200: add LDPC processing functions baseband/acc200: add LTE processing functions baseband/acc200: add support for FFT operations baseband/acc200: support interrupt baseband/acc200: add device status and vf2pf comms baseband/acc200: add PF configure companion function MAINTAINERS | 3 + app/test-bbdev/meson.build | 3 + app/test-bbdev/test_bbdev_perf.c | 76 + doc/guides/bbdevs/acc200.rst | 244 ++ doc/guides/bbdevs/index.rst | 1 + drivers/baseband/acc200/acc200_pf_enum.h | 468 +++ drivers/baseband/acc200/acc200_pmd.h | 690 drivers/baseband/acc200/acc200_vf_enum.h | 89 + drivers/baseband/acc200/meson.build | 8 + drivers/baseband/acc200/rte_acc200_cfg.h | 115 + drivers/baseband/acc200/rte_acc200_pmd.c | 5403 ++ drivers/baseband/acc200/version.map | 10 + drivers/baseband/meson.build | 1 + 13 files changed, 7111 insertions(+) create mode 100644 doc/guides/bbdevs/acc200.rst create mode 100644 drivers/baseband/acc200/acc200_pf_enum.h create mode 100644 drivers/baseband/acc200/acc200_pmd.h create mode 100644 drivers/baseband/acc200/acc200_vf_enum.h create mode 100644 drivers/baseband/acc200/meson.build create mode 100644 drivers/baseband/acc200/rte_acc200_cfg.h create mode 100644 drivers/baseband/acc200/rte_acc200_pmd.c create mode 100644 drivers/baseband/acc200/version.map Comparing ACC200 & ACC100 header files, I understand ACC200 is an evolution of the ACC10x family. The FEC bits are really close, ACC200 main addition seems to be FFT acceleration which could be handled in ACC10x driver based on device ID. I think both drivers have to be merged in order to avoid code duplication. That's how other families of devices (e.g. i40e) are handled. I haven't seen your reply on this point. Do you confirm you are working on a single driver for ACC family in order to avoid code duplication? The implementation is based on distinct ACC100 and ACC200 drivers. The 2 devices are fundamentally different generation, processes and IP. MountBryce is an eASIC device over PCIe while ACC200 is an integrated accelerator on Xeon CPU. The actual implementation are not the same, underlying IP are all distinct even if many of the descriptor format have similarities. The actual capabilities of the acceleration are different and/or new. The workaround and silicon errata are also different causing different limitation and implementation in the driver (see the serie with ongoing changes for ACC100 in parallel). This is fundamentally distinct from ACC101 which was a derivative product from ACC100 and where it made sense to share implementation between ACC100 and ACC101. So in a nutshell these 2 devices and drivers are 2 different beasts and the intention is to keep them intentionally separate as in the serie. Let me know if unclear, thanks! Nic, I used a similarity checker to compare acc100 and acc200 https://dickgrune.com/Programs/similarity_tester/ l=simum.log if [ -f $l ]; then rm $l fi sim_c -s -R -o$l -R -p -P -a . There results are ./acc200/acc200_pf_enum.h consists for 100 % of ./acc100/acc100_pf_enum.h material ./acc100/acc100_pf_enum.h consis
Re: [PATCH v1 00/10] baseband/acc200
On 8/31/22 6:26 PM, Chautru, Nicolas wrote: Hi Tom, -Original Message- From: Tom Rix Sent: Wednesday, August 31, 2022 5:28 PM To: Chautru, Nicolas ; Maxime Coquelin ; dev@dpdk.org; tho...@monjalon.net; gak...@marvell.com; hemant.agra...@nxp.com; Vargas, Hernan Cc: m...@ashroe.eu; Richardson, Bruce ; david.march...@redhat.com; step...@networkplumber.org Subject: Re: [PATCH v1 00/10] baseband/acc200 On 8/31/22 3:37 PM, Chautru, Nicolas wrote: Hi Thomas, Tom, -Original Message- From: Tom Rix Sent: Wednesday, August 31, 2022 12:26 PM To: Chautru, Nicolas ; Maxime Coquelin ; dev@dpdk.org; tho...@monjalon.net; gak...@marvell.com; hemant.agra...@nxp.com; Vargas, Hernan Cc: m...@ashroe.eu; Richardson, Bruce ; david.march...@redhat.com; step...@networkplumber.org Subject: Re: [PATCH v1 00/10] baseband/acc200 On 8/30/22 12:45 PM, Chautru, Nicolas wrote: Hi Maxime, -Original Message- From: Maxime Coquelin Sent: Tuesday, August 30, 2022 12:45 AM To: Chautru, Nicolas ; dev@dpdk.org; tho...@monjalon.net; gak...@marvell.com; hemant.agra...@nxp.com; t...@redhat.com; Vargas, Hernan Cc: m...@ashroe.eu; Richardson, Bruce ; david.march...@redhat.com; step...@networkplumber.org Subject: Re: [PATCH v1 00/10] baseband/acc200 Hi Nicolas, On 7/12/22 15:48, Maxime Coquelin wrote: Hi Nicolas, Hernan, (Adding Hernan in the recipients list) On 7/8/22 02:01, Nicolas Chautru wrote: This is targeting 22.11 and includes the PMD for the integrated accelerator on Intel Xeon SPR-EEC. There is a dependency on that parallel serie still in-flight which extends the bbdev api https://patches.dpdk.org/project/dpdk/list/?series=23894 I will be offline for a few weeks for the summer break but Hernan will cover for me during that time if required. Thanks Nic Nicolas Chautru (10): baseband/acc200: introduce PMD for ACC200 baseband/acc200: add HW register definitions baseband/acc200: add info get function baseband/acc200: add queue configuration baseband/acc200: add LDPC processing functions baseband/acc200: add LTE processing functions baseband/acc200: add support for FFT operations baseband/acc200: support interrupt baseband/acc200: add device status and vf2pf comms baseband/acc200: add PF configure companion function MAINTAINERS | 3 + app/test-bbdev/meson.build | 3 + app/test-bbdev/test_bbdev_perf.c | 76 + doc/guides/bbdevs/acc200.rst | 244 ++ doc/guides/bbdevs/index.rst | 1 + drivers/baseband/acc200/acc200_pf_enum.h | 468 +++ drivers/baseband/acc200/acc200_pmd.h | 690 drivers/baseband/acc200/acc200_vf_enum.h | 89 + drivers/baseband/acc200/meson.build | 8 + drivers/baseband/acc200/rte_acc200_cfg.h | 115 + drivers/baseband/acc200/rte_acc200_pmd.c | 5403 ++ drivers/baseband/acc200/version.map | 10 + drivers/baseband/meson.build | 1 + 13 files changed, 7111 insertions(+) create mode 100644 doc/guides/bbdevs/acc200.rst create mode 100644 drivers/baseband/acc200/acc200_pf_enum.h create mode 100644 drivers/baseband/acc200/acc200_pmd.h create mode 100644 drivers/baseband/acc200/acc200_vf_enum.h create mode 100644 drivers/baseband/acc200/meson.build create mode 100644 drivers/baseband/acc200/rte_acc200_cfg.h create mode 100644 drivers/baseband/acc200/rte_acc200_pmd.c create mode 100644 drivers/baseband/acc200/version.map Comparing ACC200 & ACC100 header files, I understand ACC200 is an evolution of the ACC10x family. The FEC bits are really close, ACC200 main addition seems to be FFT acceleration which could be handled in ACC10x driver based on device ID. I think both drivers have to be merged in order to avoid code duplication. That's how other families of devices (e.g. i40e) are handled. I haven't seen your reply on this point. Do you confirm you are working on a single driver for ACC family in order to avoid code duplication? The implementation is based on distinct ACC100 and ACC200 drivers. The 2 devices are fundamentally different generation, processes and IP. MountBryce is an eASIC device over PCIe while ACC200 is an integrated accelerator on Xeon CPU. The actual implementation are not the same, underlying IP are all distinct even if many of the descriptor format have similarities. The actual capabilities of the acceleration are different and/or new. The workaround and silicon errata are also different causing different limitation and implementation in the driver (see the serie with ongoing changes for ACC100 in parallel). This is fundamentally distinct from ACC101 which was a derivative product from ACC100 and where it made sense to share implementation between ACC100 and ACC101. So in a nutshell these 2 devices and drivers are 2 different
Re: [dpdk-dev] [PATCH v5 1/7] app/bbdev: add explicit ut for latency vs validation
On 10/23/20 4:42 PM, Nicolas Chautru wrote:
> Adding explicit different ut when testing for validation
> or latency (early termination enabled or not).
>
> Signed-off-by: Nicolas Chautru
> Acked-by: Aidan Goddard
> Acked-by: Dave Burley
> ---
> app/test-bbdev/test_bbdev_perf.c | 92
> ++--
Should update the copyright.
> 1 file changed, 88 insertions(+), 4 deletions(-)
>
> diff --git a/app/test-bbdev/test_bbdev_perf.c
> b/app/test-bbdev/test_bbdev_perf.c
> index 6e5535d..3554a77 100644
> --- a/app/test-bbdev/test_bbdev_perf.c
> +++ b/app/test-bbdev/test_bbdev_perf.c
> @@ -3999,12 +3999,14 @@ typedef int (test_case_function)(struct active_device
> *ad,
> return i;
> }
>
> +/* Test case for latency/validation for LDPC Decoder */
> static int
> latency_test_ldpc_dec(struct rte_mempool *mempool,
> struct test_buffers *bufs, struct rte_bbdev_dec_op *ref_op,
> int vector_mask, uint16_t dev_id, uint16_t queue_id,
> const uint16_t num_to_process, uint16_t burst_sz,
> - uint64_t *total_time, uint64_t *min_time, uint64_t *max_time)
> + uint64_t *total_time, uint64_t *min_time, uint64_t *max_time,
> + bool disable_et)
> {
> int ret = TEST_SUCCESS;
> uint16_t i, j, dequeued;
> @@ -4026,7 +4028,7 @@ typedef int (test_case_function)(struct active_device
> *ad,
> "rte_bbdev_dec_op_alloc_bulk() failed");
>
> /* For latency tests we need to disable early termination */
> - if (check_bit(ref_op->ldpc_dec.op_flags,
> + if (disable_et && check_bit(ref_op->ldpc_dec.op_flags,
> RTE_BBDEV_LDPC_ITERATION_STOP_ENABLE))
> ref_op->ldpc_dec.op_flags -=
> RTE_BBDEV_LDPC_ITERATION_STOP_ENABLE;
Bit clearing is usually done with &= ~()
> @@ -4248,7 +4250,7 @@ typedef int (test_case_function)(struct active_device
> *ad,
> TEST_ASSERT_NOT_NULL(op_type_str, "Invalid op type: %u", op_type);
>
> printf("+ --- +\n");
> - printf("== test: validation/latency\ndev: %s, burst size: %u, num ops:
> %u, op type: %s\n",
> + printf("== test: latency\ndev: %s, burst size: %u, num ops: %u, op
> type: %s\n",
> info.dev_name, burst_sz, num_to_process, op_type_str);
>
> if (op_type == RTE_BBDEV_OP_TURBO_DEC)
> @@ -4270,7 +4272,83 @@ typedef int (test_case_function)(struct active_device
> *ad,
> iter = latency_test_ldpc_dec(op_params->mp, bufs,
> op_params->ref_dec_op, op_params->vector_mask,
> ad->dev_id, queue_id, num_to_process,
> + burst_sz, &total_time, &min_time, &max_time,
> + true);
> + else
> + iter = latency_test_enc(op_params->mp, bufs,
> + op_params->ref_enc_op,
> + ad->dev_id, queue_id,
> + num_to_process, burst_sz, &total_time,
> + &min_time, &max_time);
This is a repeat of RTE_BBDEV_OP_TURBO_ENC.
Do not need both.
If the point is to have a else and not fail when the op_type is unknown, then
remove the earlier all and comment the else something like
else /* RTE_BBDEC_OP_TURBO_ENC */
> +
> + if (iter <= 0)
> + return TEST_FAILED;
> +
> + printf("Operation latency:\n"
> + "\tavg: %lg cycles, %lg us\n"
> + "\tmin: %lg cycles, %lg us\n"
> + "\tmax: %lg cycles, %lg us\n",
> + (double)total_time / (double)iter,
> + (double)(total_time * 100) / (double)iter /
> + (double)rte_get_tsc_hz(), (double)min_time,
> + (double)(min_time * 100) / (double)rte_get_tsc_hz(),
> + (double)max_time, (double)(max_time * 100) /
> + (double)rte_get_tsc_hz());
Could remove a tab from the last 9 lines for better alignment with printf
> +
> + return TEST_SUCCESS;
> +}
> +
> +static int
> +validation_test(struct active_device *ad,
> + struct test_op_params *op_params)
> +{
> + int iter;
> + uint16_t burst_sz = op_params->burst_sz;
> + const uint16_t num_to_process = op_params->num_to_process;
> + const enum rte_bbdev_op_type op_type = test_vector.op_type;
> + const uint16_t queue_id = ad->queue_ids[0];
> + struct test_buffers *bufs = NULL;
> + struct rte_bbdev_info info;
> + uint64_t total_time, min_time, max_time;
> + const char *op_type_str;
> +
> + total_time = max_time = 0;
> + min_time = UINT64_MAX;
> +
> + TEST_ASSERT_SUCCESS((burst_sz > MAX_BURST),
> + "BURST_SIZE should be <= %u
Re: [dpdk-dev] [PATCH v5 2/7] app/bbdev: add explicit check for counters
On 10/23/20 4:42 PM, Nicolas Chautru wrote:
> Adding explicit check in ut that the stats counters
> have the expect values. Was missing for coverage.
missing from coverage
?
>
> Signed-off-by: Nicolas Chautru
> Acked-by: Aidan Goddard
> Acked-by: Dave Burley
> ---
> app/test-bbdev/test_bbdev_perf.c | 17 +
> 1 file changed, 17 insertions(+)
>
> diff --git a/app/test-bbdev/test_bbdev_perf.c
> b/app/test-bbdev/test_bbdev_perf.c
> index 3554a77..b62848e 100644
> --- a/app/test-bbdev/test_bbdev_perf.c
> +++ b/app/test-bbdev/test_bbdev_perf.c
> @@ -4840,6 +4840,23 @@ typedef int (test_case_function)(struct active_device
> *ad,
> (double)(time_st.deq_max_time * 100) /
> rte_get_tsc_hz());
>
> + struct rte_bbdev_stats stats = {0};
Other calls to get_bbdev_queue_stats do not initialize stats and likely should
> + get_bbdev_queue_stats(ad->dev_id, queue_id, &stats);
Should check the return here.
> + if (op_type != RTE_BBDEV_OP_LDPC_DEC) {
This logic seems off.
Do you mean to check only enc stats with an enc op ?
Similar for dec.
> + TEST_ASSERT_SUCCESS(stats.enqueued_count != num_to_process,
> + "Mismatch in enqueue count %10"PRIu64" %d",
> + stats.enqueued_count, num_to_process);
> + TEST_ASSERT_SUCCESS(stats.dequeued_count != num_to_process,
> + "Mismatch in dequeue count %10"PRIu64" %d",
> + stats.dequeued_count, num_to_process);
> + }
> + TEST_ASSERT_SUCCESS(stats.enqueue_err_count != 0,
> + "Enqueue count Error %10"PRIu64"",
> + stats.enqueue_err_count);
> + TEST_ASSERT_SUCCESS(stats.dequeue_err_count != 0,
> + "Dequeue count Error (%10"PRIu64"",
> + stats.dequeue_err_count);
> +
> return TEST_SUCCESS;
> #endif
> }
Re: [dpdk-dev] [PATCH v5 3/7] app/bbdev: include explicit HARQ preloading
On 10/23/20 4:42 PM, Nicolas Chautru wrote:
> Run preloading explicitly for unit tests. Load each code block
> by reusing existing input op then restore for the actual test.
>
> Signed-off-by: Nicolas Chautru
> Acked-by: Liu Tianjiao
> ---
> app/test-bbdev/main.h| 1 +
> app/test-bbdev/test_bbdev_perf.c | 51
> +---
> 2 files changed, 28 insertions(+), 24 deletions(-)
>
> diff --git a/app/test-bbdev/main.h b/app/test-bbdev/main.h
> index fb3dec8..dc10a50 100644
> --- a/app/test-bbdev/main.h
> +++ b/app/test-bbdev/main.h
> @@ -17,6 +17,7 @@
> #define TEST_SKIPPED1
>
> #define MAX_BURST 512U
> +#define MAX_OPS 1024U
This #define is not consistently used.
ex/ see retrieve_harq_ddr, the old 1024 is still being used.
> #define DEFAULT_BURST 32U
> #define DEFAULT_OPS 64U
> #define DEFAULT_ITER 6U
> diff --git a/app/test-bbdev/test_bbdev_perf.c
> b/app/test-bbdev/test_bbdev_perf.c
> index b62848e..f30cbdb 100644
> --- a/app/test-bbdev/test_bbdev_perf.c
> +++ b/app/test-bbdev/test_bbdev_perf.c
> @@ -2513,20 +2513,20 @@ typedef int (test_case_function)(struct active_device
> *ad,
> bool preload)
> {
> uint16_t j;
> - int ret;
> - uint32_t harq_offset = (uint32_t) queue_id * HARQ_INCR * 1024;
> - struct rte_bbdev_op_data save_hc_in, save_hc_out;
> - struct rte_bbdev_dec_op *ops_deq[MAX_BURST];
> + int deq;
> + uint32_t harq_offset = (uint32_t) queue_id * HARQ_INCR * MAX_OPS;
> + struct rte_bbdev_op_data save_hc_in[MAX_OPS], save_hc_out[MAX_OPS];
> + struct rte_bbdev_dec_op *ops_deq[MAX_OPS];
> uint32_t flags = ops[0]->ldpc_dec.op_flags;
> bool mem_in = flags & RTE_BBDEV_LDPC_INTERNAL_HARQ_MEMORY_IN_ENABLE;
> bool hc_in = flags & RTE_BBDEV_LDPC_HQ_COMBINE_IN_ENABLE;
> bool mem_out = flags & RTE_BBDEV_LDPC_INTERNAL_HARQ_MEMORY_OUT_ENABLE;
> bool hc_out = flags & RTE_BBDEV_LDPC_HQ_COMBINE_OUT_ENABLE;
> bool h_comp = flags & RTE_BBDEV_LDPC_HARQ_6BIT_COMPRESSION;
> - for (j = 0; j < n; ++j) {
> - if ((mem_in || hc_in) && preload) {
> - save_hc_in = ops[j]->ldpc_dec.harq_combined_input;
> - save_hc_out = ops[j]->ldpc_dec.harq_combined_output;
> + if ((mem_in || hc_in) && preload) {
> + for (j = 0; j < n; ++j) {
> + save_hc_in[j] = ops[j]->ldpc_dec.harq_combined_input;
> + save_hc_out[j] = ops[j]->ldpc_dec.harq_combined_output;
> ops[j]->ldpc_dec.op_flags =
> RTE_BBDEV_LDPC_INTERNAL_HARQ_MEMORY_LOOPBACK +
> RTE_BBDEV_LDPC_INTERNAL_HARQ_MEMORY_OUT_ENABLE;
flags are usually handled with bit operators, not arithmetic.
this seems to be a general issue.
> @@ -2536,16 +2536,23 @@ typedef int (test_case_function)(struct active_device
> *ad,
> ops[j]->ldpc_dec.harq_combined_output.offset =
> harq_offset;
> ops[j]->ldpc_dec.harq_combined_input.offset = 0;
> - rte_bbdev_enqueue_ldpc_dec_ops(dev_id, queue_id,
> - &ops[j], 1);
> - ret = 0;
> - while (ret == 0)
> - ret = rte_bbdev_dequeue_ldpc_dec_ops(
> - dev_id, queue_id, &ops_deq[j], 1);
> + harq_offset += HARQ_INCR;
> + }
> + rte_bbdev_enqueue_ldpc_dec_ops(dev_id, queue_id, &ops[0], n);
Add check the return is 'n'
> + deq = 0;
> + while (deq != n)
> + deq += rte_bbdev_dequeue_ldpc_dec_ops(
> + dev_id, queue_id, &ops_deq[deq],
> + n - deq);
Add check the return >= 0
Tom
> + /* Restore the operations */
> + for (j = 0; j < n; ++j) {
> ops[j]->ldpc_dec.op_flags = flags;
> - ops[j]->ldpc_dec.harq_combined_input = save_hc_in;
> - ops[j]->ldpc_dec.harq_combined_output = save_hc_out;
> + ops[j]->ldpc_dec.harq_combined_input = save_hc_in[j];
> + ops[j]->ldpc_dec.harq_combined_output = save_hc_out[j];
> }
> + }
> + harq_offset = (uint32_t) queue_id * HARQ_INCR * MAX_OPS;
> + for (j = 0; j < n; ++j) {
> /* Adjust HARQ offset when we reach external DDR */
> if (mem_in || hc_in)
> ops[j]->ldpc_dec.harq_combined_input.offset
> @@ -3231,11 +3238,9 @@ typedef int (test_case_function)(struct active_device
> *ad,
> mbuf_reset(
> ops_enq[j]->ldpc_dec.harq_combined_output.data);
> }
> - if (extDdr) {
> - bool preload = i == (TEST_REPETITIONS - 1);
>
Re: [dpdk-dev] [PATCH v5 4/7] app/bbdev: define wait for offload
On 10/23/20 4:42 PM, Nicolas Chautru wrote: > Replacing magic number for default wait time for hw > offload. > > Signed-off-by: Nicolas Chautru > Acked-by: Liu Tianjiao > --- > app/test-bbdev/test_bbdev_perf.c | 9 + > 1 file changed, 5 insertions(+), 4 deletions(-) > > diff --git a/app/test-bbdev/test_bbdev_perf.c > b/app/test-bbdev/test_bbdev_perf.c > index f30cbdb..39f06db 100644 > --- a/app/test-bbdev/test_bbdev_perf.c > +++ b/app/test-bbdev/test_bbdev_perf.c > @@ -25,6 +25,7 @@ > > #define MAX_QUEUES RTE_MAX_LCORE > #define TEST_REPETITIONS 1000 > +#define WAIT_OFFLOAD_US 1000 Why wasn't 200 used ? Tom > > #ifdef RTE_LIBRTE_PMD_BBDEV_FPGA_LTE_FEC > #include > @@ -4451,7 +4452,7 @@ typedef int (test_case_function)(struct active_device > *ad, > time_st->enq_acc_total_time += stats.acc_offload_cycles; > > /* give time for device to process ops */ > - rte_delay_us(200); > + rte_delay_us(WAIT_OFFLOAD_US); > > /* Start time meas for dequeue function offload latency */ > deq_start_time = rte_rdtsc_precise(); > @@ -4542,7 +4543,7 @@ typedef int (test_case_function)(struct active_device > *ad, > time_st->enq_acc_total_time += stats.acc_offload_cycles; > > /* give time for device to process ops */ > - rte_delay_us(200); > + rte_delay_us(WAIT_OFFLOAD_US); > > /* Start time meas for dequeue function offload latency */ > deq_start_time = rte_rdtsc_precise(); > @@ -4630,7 +4631,7 @@ typedef int (test_case_function)(struct active_device > *ad, > time_st->enq_acc_total_time += stats.acc_offload_cycles; > > /* give time for device to process ops */ > - rte_delay_us(200); > + rte_delay_us(WAIT_OFFLOAD_US); > > /* Start time meas for dequeue function offload latency */ > deq_start_time = rte_rdtsc_precise(); > @@ -4713,7 +4714,7 @@ typedef int (test_case_function)(struct active_device > *ad, > time_st->enq_acc_total_time += stats.acc_offload_cycles; > > /* give time for device to process ops */ > - rte_delay_us(200); > + rte_delay_us(WAIT_OFFLOAD_US); > > /* Start time meas for dequeue function offload latency */ > deq_start_time = rte_rdtsc_precise();
Re: [dpdk-dev] [PATCH v5 5/7] app/bbdev: skip bler ut when compression is used
On 10/23/20 4:42 PM, Nicolas Chautru wrote: > bler test results are not valid when LLR compression > is used or for loopback scenarios. Skipping these. > > Signed-off-by: Nicolas Chautru > Acked-by: Aidan Goddard > Acked-by: Dave Burley > --- > app/test-bbdev/test_bbdev_perf.c | 6 +- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff --git a/app/test-bbdev/test_bbdev_perf.c > b/app/test-bbdev/test_bbdev_perf.c > index 39f06db..a15ea69 100644 > --- a/app/test-bbdev/test_bbdev_perf.c > +++ b/app/test-bbdev/test_bbdev_perf.c > @@ -3719,7 +3719,11 @@ typedef int (test_case_function)(struct active_device > *ad, > RTE_ALIGN(sizeof(struct thread_params) * num_lcores, > RTE_CACHE_LINE_SIZE)); > > - if (test_vector.op_type == RTE_BBDEV_OP_LDPC_DEC) > + if ((test_vector.op_type == RTE_BBDEV_OP_LDPC_DEC) && > + !check_bit(test_vector.ldpc_dec.op_flags, > + RTE_BBDEV_LDPC_INTERNAL_HARQ_MEMORY_LOOPBACK) > + && !check_bit(test_vector.ldpc_dec.op_flags, > + RTE_BBDEV_LDPC_LLR_COMPRESSION)) > bler_function = bler_pmd_lcore_ldpc_dec; > else > return TEST_SKIPPED; Looks ok. Reviewed-by: Tom Rix
Re: [dpdk-dev] [PATCH v5 6/7] app/bbdev: reduce duration of throughput test
On 10/23/20 4:43 PM, Nicolas Chautru wrote: > Reducing number of repetitions from 1000 to 100 > to save time. Results are accurate enough with > 100 loops. > > Signed-off-by: Nicolas Chautru > Acked-by: Liu Tianjiao > --- > app/test-bbdev/test_bbdev_perf.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/app/test-bbdev/test_bbdev_perf.c > b/app/test-bbdev/test_bbdev_perf.c > index a15ea69..b5dc536 100644 > --- a/app/test-bbdev/test_bbdev_perf.c > +++ b/app/test-bbdev/test_bbdev_perf.c > @@ -24,7 +24,7 @@ > #define GET_SOCKET(socket_id) (((socket_id) == SOCKET_ID_ANY) ? 0 : > (socket_id)) > > #define MAX_QUEUES RTE_MAX_LCORE > -#define TEST_REPETITIONS 1000 > +#define TEST_REPETITIONS 100 > #define WAIT_OFFLOAD_US 1000 > > #ifdef RTE_LIBRTE_PMD_BBDEV_FPGA_LTE_FEC Looks ok Reviewed-by: Tom Rix
Re: [dpdk-dev] [PATCH v5 7/7] app/bbdev: update offload test to dequeue full ring
On 10/23/20 4:43 PM, Nicolas Chautru wrote:
> update offload dequeue to retrieve the full ring to be
> agnostic of implementation.
>
> Signed-off-by: Nicolas Chautru
> Acked-by: Aidan Goddard
> Acked-by: Dave Burley
> ---
> app/test-bbdev/test_bbdev_perf.c | 16
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/app/test-bbdev/test_bbdev_perf.c
> b/app/test-bbdev/test_bbdev_perf.c
> index b5dc536..a6884c5 100644
> --- a/app/test-bbdev/test_bbdev_perf.c
> +++ b/app/test-bbdev/test_bbdev_perf.c
> @@ -4463,8 +4463,8 @@ typedef int (test_case_function)(struct active_device
> *ad,
> /* Dequeue one operation */
This comment and similar need to change, not doing just 1 anymore
> do {
> deq += rte_bbdev_dequeue_dec_ops(dev_id, queue_id,
> - &ops_deq[deq], 1);
> - } while (unlikely(deq != 1));
> + &ops_deq[deq], enq);
> + } while (unlikely(deq == 0));
This check looks wrong, should likely be (deq != enq)
Similar below
Tom
>
> deq_last_time = rte_rdtsc_precise() - deq_start_time;
> time_st->deq_max_time = RTE_MAX(time_st->deq_max_time,
> @@ -4554,8 +4554,8 @@ typedef int (test_case_function)(struct active_device
> *ad,
> /* Dequeue one operation */
> do {
> deq += rte_bbdev_dequeue_ldpc_dec_ops(dev_id, queue_id,
> - &ops_deq[deq], 1);
> - } while (unlikely(deq != 1));
> + &ops_deq[deq], enq);
> + } while (unlikely(deq == 0));
>
> deq_last_time = rte_rdtsc_precise() - deq_start_time;
> time_st->deq_max_time = RTE_MAX(time_st->deq_max_time,
> @@ -4642,8 +4642,8 @@ typedef int (test_case_function)(struct active_device
> *ad,
> /* Dequeue one operation */
> do {
> deq += rte_bbdev_dequeue_enc_ops(dev_id, queue_id,
> - &ops_deq[deq], 1);
> - } while (unlikely(deq != 1));
> + &ops_deq[deq], enq);
> + } while (unlikely(deq == 0));
>
> deq_last_time = rte_rdtsc_precise() - deq_start_time;
> time_st->deq_max_time = RTE_MAX(time_st->deq_max_time,
> @@ -4725,8 +4725,8 @@ typedef int (test_case_function)(struct active_device
> *ad,
> /* Dequeue one operation */
> do {
> deq += rte_bbdev_dequeue_ldpc_enc_ops(dev_id, queue_id,
> - &ops_deq[deq], 1);
> - } while (unlikely(deq != 1));
> + &ops_deq[deq], enq);
> + } while (unlikely(deq == 0));
>
> deq_last_time = rte_rdtsc_precise() - deq_start_time;
> time_st->deq_max_time = RTE_MAX(time_st->deq_max_time,
Re: [dpdk-dev] [PATCH v5 4/7] app/bbdev: define wait for offload
On 10/26/20 9:04 AM, Chautru, Nicolas wrote: >> From: Tom Rix >> Sent: Monday, October 26, 2020 6:33 AM >> To: Chautru, Nicolas ; dev@dpdk.org; >> akhil.go...@nxp.com >> Cc: david.march...@redhat.com >> Subject: Re: [PATCH v5 4/7] app/bbdev: define wait for offload >> >> >> On 10/23/20 4:42 PM, Nicolas Chautru wrote: >>> Replacing magic number for default wait time for hw offload. >>> >>> Signed-off-by: Nicolas Chautru >>> Acked-by: Liu Tianjiao >>> --- >>> app/test-bbdev/test_bbdev_perf.c | 9 + >>> 1 file changed, 5 insertions(+), 4 deletions(-) >>> >>> diff --git a/app/test-bbdev/test_bbdev_perf.c >>> b/app/test-bbdev/test_bbdev_perf.c >>> index f30cbdb..39f06db 100644 >>> --- a/app/test-bbdev/test_bbdev_perf.c >>> +++ b/app/test-bbdev/test_bbdev_perf.c >>> @@ -25,6 +25,7 @@ >>> >>> #define MAX_QUEUES RTE_MAX_LCORE >>> #define TEST_REPETITIONS 1000 >>> +#define WAIT_OFFLOAD_US 1000 >> Why wasn't 200 used ? >> >> Tom > 1ms is a more typical expectation for workload (TTI in numerology 0 for 5GNR > and LTE). That's fine, i was only commenting because it changed. Tom > > >>> #ifdef RTE_LIBRTE_PMD_BBDEV_FPGA_LTE_FEC #include >> >>> @@ -4451,7 +4452,7 @@ typedef int (test_case_function)(struct >> active_device *ad, >>> time_st->enq_acc_total_time += stats.acc_offload_cycles; >>> >>> /* give time for device to process ops */ >>> - rte_delay_us(200); >>> + rte_delay_us(WAIT_OFFLOAD_US); >>> >>> /* Start time meas for dequeue function offload latency */ >>> deq_start_time = rte_rdtsc_precise(); @@ -4542,7 +4543,7 >> @@ typedef >>> int (test_case_function)(struct active_device *ad, >>> time_st->enq_acc_total_time += stats.acc_offload_cycles; >>> >>> /* give time for device to process ops */ >>> - rte_delay_us(200); >>> + rte_delay_us(WAIT_OFFLOAD_US); >>> >>> /* Start time meas for dequeue function offload latency */ >>> deq_start_time = rte_rdtsc_precise(); @@ -4630,7 +4631,7 >> @@ typedef >>> int (test_case_function)(struct active_device *ad, >>> time_st->enq_acc_total_time += stats.acc_offload_cycles; >>> >>> /* give time for device to process ops */ >>> - rte_delay_us(200); >>> + rte_delay_us(WAIT_OFFLOAD_US); >>> >>> /* Start time meas for dequeue function offload latency */ >>> deq_start_time = rte_rdtsc_precise(); @@ -4713,7 +4714,7 >> @@ typedef >>> int (test_case_function)(struct active_device *ad, >>> time_st->enq_acc_total_time += stats.acc_offload_cycles; >>> >>> /* give time for device to process ops */ >>> - rte_delay_us(200); >>> + rte_delay_us(WAIT_OFFLOAD_US); >>> >>> /* Start time meas for dequeue function offload latency */ >>> deq_start_time = rte_rdtsc_precise();
Re: [dpdk-dev] [PATCH v5 7/7] app/bbdev: update offload test to dequeue full ring
On 10/26/20 9:27 AM, Chautru, Nicolas wrote:
>> -Original Message-
>> From: Tom Rix
>> Sent: Monday, October 26, 2020 6:56 AM
>> To: Chautru, Nicolas ; dev@dpdk.org;
>> akhil.go...@nxp.com
>> Cc: david.march...@redhat.com
>> Subject: Re: [PATCH v5 7/7] app/bbdev: update offload test to dequeue full
>> ring
>>
>>
>> On 10/23/20 4:43 PM, Nicolas Chautru wrote:
>>> update offload dequeue to retrieve the full ring to be agnostic of
>>> implementation.
>>>
>>> Signed-off-by: Nicolas Chautru
>>> Acked-by: Aidan Goddard
>>> Acked-by: Dave Burley
>>> ---
>>> app/test-bbdev/test_bbdev_perf.c | 16
>>> 1 file changed, 8 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/app/test-bbdev/test_bbdev_perf.c
>>> b/app/test-bbdev/test_bbdev_perf.c
>>> index b5dc536..a6884c5 100644
>>> --- a/app/test-bbdev/test_bbdev_perf.c
>>> +++ b/app/test-bbdev/test_bbdev_perf.c
>>> @@ -4463,8 +4463,8 @@ typedef int (test_case_function)(struct
>> active_device *ad,
>>> /* Dequeue one operation */
>> This comment and similar need to change, not doing just 1 anymore
> We still just need one operation dequeued to be considered done.
>
>>> do {
>>> deq += rte_bbdev_dequeue_dec_ops(dev_id,
>> queue_id,
>>> - &ops_deq[deq], 1);
>>> - } while (unlikely(deq != 1));
>>> + &ops_deq[deq], enq);
>>> + } while (unlikely(deq == 0));
>> This check looks wrong, should likely be (deq != enq)
>>
>> Similar below
> No that is intentional. Not waiting for everything to be done but purely the
> first dequeue. If not this would be run multiple times.
> The rest of ring is dequeued below.
So is > 1 an error condition or ok?
Maybe add a comment that it is really ok because the call logic is not setup
for 1 but for enq
Tom
>
>> Tom
>>
>>> deq_last_time = rte_rdtsc_precise() - deq_start_time;
>>> time_st->deq_max_time = RTE_MAX(time_st-
>>> deq_max_time, @@ -4554,8
>>> +4554,8 @@ typedef int (test_case_function)(struct active_device *ad,
>>> /* Dequeue one operation */
>>> do {
>>> deq += rte_bbdev_dequeue_ldpc_dec_ops(dev_id,
>> queue_id,
>>> - &ops_deq[deq], 1);
>>> - } while (unlikely(deq != 1));
>>> + &ops_deq[deq], enq);
>>> + } while (unlikely(deq == 0));
>>>
>>> deq_last_time = rte_rdtsc_precise() - deq_start_time;
>>> time_st->deq_max_time = RTE_MAX(time_st-
>>> deq_max_time, @@ -4642,8
>>> +4642,8 @@ typedef int (test_case_function)(struct active_device *ad,
>>> /* Dequeue one operation */
>>> do {
>>> deq += rte_bbdev_dequeue_enc_ops(dev_id,
>> queue_id,
>>> - &ops_deq[deq], 1);
>>> - } while (unlikely(deq != 1));
>>> + &ops_deq[deq], enq);
>>> + } while (unlikely(deq == 0));
>>>
>>> deq_last_time = rte_rdtsc_precise() - deq_start_time;
>>> time_st->deq_max_time = RTE_MAX(time_st-
>>> deq_max_time, @@ -4725,8
>>> +4725,8 @@ typedef int (test_case_function)(struct active_device *ad,
>>> /* Dequeue one operation */
>>> do {
>>> deq += rte_bbdev_dequeue_ldpc_enc_ops(dev_id,
>> queue_id,
>>> - &ops_deq[deq], 1);
>>> - } while (unlikely(deq != 1));
>>> + &ops_deq[deq], enq);
>>> + } while (unlikely(deq == 0));
>>>
>>> deq_last_time = rte_rdtsc_precise() - deq_start_time;
>>> time_st->deq_max_time = RTE_MAX(time_st-
>>> deq_max_time,
Re: [dpdk-dev] [PATCH v5 2/7] app/bbdev: add explicit check for counters
On 10/26/20 9:29 AM, Chautru, Nicolas wrote:
>> -Original Message-
>> From: Tom Rix
>> Sent: Monday, October 26, 2020 6:06 AM
>> To: Chautru, Nicolas ; dev@dpdk.org;
>> akhil.go...@nxp.com
>> Cc: david.march...@redhat.com
>> Subject: Re: [PATCH v5 2/7] app/bbdev: add explicit check for counters
>>
>>
>> On 10/23/20 4:42 PM, Nicolas Chautru wrote:
>>> Adding explicit check in ut that the stats counters have the expect
>>> values. Was missing for coverage.
>> missing from coverage
>>
>> ?
> This was causing code coverage gap.
Add 'code ' to make the context better.
>
>>> Signed-off-by: Nicolas Chautru
>>> Acked-by: Aidan Goddard
>>> Acked-by: Dave Burley
>>> ---
>>> app/test-bbdev/test_bbdev_perf.c | 17 +
>>> 1 file changed, 17 insertions(+)
>>>
>>> diff --git a/app/test-bbdev/test_bbdev_perf.c
>>> b/app/test-bbdev/test_bbdev_perf.c
>>> index 3554a77..b62848e 100644
>>> --- a/app/test-bbdev/test_bbdev_perf.c
>>> +++ b/app/test-bbdev/test_bbdev_perf.c
>>> @@ -4840,6 +4840,23 @@ typedef int (test_case_function)(struct
>> active_device *ad,
>>> (double)(time_st.deq_max_time * 100) /
>>> rte_get_tsc_hz());
>>>
>>> + struct rte_bbdev_stats stats = {0};
>> Other calls to get_bbdev_queue_stats do not initialize stats and likely
>> should
>>> + get_bbdev_queue_stats(ad->dev_id, queue_id, &stats);
>> Should check the return here.
>>> + if (op_type != RTE_BBDEV_OP_LDPC_DEC) {
>> This logic seems off.
>>
>> Do you mean to check only enc stats with an enc op ?
>>
>> Similar for dec.
> No that is intentional. That check would not be relavent for the LDPC_DEC
> tests as this may run more operations for the sake of HARQ
> preloading/retrieve.
ok
>
>>> + TEST_ASSERT_SUCCESS(stats.enqueued_count !=
>> num_to_process,
>>> + "Mismatch in enqueue count %10"PRIu64"
>> %d",
>>> + stats.enqueued_count, num_to_process);
>>> + TEST_ASSERT_SUCCESS(stats.dequeued_count !=
>> num_to_process,
>>> + "Mismatch in dequeue count %10"PRIu64"
>> %d",
>>> + stats.dequeued_count, num_to_process);
>>> + }
>>> + TEST_ASSERT_SUCCESS(stats.enqueue_err_count != 0,
>>> + "Enqueue count Error %10"PRIu64"",
>>> + stats.enqueue_err_count);
>>> + TEST_ASSERT_SUCCESS(stats.dequeue_err_count != 0,
>>> + "Dequeue count Error (%10"PRIu64"",
>>> + stats.dequeue_err_count);
>>> +
>>> return TEST_SUCCESS;
>>> #endif
>>> }
Re: [dpdk-dev] [PATCH v5 3/7] app/bbdev: include explicit HARQ preloading
On 10/26/20 9:50 AM, Chautru, Nicolas wrote:
>> -Original Message-
>> From: Tom Rix
>> Sent: Monday, October 26, 2020 6:32 AM
>> To: Chautru, Nicolas ; dev@dpdk.org;
>> akhil.go...@nxp.com
>> Cc: david.march...@redhat.com
>> Subject: Re: [PATCH v5 3/7] app/bbdev: include explicit HARQ preloading
>>
>>
>> On 10/23/20 4:42 PM, Nicolas Chautru wrote:
>>> Run preloading explicitly for unit tests. Load each code block by
>>> reusing existing input op then restore for the actual test.
>>>
>>> Signed-off-by: Nicolas Chautru
>>> Acked-by: Liu Tianjiao
>>> ---
>>> app/test-bbdev/main.h| 1 +
>>> app/test-bbdev/test_bbdev_perf.c | 51
>>> +---
>>> 2 files changed, 28 insertions(+), 24 deletions(-)
>>>
>>> diff --git a/app/test-bbdev/main.h b/app/test-bbdev/main.h index
>>> fb3dec8..dc10a50 100644
>>> --- a/app/test-bbdev/main.h
>>> +++ b/app/test-bbdev/main.h
>>> @@ -17,6 +17,7 @@
>>> #define TEST_SKIPPED1
>>>
>>> #define MAX_BURST 512U
>>> +#define MAX_OPS 1024U
>> This #define is not consistently used.
>>
>> ex/ see retrieve_harq_ddr, the old 1024 is still being used.
> Thanks I missed it. I will change this now.
>
>>> #define DEFAULT_BURST 32U
>>> #define DEFAULT_OPS 64U
>>> #define DEFAULT_ITER 6U
>>> diff --git a/app/test-bbdev/test_bbdev_perf.c
>>> b/app/test-bbdev/test_bbdev_perf.c
>>> index b62848e..f30cbdb 100644
>>> --- a/app/test-bbdev/test_bbdev_perf.c
>>> +++ b/app/test-bbdev/test_bbdev_perf.c
>>> @@ -2513,20 +2513,20 @@ typedef int (test_case_function)(struct
>> active_device *ad,
>>> bool preload)
>>> {
>>> uint16_t j;
>>> - int ret;
>>> - uint32_t harq_offset = (uint32_t) queue_id * HARQ_INCR * 1024;
>>> - struct rte_bbdev_op_data save_hc_in, save_hc_out;
>>> - struct rte_bbdev_dec_op *ops_deq[MAX_BURST];
>>> + int deq;
>>> + uint32_t harq_offset = (uint32_t) queue_id * HARQ_INCR *
>> MAX_OPS;
>>> + struct rte_bbdev_op_data save_hc_in[MAX_OPS],
>> save_hc_out[MAX_OPS];
>>> + struct rte_bbdev_dec_op *ops_deq[MAX_OPS];
>>> uint32_t flags = ops[0]->ldpc_dec.op_flags;
>>> bool mem_in = flags &
>> RTE_BBDEV_LDPC_INTERNAL_HARQ_MEMORY_IN_ENABLE;
>>> bool hc_in = flags & RTE_BBDEV_LDPC_HQ_COMBINE_IN_ENABLE;
>>> bool mem_out = flags &
>> RTE_BBDEV_LDPC_INTERNAL_HARQ_MEMORY_OUT_ENABLE;
>>> bool hc_out = flags &
>> RTE_BBDEV_LDPC_HQ_COMBINE_OUT_ENABLE;
>>> bool h_comp = flags &
>> RTE_BBDEV_LDPC_HARQ_6BIT_COMPRESSION;
>>> - for (j = 0; j < n; ++j) {
>>> - if ((mem_in || hc_in) && preload) {
>>> - save_hc_in = ops[j]-
>>> ldpc_dec.harq_combined_input;
>>> - save_hc_out = ops[j]-
>>> ldpc_dec.harq_combined_output;
>>> + if ((mem_in || hc_in) && preload) {
>>> + for (j = 0; j < n; ++j) {
>>> + save_hc_in[j] = ops[j]-
>>> ldpc_dec.harq_combined_input;
>>> + save_hc_out[j] = ops[j]-
>>> ldpc_dec.harq_combined_output;
>>> ops[j]->ldpc_dec.op_flags =
>>>
>> RTE_BBDEV_LDPC_INTERNAL_HARQ_MEMORY_LOOPBACK +
>> RTE_BBDEV_LDPC_INTERNAL_HARQ_MEMORY_OUT_ENABLE;
>>
>> flags are usually handled with bit operators, not arithmetic.
>>
>> this seems to be a general issue.
> This is keeping same coding style as rest of file. So keeping as is.
Ugh. Add to a cleanup list.
>
>>> @@ -2536,16 +2536,23 @@ typedef int (test_case_function)(struct
>> active_device *ad,
>>> ops[j]->ldpc_dec.harq_combined_output.offset =
>>> harq_offset;
>>> ops[j]->ldpc_dec.harq_combined_input.offset = 0;
>>> - rte_bbdev_enqueue_ldpc_dec_ops(dev_id, queue_id,
>>> - &ops[j], 1);
>>> - ret = 0;
>>> - while (ret == 0)
>>> - ret = rte_bbdev_dequeue_ldpc_dec_ops(
>>> - dev_id, queue_id, &ops_deq[j], 1);
>>> + harq_offset += HARQ_INCR;
>>> + }
>>> +
Re: [dpdk-dev] [PATCH v5 1/7] app/bbdev: add explicit ut for latency vs validation
On 10/26/20 10:30 AM, Chautru, Nicolas wrote:
>> -Original Message-
>> From: Tom Rix
>> Sent: Monday, October 26, 2020 5:56 AM
>> To: Chautru, Nicolas ; dev@dpdk.org;
>> akhil.go...@nxp.com
>> Cc: david.march...@redhat.com
>> Subject: Re: [PATCH v5 1/7] app/bbdev: add explicit ut for latency vs
>> validation
>>
>>
>> On 10/23/20 4:42 PM, Nicolas Chautru wrote:
>>> Adding explicit different ut when testing for validation or latency
>>> (early termination enabled or not).
>>>
>>> Signed-off-by: Nicolas Chautru
>>> Acked-by: Aidan Goddard
>>> Acked-by: Dave Burley
>>> ---
>>> app/test-bbdev/test_bbdev_perf.c | 92
>>> ++--
>> Should update the copyright.
>>> 1 file changed, 88 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/app/test-bbdev/test_bbdev_perf.c
>>> b/app/test-bbdev/test_bbdev_perf.c
>>> index 6e5535d..3554a77 100644
>>> --- a/app/test-bbdev/test_bbdev_perf.c
>>> +++ b/app/test-bbdev/test_bbdev_perf.c
>>> @@ -3999,12 +3999,14 @@ typedef int (test_case_function)(struct
>> active_device *ad,
>>> return i;
>>> }
>>>
>>> +/* Test case for latency/validation for LDPC Decoder */
>>> static int
>>> latency_test_ldpc_dec(struct rte_mempool *mempool,
>>> struct test_buffers *bufs, struct rte_bbdev_dec_op *ref_op,
>>> int vector_mask, uint16_t dev_id, uint16_t queue_id,
>>> const uint16_t num_to_process, uint16_t burst_sz,
>>> - uint64_t *total_time, uint64_t *min_time, uint64_t
>> *max_time)
>>> + uint64_t *total_time, uint64_t *min_time, uint64_t
>> *max_time,
>>> + bool disable_et)
>>> {
>>> int ret = TEST_SUCCESS;
>>> uint16_t i, j, dequeued;
>>> @@ -4026,7 +4028,7 @@ typedef int (test_case_function)(struct
>> active_device *ad,
>>> "rte_bbdev_dec_op_alloc_bulk() failed");
>>>
>>> /* For latency tests we need to disable early termination */
>>> - if (check_bit(ref_op->ldpc_dec.op_flags,
>>> + if (disable_et && check_bit(ref_op->ldpc_dec.op_flags,
>>>
>> RTE_BBDEV_LDPC_ITERATION_STOP_ENABLE))
>>> ref_op->ldpc_dec.op_flags -=
>>>
>> RTE_BBDEV_LDPC_ITERATION_STOP_ENABLE;
>> Bit clearing is usually done with &= ~()
> This is the coding style for rest of the file hence sticking to it.
>
>>> @@ -4248,7 +4250,7 @@ typedef int (test_case_function)(struct
>> active_device *ad,
>>> TEST_ASSERT_NOT_NULL(op_type_str, "Invalid op type: %u",
>> op_type);
>>> printf("+ --- +\n");
>>> - printf("== test: validation/latency\ndev: %s, burst size: %u, num ops:
>> %u, op type: %s\n",
>>> + printf("== test: latency\ndev: %s, burst size: %u, num ops: %u, op
>>> +type: %s\n",
>>> info.dev_name, burst_sz, num_to_process,
>> op_type_str);
>>> if (op_type == RTE_BBDEV_OP_TURBO_DEC) @@ -4270,7 +4272,83
>> @@
>>> typedef int (test_case_function)(struct active_device *ad,
>>> iter = latency_test_ldpc_dec(op_params->mp, bufs,
>>> op_params->ref_dec_op, op_params-
>>> vector_mask,
>>> ad->dev_id, queue_id, num_to_process,
>>> + burst_sz, &total_time, &min_time,
>> &max_time,
>>> + true);
>>> + else
>>> + iter = latency_test_enc(op_params->mp, bufs,
>>> + op_params->ref_enc_op,
>>> + ad->dev_id, queue_id,
>>> + num_to_process, burst_sz,
>> &total_time,
>>> + &min_time, &max_time);
>> This is a repeat of RTE_BBDEV_OP_TURBO_ENC.
>>
>> Do not need both.
> Fair enough. That is part of previous code but can simplify.
>
>> If the point is to have a else and not fail when the op_type is unknown, then
>>
>> remove the earlier all and comment the else something like
>>
>> else /* RTE_BBDEC_OP_TURBO_ENC */
>>
>>> +
>>> + if (iter <= 0)
>>> + return T
Re: [dpdk-dev] [PATCH v2] doc: add reference to companion configuration tool
On 11/2/20 12:53 PM, Nicolas Chautru wrote:
> Adding reference to pf_bb_config in github to do
> device configuration of the fpga_5gnr, fpga_lte and
> acc100 devices and pmds.
>
> Signed-off-by: Nicolas Chautru
> ---
> doc/guides/bbdevs/acc100.rst| 19 +++
> doc/guides/bbdevs/fpga_5gnr_fec.rst | 19 +++
> doc/guides/bbdevs/fpga_lte_fec.rst | 19 +++
> 3 files changed, 57 insertions(+)
>
> diff --git a/doc/guides/bbdevs/acc100.rst b/doc/guides/bbdevs/acc100.rst
> index 7a23c16..b772854 100644
> --- a/doc/guides/bbdevs/acc100.rst
> +++ b/doc/guides/bbdevs/acc100.rst
> @@ -223,3 +223,22 @@ In addition to the simple LDPC decoder and LDPC encoder
> tests, bbdev also provid
> a range of additional tests under the test_vectors folder, which may be
> useful. The results
> of these tests will depend on the ACC100 5G/4G FEC capabilities which may
> cause some
> testcases to be skipped, but no failure should be reported.
> +
> +
> +Alternate Baseband Device configuration tool
> +
> +
> +On top of the embedded configuration feature supported in test-bbdev using
> "- -init-device"
> +option mentioned above, there is also a tool available to perform that
> device configuration
> +using a companion application.
> +The ``pf_bb_config`` application notably enables then to run bbdev-test from
> the VF
> +and not only limited to the PF as captured above.
> +
> +See for more details: https://github.com/intel/pf-bb-config
> +
> +Specifically for the BBDEV ACC100 PMD, the command below can be used:
> +
> +.. code-block:: console
> +
> + ./pf_bb_config ACC100 -c acc100/acc100_config_vf_5g.cfg
> + ./test-bbdev.py -e="-c 0xff0 -w${VF_PCI_ADDR}" -c validation -n 64 -b 32
> -l 1 -v ./ldpc_dec_default.data
> diff --git a/doc/guides/bbdevs/fpga_5gnr_fec.rst
> b/doc/guides/bbdevs/fpga_5gnr_fec.rst
> index 61c19c3..78c1ce7 100644
> --- a/doc/guides/bbdevs/fpga_5gnr_fec.rst
> +++ b/doc/guides/bbdevs/fpga_5gnr_fec.rst
> @@ -286,3 +286,22 @@ Test Vectors
> In addition to the simple LDPC decoder and LDPC encoder tests, bbdev also
> provides
> a range of additional tests under the test_vectors folder, which may be
> useful. The results
> of these tests will depend on the FPGA 5GNR FEC capabilities.
> +
> +
> +Alternate Baseband Device configuration tool
> +
> +
> +On top of the embedded configuration feature supported in test-bbdev using
> "- -init-device"
> +option, there is also a tool available to perform that device configuration
> using a companion
> +application.
> +The ``pf_bb_config`` application notably enables then to run bbdev-test from
> the VF
> +and not only limited to the PF as captured above.
> +
> +See for more details: https://github.com/intel/pf-bb-config
> +
> +Specifically for the BBDEV FPGA 5GNR FEC PMD, the command below can be used:
> +
> +.. code-block:: console
> +
> + ./pf_bb_config FPGA_5GNR -c fpga_5gnr/fpga_5gnr_config_vf.cfg
> + ./test-bbdev.py -e="-c 0xff0 -w${VF_PCI_ADDR}" -c validation -n 64 -b 32
> -l 1 -v ./ldpc_dec_default.data
> diff --git a/doc/guides/bbdevs/fpga_lte_fec.rst
> b/doc/guides/bbdevs/fpga_lte_fec.rst
> index 9d64e15..a1b3e33 100644
> --- a/doc/guides/bbdevs/fpga_lte_fec.rst
> +++ b/doc/guides/bbdevs/fpga_lte_fec.rst
> @@ -305,3 +305,22 @@ of these tests will depend on the FPGA LTE FEC
> capabilities:
> - ``turbo_enc_c2_k5952_r0_e17868_crc24b.data``
> - ``turbo_enc_c3_k4800_r2_e14412_crc24b.data``
> - ``turbo_enc_c4_k4800_r2_e14412_crc24b.data``
> +
> +
> +Alternate Baseband Device configuration tool
> +
> +
> +On top of the embedded configuration feature supported in test-bbdev using
> "- -init-device"
> +option, there is also a tool available to perform that device configuration
> using a companion
> +application.
> +The ``pf_bb_config`` application notably enables then to run bbdev-test from
> the VF
> +and not only limited to the PF as captured above.
> +
> +See for more details: https://github.com/intel/pf-bb-config
> +
> +Specifically for the BBDEV FPGA LTE FEC PMD, the command below can be used:
> +
> +.. code-block:: console
> +
> + ./pf_bb_config FPGA_lte -c fpga_lte/fpga_lte_config_vf.cfg
>From inspection, pf_bb_config does not care about the case of FPGA_lte
However for documentation, it is best if these examples are consistent.
So this should be
./pf_bb_config FPGA_LTE ...
Tom
> + ./test-bbdev.py -e="-c 0xff0 -w${VF_PCI_ADDR}" -c validation -n 64 -b 32
> -l 1 -v ./turbo_dec_default.data
Re: [dpdk-dev] [PATCH v2] doc: add reference to companion configuration tool
On 11/3/20 7:58 AM, Chautru, Nicolas wrote:
>
>> -Original Message-
>> From: Tom Rix
>> Sent: Tuesday, November 3, 2020 7:07 AM
>> To: Chautru, Nicolas ; dev@dpdk.org;
>> akhil.go...@nxp.com; tho...@monjalon.net
>> Cc: Mcnamara, John ;
>> david.march...@redhat.com; Richardson, Bruce
>> ; Liu, Tianjiao
>> Subject: Re: [PATCH v2] doc: add reference to companion configuration tool
>>
>>
>> On 11/2/20 12:53 PM, Nicolas Chautru wrote:
>>> Adding reference to pf_bb_config in github to do device configuration
>>> of the fpga_5gnr, fpga_lte and
>>> acc100 devices and pmds.
>>>
>>> Signed-off-by: Nicolas Chautru
>>> ---
>>> doc/guides/bbdevs/acc100.rst| 19 +++
>>> doc/guides/bbdevs/fpga_5gnr_fec.rst | 19 +++
>>> doc/guides/bbdevs/fpga_lte_fec.rst | 19 +++
>>> 3 files changed, 57 insertions(+)
>>>
>>> diff --git a/doc/guides/bbdevs/acc100.rst
>>> b/doc/guides/bbdevs/acc100.rst index 7a23c16..b772854 100644
>>> --- a/doc/guides/bbdevs/acc100.rst
>>> +++ b/doc/guides/bbdevs/acc100.rst
>>> @@ -223,3 +223,22 @@ In addition to the simple LDPC decoder and LDPC
>>> encoder tests, bbdev also provid a range of additional tests under
>>> the test_vectors folder, which may be useful. The results of these
>>> tests will depend on the ACC100 5G/4G FEC capabilities which may cause
>> some testcases to be skipped, but no failure should be reported.
>>> +
>>> +
>>> +Alternate Baseband Device configuration tool
>>> +
>>> +
>>> +On top of the embedded configuration feature supported in test-bbdev
>> using "- -init-device"
>>> +option mentioned above, there is also a tool available to perform
>>> +that device configuration using a companion application.
>>> +The ``pf_bb_config`` application notably enables then to run
>>> +bbdev-test from the VF and not only limited to the PF as captured above.
>>> +
>>> +See for more details: https://github.com/intel/pf-bb-config
>>> +
>>> +Specifically for the BBDEV ACC100 PMD, the command below can be
>> used:
>>> +
>>> +.. code-block:: console
>>> +
>>> + ./pf_bb_config ACC100 -c acc100/acc100_config_vf_5g.cfg
>>> + ./test-bbdev.py -e="-c 0xff0 -w${VF_PCI_ADDR}" -c validation -n 64
>>> + -b 32 -l 1 -v ./ldpc_dec_default.data
>>> diff --git a/doc/guides/bbdevs/fpga_5gnr_fec.rst
>>> b/doc/guides/bbdevs/fpga_5gnr_fec.rst
>>> index 61c19c3..78c1ce7 100644
>>> --- a/doc/guides/bbdevs/fpga_5gnr_fec.rst
>>> +++ b/doc/guides/bbdevs/fpga_5gnr_fec.rst
>>> @@ -286,3 +286,22 @@ Test Vectors
>>> In addition to the simple LDPC decoder and LDPC encoder tests, bbdev
>>> also provides a range of additional tests under the test_vectors
>>> folder, which may be useful. The results of these tests will depend on the
>> FPGA 5GNR FEC capabilities.
>>> +
>>> +
>>> +Alternate Baseband Device configuration tool
>>> +
>>> +
>>> +On top of the embedded configuration feature supported in test-bbdev
>> using "- -init-device"
>>> +option, there is also a tool available to perform that device
>>> +configuration using a companion application.
>>> +The ``pf_bb_config`` application notably enables then to run
>>> +bbdev-test from the VF and not only limited to the PF as captured above.
>>> +
>>> +See for more details: https://github.com/intel/pf-bb-config
>>> +
>>> +Specifically for the BBDEV FPGA 5GNR FEC PMD, the command below can
>> be used:
>>> +
>>> +.. code-block:: console
>>> +
>>> +
>>> + ./test-bbdev.py -e="-c 0xff0 -w${VF_PCI_ADDR}" -c validation -n 64
>>> + -b 32 -l 1 -v ./ldpc_dec_default.data
>>> diff --git a/doc/guides/bbdevs/fpga_lte_fec.rst
>>> b/doc/guides/bbdevs/fpga_lte_fec.rst
>>> index 9d64e15..a1b3e33 100644
>>> --- a/doc/guides/bbdevs/fpga_lte_fec.rst
>>> +++ b/doc/guides/bbdevs/fpga_lte_fec.rst
>>> @@ -305,3 +305,22 @@ of these tests will depend on the FPGA LTE FEC
>> capabilities:
>>> - ``turbo_enc_c2_k5952_r0_e17868_crc24b.data``
>>> - ``turbo_enc_c3_k4800_r2_e14412_crc24b.data``
>>> - ``turbo_enc_c4_k4800_r2_e14412_crc24b.data``
>>> +
>>> +
>>> +Alternate Baseband
Re: [dpdk-dev] [PATCH v3] doc: add reference to bbdev companion configuration tool
On 11/3/20 11:39 AM, Nicolas Chautru wrote: > v3: casing typo correction > v2: typo corrections > Adding reference to companion tool to perform PF device configuration of HW > bbdev devices : pf_bb_config This topic was previously discussed in > https://patches.dpdk.org/patch/74270/ > and it was preferred for the tool to be be upstreamed outside of DPDK in > github. > This dependency notably allows to run the bbdev workload from VF. > Kept this as a single commit affecting the 3 distinct docs. > > > Nicolas Chautru (1): > doc: add reference to companion configuration tool > > doc/guides/bbdevs/acc100.rst| 19 +++ > doc/guides/bbdevs/fpga_5gnr_fec.rst | 19 +++ > doc/guides/bbdevs/fpga_lte_fec.rst | 19 +++ > 3 files changed, 57 insertions(+) > Looks good, thanks. Reviewed-by: Tom Rix
Re: [dpdk-dev] [PATCH] baseband/acc100: remove logically dead code
On 10/19/20 2:09 PM, Nicolas Chautru wrote: > Coverity reported dead code for a few error > checks which are indeed not reachable. > > Coverity issue: 363451, 363454, 363455 > > Signed-off-by: Nicolas Chautru This change looks fine. Should remove the 'Coverity issue: ... ' from the log. Reviewed-by: Tom Rix > --- > drivers/baseband/acc100/rte_acc100_pmd.c | 9 - > 1 file changed, 9 deletions(-) > > diff --git a/drivers/baseband/acc100/rte_acc100_pmd.c > b/drivers/baseband/acc100/rte_acc100_pmd.c > index 47ddbae..5e663a6 100644 > --- a/drivers/baseband/acc100/rte_acc100_pmd.c > +++ b/drivers/baseband/acc100/rte_acc100_pmd.c > @@ -2519,9 +2519,6 @@ > r++; > } > > - if (unlikely(desc == NULL)) > - return current_enqueued_cbs; > - > #ifdef RTE_LIBRTE_BBDEV_DEBUG > if (check_mbuf_total_left(mbuf_total_left) != 0) > return -EINVAL; > @@ -3076,9 +3073,6 @@ > r++; > } > > - if (unlikely(desc == NULL)) > - return current_enqueued_cbs; > - > #ifdef RTE_LIBRTE_BBDEV_DEBUG > if (check_mbuf_total_left(mbuf_total_left) != 0) > return -EINVAL; > @@ -3181,9 +3175,6 @@ > r++; > } > > - if (unlikely(desc == NULL)) > - return current_enqueued_cbs; > - > #ifdef RTE_LIBRTE_BBDEV_DEBUG > if (check_mbuf_total_left(mbuf_total_left) != 0) > return -EINVAL;
Re: [dpdk-dev] [PATCH v9 01/10] drivers/baseband: add PMD for ACC100
On 9/28/20 5:29 PM, Nicolas Chautru wrote: > Add stubs for the ACC100 PMD > > Signed-off-by: Nicolas Chautru > Acked-by: Liu Tianjiao > --- > doc/guides/bbdevs/acc100.rst | 233 > + > doc/guides/bbdevs/features/acc100.ini | 14 ++ > doc/guides/bbdevs/index.rst| 1 + > drivers/baseband/acc100/meson.build| 6 + > drivers/baseband/acc100/rte_acc100_pmd.c | 175 > drivers/baseband/acc100/rte_acc100_pmd.h | 37 > .../acc100/rte_pmd_bbdev_acc100_version.map| 3 + > drivers/baseband/meson.build | 2 +- > 8 files changed, 470 insertions(+), 1 deletion(-) > create mode 100644 doc/guides/bbdevs/acc100.rst > create mode 100644 doc/guides/bbdevs/features/acc100.ini > create mode 100644 drivers/baseband/acc100/meson.build > create mode 100644 drivers/baseband/acc100/rte_acc100_pmd.c > create mode 100644 drivers/baseband/acc100/rte_acc100_pmd.h > create mode 100644 drivers/baseband/acc100/rte_pmd_bbdev_acc100_version.map > > diff --git a/doc/guides/bbdevs/acc100.rst b/doc/guides/bbdevs/acc100.rst > new file mode 100644 > index 000..f87ee09 > --- /dev/null > +++ b/doc/guides/bbdevs/acc100.rst > @@ -0,0 +1,233 @@ > +.. SPDX-License-Identifier: BSD-3-Clause > +Copyright(c) 2020 Intel Corporation > + > +Intel(R) ACC100 5G/4G FEC Poll Mode Driver > +== > + > +The BBDEV ACC100 5G/4G FEC poll mode driver (PMD) supports an > +implementation of a VRAN FEC wireless acceleration function. > +This device is also known as Mount Bryce. If this is code name or general chip name it should be removed. > + > +Features > + > + > +ACC100 5G/4G FEC PMD supports the following features: > + > +- LDPC Encode in the DL (5GNR) > +- LDPC Decode in the UL (5GNR) > +- Turbo Encode in the DL (4G) > +- Turbo Decode in the UL (4G) > +- 16 VFs per PF (physical device) > +- Maximum of 128 queues per VF > +- PCIe Gen-3 x16 Interface > +- MSI > +- SR-IOV > + > +ACC100 5G/4G FEC PMD supports the following BBDEV capabilities: > + > +* For the LDPC encode operation: > + - ``RTE_BBDEV_LDPC_CRC_24B_ATTACH`` : set to attach CRC24B to CB(s) > + - ``RTE_BBDEV_LDPC_RATE_MATCH`` : if set then do not do Rate Match bypass > + - ``RTE_BBDEV_LDPC_INTERLEAVER_BYPASS`` : if set then bypass interleaver > + > +* For the LDPC decode operation: > + - ``RTE_BBDEV_LDPC_CRC_TYPE_24B_CHECK`` : check CRC24B from CB(s) > + - ``RTE_BBDEV_LDPC_ITERATION_STOP_ENABLE`` : disable early termination > + - ``RTE_BBDEV_LDPC_CRC_TYPE_24B_DROP`` : drops CRC24B bits appended > while decoding > + - ``RTE_BBDEV_LDPC_HQ_COMBINE_IN_ENABLE`` : provides an input for HARQ > combining > + - ``RTE_BBDEV_LDPC_HQ_COMBINE_OUT_ENABLE`` : provides an input for HARQ > combining > + - ``RTE_BBDEV_LDPC_INTERNAL_HARQ_MEMORY_IN_ENABLE`` : HARQ memory input > is internal > + - ``RTE_BBDEV_LDPC_INTERNAL_HARQ_MEMORY_OUT_ENABLE`` : HARQ memory > output is internal > + - ``RTE_BBDEV_LDPC_INTERNAL_HARQ_MEMORY_LOOPBACK`` : loopback data > to/from HARQ memory > + - ``RTE_BBDEV_LDPC_INTERNAL_HARQ_MEMORY_FILLERS`` : HARQ memory includes > the fillers bits > + - ``RTE_BBDEV_LDPC_DEC_SCATTER_GATHER`` : supports scatter-gather for > input/output data > + - ``RTE_BBDEV_LDPC_HARQ_6BIT_COMPRESSION`` : supports compression of the > HARQ input/output > + - ``RTE_BBDEV_LDPC_LLR_COMPRESSION`` : supports LLR input compression > + > +* For the turbo encode operation: > + - ``RTE_BBDEV_TURBO_CRC_24B_ATTACH`` : set to attach CRC24B to CB(s) > + - ``RTE_BBDEV_TURBO_RATE_MATCH`` : if set then do not do Rate Match > bypass > + - ``RTE_BBDEV_TURBO_ENC_INTERRUPTS`` : set for encoder dequeue interrupts > + - ``RTE_BBDEV_TURBO_RV_INDEX_BYPASS`` : set to bypass RV index > + - ``RTE_BBDEV_TURBO_ENC_SCATTER_GATHER`` : supports scatter-gather for > input/output data > + > +* For the turbo decode operation: > + - ``RTE_BBDEV_TURBO_CRC_TYPE_24B`` : check CRC24B from CB(s) > + - ``RTE_BBDEV_TURBO_SUBBLOCK_DEINTERLEAVE`` : perform subblock > de-interleave > + - ``RTE_BBDEV_TURBO_DEC_INTERRUPTS`` : set for decoder dequeue interrupts > + - ``RTE_BBDEV_TURBO_NEG_LLR_1_BIT_IN`` : set if negative LLR encoder i/p > is supported > + - ``RTE_BBDEV_TURBO_POS_LLR_1_BIT_IN`` : set if positive LLR encoder i/p > is supported > + - ``RTE_BBDEV_TURBO_DEC_TB_CRC_24B_KEEP`` : keep CRC24B bits appended > while decoding > + - ``RTE_BBDEV_TURBO_EARLY_TERMINATION`` : set early 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 > + > +Installation > + > + > +Section 3 of the DPDK manual provides instuctions on installing and > compiling DPDK. The > +default set of
Re: [dpdk-dev] [PATCH v9 02/10] baseband/acc100: add register definition file
On 9/28/20 5:29 PM, Nicolas Chautru wrote:
> Add in the list of registers for the device and related
> HW specs definitions.
>
> Signed-off-by: Nicolas Chautru
> Reviewed-by: Rosen Xu
> Acked-by: Liu Tianjiao
> ---
> drivers/baseband/acc100/acc100_pf_enum.h | 1068
> ++
> drivers/baseband/acc100/acc100_vf_enum.h | 73 ++
> drivers/baseband/acc100/rte_acc100_pmd.h | 490 ++
> 3 files changed, 1631 insertions(+)
> create mode 100644 drivers/baseband/acc100/acc100_pf_enum.h
> create mode 100644 drivers/baseband/acc100/acc100_vf_enum.h
>
> diff --git a/drivers/baseband/acc100/acc100_pf_enum.h
> b/drivers/baseband/acc100/acc100_pf_enum.h
> new file mode 100644
> index 000..a1ee416
> --- /dev/null
> +++ b/drivers/baseband/acc100/acc100_pf_enum.h
> @@ -0,0 +1,1068 @@
> +/* SPDX-License-Identifier: BSD-3-Clause
> + * Copyright(c) 2017 Intel Corporation
> + */
> +
> +#ifndef ACC100_PF_ENUM_H
> +#define ACC100_PF_ENUM_H
> +
> +/*
> + * ACC100 Register mapping on PF BAR0
> + * This is automatically generated from RDL, format may change with new RDL
> + * Release.
> + * Variable names are as is
> + */
> +enum {
> + HWPfQmgrEgressQueuesTemplate = 0x0007FE00,
> + HWPfQmgrIngressAq = 0x0008,
> + HWPfQmgrArbQAvail = 0x00A00010,
> + HWPfQmgrArbQBlock = 0x00A00014,
> + HWPfQmgrAqueueDropNotifEn = 0x00A00024,
> + HWPfQmgrAqueueDisableNotifEn = 0x00A00028,
> + HWPfQmgrSoftReset = 0x00A00038,
> + HWPfQmgrInitStatus= 0x00A0003C,
> + HWPfQmgrAramWatchdogCount = 0x00A00040,
> + HWPfQmgrAramWatchdogCounterEn = 0x00A00044,
> + HWPfQmgrAxiWatchdogCount = 0x00A00048,
> + HWPfQmgrAxiWatchdogCounterEn = 0x00A0004C,
> + HWPfQmgrProcessWatchdogCount = 0x00A00050,
> + HWPfQmgrProcessWatchdogCounterEn = 0x00A00054,
> + HWPfQmgrProcessUl4GWatchdogCounter= 0x00A00058,
> + HWPfQmgrProcessDl4GWatchdogCounter= 0x00A0005C,
> + HWPfQmgrProcessUl5GWatchdogCounter= 0x00A00060,
> + HWPfQmgrProcessDl5GWatchdogCounter= 0x00A00064,
> + HWPfQmgrProcessMldWatchdogCounter = 0x00A00068,
> + HWPfQmgrMsiOverflowUpperVf= 0x00A00070,
> + HWPfQmgrMsiOverflowLowerVf= 0x00A00074,
> + HWPfQmgrMsiWatchdogOverflow = 0x00A00078,
> + HWPfQmgrMsiOverflowEnable = 0x00A0007C,
> + HWPfQmgrDebugAqPointerMemGrp = 0x00A00100,
> + HWPfQmgrDebugOutputArbQFifoGrp= 0x00A00140,
> + HWPfQmgrDebugMsiFifoGrp = 0x00A00180,
> + HWPfQmgrDebugAxiWdTimeoutMsiFifo = 0x00A001C0,
> + HWPfQmgrDebugProcessWdTimeoutMsiFifo = 0x00A001C4,
> + HWPfQmgrDepthLog2Grp = 0x00A00200,
> + HWPfQmgrTholdGrp = 0x00A00300,
> + HWPfQmgrGrpTmplateReg0Indx= 0x00A00600,
> + HWPfQmgrGrpTmplateReg1Indx= 0x00A00680,
> + HWPfQmgrGrpTmplateReg2indx= 0x00A00700,
> + HWPfQmgrGrpTmplateReg3Indx= 0x00A00780,
> + HWPfQmgrGrpTmplateReg4Indx= 0x00A00800,
> + HWPfQmgrVfBaseAddr= 0x00A01000,
> + HWPfQmgrUl4GWeightRrVf= 0x00A02000,
> + HWPfQmgrDl4GWeightRrVf= 0x00A02100,
> + HWPfQmgrUl5GWeightRrVf= 0x00A02200,
> + HWPfQmgrDl5GWeightRrVf= 0x00A02300,
> + HWPfQmgrMldWeightRrVf = 0x00A02400,
> + HWPfQmgrArbQDepthGrp = 0x00A02F00,
> + HWPfQmgrGrpFunction0 = 0x00A02F40,
> + HWPfQmgrGrpFunction1 = 0x00A02F44,
> + HWPfQmgrGrpPriority = 0x00A02F48,
> + HWPfQmgrWeightSync= 0x00A03000,
> + HWPfQmgrAqEnableVf= 0x00A1,
> + HWPfQmgrAqResetVf = 0x00A2,
> + HWPfQmgrRingSizeVf= 0x00A20004,
> + HWPfQmgrGrpDepthLog20Vf = 0x00A20008,
> + HWPfQmgrGrpDepthLog21Vf = 0x00A2000C,
> + HWPfQmgrGrpFunction0Vf= 0x00A20010,
> + HWPfQmgrGrpFunction1Vf= 0x00A20014,
> + HWPfDmaConfig0Reg = 0x00B8,
> + HWPfDmaConfig1Reg = 0x00B80004,
> + HWPfDmaQmgrAddrReg= 0x00B80008,
> + HWPfDmaSoftResetReg = 0x00B8000C,
> + HWPfDmaAxcacheReg = 0x00B80010,
> + HWPfDmaVersionReg = 0x00B80014,
> + HWPfDmaFrameThreshold = 0x00B80018,
> + HWPfDmaTimestampLo= 0x00B8001C,
> + HWPfDmaTimestampHi= 0x00B80020,
> + HWPfDmaAxiStatus
Re: [dpdk-dev] [PATCH v9 03/10] baseband/acc100: add info get function
On 9/28/20 5:29 PM, Nicolas Chautru wrote:
> Add in the "info_get" function to the driver, to allow us to query the
> device.
> No processing capability are available yet.
> Linking bbdev-test to support the PMD with null capability.
>
> Signed-off-by: Nicolas Chautru
> Acked-by: Liu Tianjiao
> ---
> app/test-bbdev/meson.build | 3 +
> drivers/baseband/acc100/rte_acc100_cfg.h | 96 +
> drivers/baseband/acc100/rte_acc100_pmd.c | 225
> +++
> drivers/baseband/acc100/rte_acc100_pmd.h | 3 +
> 4 files changed, 327 insertions(+)
> create mode 100644 drivers/baseband/acc100/rte_acc100_cfg.h
>
> diff --git a/app/test-bbdev/meson.build b/app/test-bbdev/meson.build
> index 18ab6a8..fbd8ae3 100644
> --- a/app/test-bbdev/meson.build
> +++ b/app/test-bbdev/meson.build
> @@ -12,3 +12,6 @@ endif
> if dpdk_conf.has('RTE_LIBRTE_PMD_BBDEV_FPGA_5GNR_FEC')
> deps += ['pmd_bbdev_fpga_5gnr_fec']
> endif
> +if dpdk_conf.has('RTE_LIBRTE_PMD_BBDEV_ACC100')
> + deps += ['pmd_bbdev_acc100']
> +endif
> \ No newline at end of file
> diff --git a/drivers/baseband/acc100/rte_acc100_cfg.h
> b/drivers/baseband/acc100/rte_acc100_cfg.h
> new file mode 100644
> index 000..73bbe36
> --- /dev/null
> +++ b/drivers/baseband/acc100/rte_acc100_cfg.h
> @@ -0,0 +1,96 @@
> +/* SPDX-License-Identifier: BSD-3-Clause
> + * Copyright(c) 2020 Intel Corporation
> + */
> +
> +#ifndef _RTE_ACC100_CFG_H_
> +#define _RTE_ACC100_CFG_H_
> +
> +/**
> + * @file rte_acc100_cfg.h
> + *
> + * Functions for configuring ACC100 HW, exposed directly to applications.
> + * Configuration related to encoding/decoding is done through the
> + * librte_bbdev library.
> + *
> + * @warning
> + * @b EXPERIMENTAL: this API may change without prior notice
When will this experimental tag be removed ?
> + */
> +
> +#include
> +#include
> +
> +#ifdef __cplusplus
> +extern "C" {
> +#endif
> +/**< Number of Virtual Functions ACC100 supports */
> +#define RTE_ACC100_NUM_VFS 16
This is already defined with ACC100_NUM_VFS
> +
> +/**
> + * Definition of Queue Topology for ACC100 Configuration
> + * Some level of details is abstracted out to expose a clean interface
> + * given that comprehensive flexibility is not required
> + */
> +struct rte_q_topology_t {
> + /** Number of QGroups in incremental order of priority */
> + uint16_t num_qgroups;
> + /**
> + * All QGroups have the same number of AQs here.
> + * Note : Could be made a 16-array if more flexibility is really
> + * required
> + */
> + uint16_t num_aqs_per_groups;
> + /**
> + * Depth of the AQs is the same of all QGroups here. Log2 Enum : 2^N
> + * Note : Could be made a 16-array if more flexibility is really
> + * required
> + */
> + uint16_t aq_depth_log2;
> + /**
> + * Index of the first Queue Group Index - assuming contiguity
> + * Initialized as -1
> + */
> + int8_t first_qgroup_index;
> +};
> +
> +/**
> + * Definition of Arbitration related parameters for ACC100 Configuration
> + */
> +struct rte_arbitration_t {
> + /** Default Weight for VF Fairness Arbitration */
> + uint16_t round_robin_weight;
> + uint32_t gbr_threshold1; /**< Guaranteed Bitrate Threshold 1 */
> + uint32_t gbr_threshold2; /**< Guaranteed Bitrate Threshold 2 */
> +};
> +
> +/**
> + * Structure to pass ACC100 configuration.
> + * Note: all VF Bundles will have the same configuration.
> + */
> +struct acc100_conf {
> + bool pf_mode_en; /**< 1 if PF is used for dataplane, 0 for VFs */
> + /** 1 if input '1' bit is represented by a positive LLR value, 0 if '1'
> + * bit is represented by a negative value.
> + */
> + bool input_pos_llr_1_bit;
> + /** 1 if output '1' bit is represented by a positive value, 0 if '1'
> + * bit is represented by a negative value.
> + */
> + bool output_pos_llr_1_bit;
> + uint16_t num_vf_bundles; /**< Number of VF bundles to setup */
> + /** Queue topology for each operation type */
> + struct rte_q_topology_t q_ul_4g;
> + struct rte_q_topology_t q_dl_4g;
> + struct rte_q_topology_t q_ul_5g;
> + struct rte_q_topology_t q_dl_5g;
> + /** Arbitration configuration for each operation type */
> + struct rte_arbitration_t arb_ul_4g[RTE_ACC100_NUM_VFS];
> + struct rte_arbitration_t arb_dl_4g[RTE_ACC100_NUM_VFS];
> + struct rte_arbitration_t arb_ul_5g[RTE_ACC100_NUM_VFS];
> + struct rte_arbitration_t arb_dl_5g[RTE_ACC100_NUM_VFS];
> +};
> +
> +#ifdef __cplusplus
> +}
> +#endif
> +
> +#endif /* _RTE_ACC100_CFG_H_ */
> diff --git a/drivers/baseband/acc100/rte_acc100_pmd.c
> b/drivers/baseband/acc100/rte_acc100_pmd.c
> index 1b4cd13..7807a30 100644
> --- a/drivers/baseband/acc100/rte_acc100_pmd.c
> +++ b/drivers/baseband/acc100/rte_acc100_pmd.c
> @@ -26,6 +26,184 @@
> RTE_LOG_REGISTER(acc100_logtype, pmd.bb.acc100, NOTICE);
> #endif
>
> +/* Read a register of a ACC100 d
Re: [dpdk-dev] [PATCH v9 04/10] baseband/acc100: add queue configuration
On 9/28/20 5:29 PM, Nicolas Chautru wrote:
> Adding function to create and configure queues for
> the device. Still no capability.
>
> Signed-off-by: Nicolas Chautru
> Reviewed-by: Rosen Xu
> Acked-by: Liu Tianjiao
> ---
> drivers/baseband/acc100/rte_acc100_pmd.c | 420
> ++-
> drivers/baseband/acc100/rte_acc100_pmd.h | 45
> 2 files changed, 464 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/baseband/acc100/rte_acc100_pmd.c
> b/drivers/baseband/acc100/rte_acc100_pmd.c
> index 7807a30..7a21c57 100644
> --- a/drivers/baseband/acc100/rte_acc100_pmd.c
> +++ b/drivers/baseband/acc100/rte_acc100_pmd.c
> @@ -26,6 +26,22 @@
> RTE_LOG_REGISTER(acc100_logtype, pmd.bb.acc100, NOTICE);
> #endif
>
> +/* Write to MMIO register address */
> +static inline void
> +mmio_write(void *addr, uint32_t value)
> +{
> + *((volatile uint32_t *)(addr)) = rte_cpu_to_le_32(value);
> +}
> +
> +/* Write a register of a ACC100 device */
> +static inline void
> +acc100_reg_write(struct acc100_device *d, uint32_t offset, uint32_t payload)
> +{
> + void *reg_addr = RTE_PTR_ADD(d->mmio_base, offset);
> + mmio_write(reg_addr, payload);
> + usleep(1000);
rte_acc100_pmd.h defines LONG_WAIT , could this #define be used instead ?
> +}
> +
> /* Read a register of a ACC100 device */
> static inline uint32_t
> acc100_reg_read(struct acc100_device *d, uint32_t offset)
> @@ -36,6 +52,22 @@
> return rte_le_to_cpu_32(ret);
> }
>
> +/* Basic Implementation of Log2 for exact 2^N */
> +static inline uint32_t
> +log2_basic(uint32_t value)
mirrors the function rte_bsf32
> +{
> + return (value == 0) ? 0 : __builtin_ctz(value);
> +}
> +
> +/* Calculate memory alignment offset assuming alignment is 2^N */
> +static inline uint32_t
> +calc_mem_alignment_offset(void *unaligned_virt_mem, uint32_t alignment)
> +{
> + rte_iova_t unaligned_phy_mem = rte_malloc_virt2iova(unaligned_virt_mem);
> + return (uint32_t)(alignment -
> + (unaligned_phy_mem & (alignment-1)));
> +}
> +
> /* Calculate the offset of the enqueue register */
> static inline uint32_t
> queue_offset(bool pf_device, uint8_t vf_id, uint8_t qgrp_id, uint16_t aq_id)
> @@ -204,10 +236,393 @@
> acc100_conf->q_dl_5g.aq_depth_log2);
> }
>
> +static void
> +free_base_addresses(void **base_addrs, int size)
> +{
> + int i;
> + for (i = 0; i < size; i++)
> + rte_free(base_addrs[i]);
> +}
> +
> +static inline uint32_t
> +get_desc_len(void)
> +{
> + return sizeof(union acc100_dma_desc);
> +}
> +
> +/* Allocate the 2 * 64MB block for the sw rings */
> +static int
> +alloc_2x64mb_sw_rings_mem(struct rte_bbdev *dev, struct acc100_device *d,
> + int socket)
see earlier comment about name of function.
> +{
> + uint32_t sw_ring_size = ACC100_SIZE_64MBYTE;
> + d->sw_rings_base = rte_zmalloc_socket(dev->device->driver->name,
> + 2 * sw_ring_size, RTE_CACHE_LINE_SIZE, socket);
> + if (d->sw_rings_base == NULL) {
> + rte_bbdev_log(ERR, "Failed to allocate memory for %s:%u",
> + dev->device->driver->name,
> + dev->data->dev_id);
> + return -ENOMEM;
> + }
> + memset(d->sw_rings_base, 0, ACC100_SIZE_64MBYTE);
> + uint32_t next_64mb_align_offset = calc_mem_alignment_offset(
> + d->sw_rings_base, ACC100_SIZE_64MBYTE);
> + d->sw_rings = RTE_PTR_ADD(d->sw_rings_base, next_64mb_align_offset);
> + d->sw_rings_phys = rte_malloc_virt2iova(d->sw_rings_base) +
> + next_64mb_align_offset;
> + d->sw_ring_size = MAX_QUEUE_DEPTH * get_desc_len();
> + d->sw_ring_max_depth = d->sw_ring_size / get_desc_len();
> +
> + return 0;
> +}
> +
> +/* Attempt to allocate minimised memory space for sw rings */
> +static void
> +alloc_sw_rings_min_mem(struct rte_bbdev *dev, struct acc100_device *d,
> + uint16_t num_queues, int socket)
> +{
> + rte_iova_t sw_rings_base_phy, next_64mb_align_addr_phy;
> + uint32_t next_64mb_align_offset;
> + rte_iova_t sw_ring_phys_end_addr;
> + void *base_addrs[SW_RING_MEM_ALLOC_ATTEMPTS];
> + void *sw_rings_base;
> + int i = 0;
> + uint32_t q_sw_ring_size = MAX_QUEUE_DEPTH * get_desc_len();
> + uint32_t dev_sw_ring_size = q_sw_ring_size * num_queues;
> +
> + /* Find an aligned block of memory to store sw rings */
> + while (i < SW_RING_MEM_ALLOC_ATTEMPTS) {
> + /*
> + * sw_ring allocated memory is guaranteed to be aligned to
> + * q_sw_ring_size at the condition that the requested size is
> + * less than the page size
> + */
> + sw_rings_base = rte_zmalloc_socket(
> + dev->device->driver->name,
> + dev_sw_ring_size, q_sw_ring_size, socket);
> +
> + if (sw_rings_base == NULL) {
Re: [dpdk-dev] [PATCH v9 05/10] baseband/acc100: add LDPC processing functions
On 9/28/20 5:29 PM, Nicolas Chautru wrote:
> Adding LDPC decode and encode processing operations
>
> Signed-off-by: Nicolas Chautru
> Acked-by: Liu Tianjiao
> Acked-by: Dave Burley
> ---
> doc/guides/bbdevs/features/acc100.ini|8 +-
> drivers/baseband/acc100/rte_acc100_pmd.c | 1625
> +-
> drivers/baseband/acc100/rte_acc100_pmd.h |3 +
> 3 files changed, 1630 insertions(+), 6 deletions(-)
>
> diff --git a/doc/guides/bbdevs/features/acc100.ini
> b/doc/guides/bbdevs/features/acc100.ini
> index c89a4d7..40c7adc 100644
> --- a/doc/guides/bbdevs/features/acc100.ini
> +++ b/doc/guides/bbdevs/features/acc100.ini
> @@ -6,9 +6,9 @@
> [Features]
> Turbo Decoder (4G) = N
> Turbo Encoder (4G) = N
> -LDPC Decoder (5G) = N
> -LDPC Encoder (5G) = N
> -LLR/HARQ Compression = N
> -External DDR Access= N
> +LDPC Decoder (5G) = Y
> +LDPC Encoder (5G) = Y
> +LLR/HARQ Compression = Y
> +External DDR Access= Y
> HW Accelerated = Y
> BBDEV API = Y
> diff --git a/drivers/baseband/acc100/rte_acc100_pmd.c
> b/drivers/baseband/acc100/rte_acc100_pmd.c
> index 7a21c57..b223547 100644
> --- a/drivers/baseband/acc100/rte_acc100_pmd.c
> +++ b/drivers/baseband/acc100/rte_acc100_pmd.c
> @@ -15,6 +15,9 @@
> #include
> #include
> #include
> +#ifdef RTE_BBDEV_OFFLOAD_COST
> +#include
> +#endif
>
> #include
> #include
> @@ -449,7 +452,6 @@
> return 0;
> }
>
> -
> /**
> * Report a ACC100 queue index which is free
> * Return 0 to 16k for a valid queue_idx or -1 when no queue is available
> @@ -634,6 +636,46 @@
> struct acc100_device *d = dev->data->dev_private;
>
> static const struct rte_bbdev_op_cap bbdev_capabilities[] = {
> + {
> + .type = RTE_BBDEV_OP_LDPC_ENC,
> + .cap.ldpc_enc = {
> + .capability_flags =
> + RTE_BBDEV_LDPC_RATE_MATCH |
> + RTE_BBDEV_LDPC_CRC_24B_ATTACH |
> + RTE_BBDEV_LDPC_INTERLEAVER_BYPASS,
> + .num_buffers_src =
> + RTE_BBDEV_LDPC_MAX_CODE_BLOCKS,
> + .num_buffers_dst =
> + RTE_BBDEV_LDPC_MAX_CODE_BLOCKS,
> + }
> + },
> + {
> + .type = RTE_BBDEV_OP_LDPC_DEC,
> + .cap.ldpc_dec = {
> + .capability_flags =
> + RTE_BBDEV_LDPC_CRC_TYPE_24B_CHECK |
> + RTE_BBDEV_LDPC_CRC_TYPE_24B_DROP |
> + RTE_BBDEV_LDPC_HQ_COMBINE_IN_ENABLE |
> + RTE_BBDEV_LDPC_HQ_COMBINE_OUT_ENABLE |
> +#ifdef ACC100_EXT_MEM
This is unconditionally defined in rte_acc100_pmd.h but it seems
like it could be a hw config. Please add a comment in the *.h
Could also change to
#if ACC100_EXT_MEM
and change the #define ACC100_EXT_MEM 1
> + RTE_BBDEV_LDPC_INTERNAL_HARQ_MEMORY_IN_ENABLE |
> + RTE_BBDEV_LDPC_INTERNAL_HARQ_MEMORY_OUT_ENABLE |
> +#endif
> + RTE_BBDEV_LDPC_ITERATION_STOP_ENABLE |
> + RTE_BBDEV_LDPC_DEINTERLEAVER_BYPASS |
> + RTE_BBDEV_LDPC_DECODE_BYPASS |
> + RTE_BBDEV_LDPC_DEC_SCATTER_GATHER |
> + RTE_BBDEV_LDPC_HARQ_6BIT_COMPRESSION |
> + RTE_BBDEV_LDPC_LLR_COMPRESSION,
> + .llr_size = 8,
> + .llr_decimals = 1,
> + .num_buffers_src =
> + RTE_BBDEV_LDPC_MAX_CODE_BLOCKS,
> + .num_buffers_hard_out =
> + RTE_BBDEV_LDPC_MAX_CODE_BLOCKS,
> + .num_buffers_soft_out = 0,
> + }
> + },
> RTE_BBDEV_END_OF_CAPABILITIES_LIST()
> };
>
> @@ -669,9 +711,14 @@
> dev_info->cpu_flag_reqs = NULL;
> dev_info->min_alignment = 64;
> dev_info->capabilities = bbdev_capabilities;
> +#ifdef ACC100_EXT_MEM
> dev_info->harq_buffer_size = d->ddr_size;
> +#else
> + dev_info->harq_buffer_size = 0;
> +#endif
> }
>
> +
> static const struct rte_bbdev_ops acc100_bbdev_ops = {
> .setup_queues = acc100_setup_queues,
> .close = acc100_dev_close,
> @@ -696,6 +743,1577 @@
> {.device_id = 0},
> };
>
> +/* Read flag value 0/1 from bitmap */
> +static inline bool
> +check_bit(uint32_t bitmap, uint32_t bitmask)
> +{
> + return bitmap & bitmask;
> +}
> +
All the bbdev have this function, its pretty trival but it would be good if
common bbdev
functions got moved to a common place.
> +static inl
Re: [dpdk-dev] [PATCH v9 06/10] baseband/acc100: add HARQ loopback support
On 9/28/20 5:29 PM, Nicolas Chautru wrote:
> Additional support for HARQ memory loopback
>
> Signed-off-by: Nicolas Chautru
> Acked-by: Liu Tianjiao
> ---
> drivers/baseband/acc100/rte_acc100_pmd.c | 158
> +++
> 1 file changed, 158 insertions(+)
>
> diff --git a/drivers/baseband/acc100/rte_acc100_pmd.c
> b/drivers/baseband/acc100/rte_acc100_pmd.c
> index b223547..e484c0a 100644
> --- a/drivers/baseband/acc100/rte_acc100_pmd.c
> +++ b/drivers/baseband/acc100/rte_acc100_pmd.c
> @@ -658,6 +658,7 @@
> RTE_BBDEV_LDPC_HQ_COMBINE_IN_ENABLE |
> RTE_BBDEV_LDPC_HQ_COMBINE_OUT_ENABLE |
> #ifdef ACC100_EXT_MEM
> + RTE_BBDEV_LDPC_INTERNAL_HARQ_MEMORY_LOOPBACK |
> RTE_BBDEV_LDPC_INTERNAL_HARQ_MEMORY_IN_ENABLE |
> RTE_BBDEV_LDPC_INTERNAL_HARQ_MEMORY_OUT_ENABLE |
> #endif
> @@ -1480,12 +1481,169 @@
> return 1;
> }
>
> +static inline int
> +harq_loopback(struct acc100_queue *q, struct rte_bbdev_dec_op *op,
> + uint16_t total_enqueued_cbs) {
> + struct acc100_fcw_ld *fcw;
> + union acc100_dma_desc *desc;
> + int next_triplet = 1;
> + struct rte_mbuf *hq_output_head, *hq_output;
> + uint16_t harq_in_length = op->ldpc_dec.harq_combined_input.length;
> + if (harq_in_length == 0) {
> + rte_bbdev_log(ERR, "Loopback of invalid null size\n");
> + return -EINVAL;
> + }
> +
> + int h_comp = check_bit(op->ldpc_dec.op_flags,
> + RTE_BBDEV_LDPC_HARQ_6BIT_COMPRESSION
> + ) ? 1 : 0;
bool
Tom
> + if (h_comp == 1)
> + harq_in_length = harq_in_length * 8 / 6;
> + harq_in_length = RTE_ALIGN(harq_in_length, 64);
> + uint16_t harq_dma_length_in = (h_comp == 0) ?
> + harq_in_length :
> + harq_in_length * 6 / 8;
> + uint16_t harq_dma_length_out = harq_dma_length_in;
> + bool ddr_mem_in = check_bit(op->ldpc_dec.op_flags,
> + RTE_BBDEV_LDPC_INTERNAL_HARQ_MEMORY_IN_ENABLE);
> + union acc100_harq_layout_data *harq_layout = q->d->harq_layout;
> + uint16_t harq_index = (ddr_mem_in ?
> + op->ldpc_dec.harq_combined_input.offset :
> + op->ldpc_dec.harq_combined_output.offset)
> + / ACC100_HARQ_OFFSET;
> +
> + uint16_t desc_idx = ((q->sw_ring_head + total_enqueued_cbs)
> + & q->sw_ring_wrap_mask);
> + desc = q->ring_addr + desc_idx;
> + fcw = &desc->req.fcw_ld;
> + /* Set the FCW from loopback into DDR */
> + memset(fcw, 0, sizeof(struct acc100_fcw_ld));
> + fcw->FCWversion = ACC100_FCW_VER;
> + fcw->qm = 2;
> + fcw->Zc = 384;
> + if (harq_in_length < 16 * N_ZC_1)
> + fcw->Zc = 16;
> + fcw->ncb = fcw->Zc * N_ZC_1;
> + fcw->rm_e = 2;
> + fcw->hcin_en = 1;
> + fcw->hcout_en = 1;
> +
> + rte_bbdev_log(DEBUG, "Loopback IN %d Index %d offset %d length %d %d\n",
> + ddr_mem_in, harq_index,
> + harq_layout[harq_index].offset, harq_in_length,
> + harq_dma_length_in);
> +
> + if (ddr_mem_in && (harq_layout[harq_index].offset > 0)) {
> + fcw->hcin_size0 = harq_layout[harq_index].size0;
> + fcw->hcin_offset = harq_layout[harq_index].offset;
> + fcw->hcin_size1 = harq_in_length - fcw->hcin_offset;
> + harq_dma_length_in = (fcw->hcin_size0 + fcw->hcin_size1);
> + if (h_comp == 1)
> + harq_dma_length_in = harq_dma_length_in * 6 / 8;
> + } else {
> + fcw->hcin_size0 = harq_in_length;
> + }
> + harq_layout[harq_index].val = 0;
> + rte_bbdev_log(DEBUG, "Loopback FCW Config %d %d %d\n",
> + fcw->hcin_size0, fcw->hcin_offset, fcw->hcin_size1);
> + fcw->hcout_size0 = harq_in_length;
> + fcw->hcin_decomp_mode = h_comp;
> + fcw->hcout_comp_mode = h_comp;
> + fcw->gain_i = 1;
> + fcw->gain_h = 1;
> +
> + /* Set the prefix of descriptor. This could be done at polling */
> + desc->req.word0 = ACC100_DMA_DESC_TYPE;
> + desc->req.word1 = 0; /**< Timestamp could be disabled */
> + desc->req.word2 = 0;
> + desc->req.word3 = 0;
> + desc->req.numCBs = 1;
> +
> + /* Null LLR input for Decoder */
> + desc->req.data_ptrs[next_triplet].address =
> + q->lb_in_addr_phys;
> + desc->req.data_ptrs[next_triplet].blen = 2;
> + desc->req.data_ptrs[next_triplet].blkid = ACC100_DMA_BLKID_IN;
> + desc->req.data_ptrs[next_triplet].last = 0;
> + desc->req.data_ptrs[next_triplet].dma_ext = 0;
> + next_triplet++;
> +
> + /* HARQ Combine input from either Memory interface */
> + if (!ddr_mem_in) {
> + next_triplet = acc100_dma_fill_blk_type_out(&desc->req,
> +
Re: [dpdk-dev] [PATCH v9 07/10] baseband/acc100: add support for 4G processing
On 9/28/20 5:29 PM, Nicolas Chautru wrote:
> Adding capability for 4G encode and decoder processing
>
> Signed-off-by: Nicolas Chautru
> Acked-by: Liu Tianjiao
> ---
> doc/guides/bbdevs/features/acc100.ini|4 +-
> drivers/baseband/acc100/rte_acc100_pmd.c | 1010
> --
> 2 files changed, 945 insertions(+), 69 deletions(-)
>
> diff --git a/doc/guides/bbdevs/features/acc100.ini
> b/doc/guides/bbdevs/features/acc100.ini
> index 40c7adc..642cd48 100644
> --- a/doc/guides/bbdevs/features/acc100.ini
> +++ b/doc/guides/bbdevs/features/acc100.ini
> @@ -4,8 +4,8 @@
> ; Refer to default.ini for the full list of available PMD features.
> ;
> [Features]
> -Turbo Decoder (4G) = N
> -Turbo Encoder (4G) = N
> +Turbo Decoder (4G) = Y
> +Turbo Encoder (4G) = Y
> LDPC Decoder (5G) = Y
> LDPC Encoder (5G) = Y
> LLR/HARQ Compression = Y
> diff --git a/drivers/baseband/acc100/rte_acc100_pmd.c
> b/drivers/baseband/acc100/rte_acc100_pmd.c
> index e484c0a..7d4c3df 100644
> --- a/drivers/baseband/acc100/rte_acc100_pmd.c
> +++ b/drivers/baseband/acc100/rte_acc100_pmd.c
> @@ -339,7 +339,6 @@
> free_base_addresses(base_addrs, i);
> }
>
> -
> /* Allocate 64MB memory used for all software rings */
> static int
> acc100_setup_queues(struct rte_bbdev *dev, uint16_t num_queues, int
> socket_id)
> @@ -637,6 +636,41 @@
>
> static const struct rte_bbdev_op_cap bbdev_capabilities[] = {
> {
> + .type = RTE_BBDEV_OP_TURBO_DEC,
> + .cap.turbo_dec = {
> + .capability_flags =
> + RTE_BBDEV_TURBO_SUBBLOCK_DEINTERLEAVE |
> + RTE_BBDEV_TURBO_CRC_TYPE_24B |
> + RTE_BBDEV_TURBO_HALF_ITERATION_EVEN |
> + RTE_BBDEV_TURBO_EARLY_TERMINATION |
> + RTE_BBDEV_TURBO_NEG_LLR_1_BIT_IN |
> + RTE_BBDEV_TURBO_MAP_DEC |
> + RTE_BBDEV_TURBO_DEC_TB_CRC_24B_KEEP |
> + RTE_BBDEV_TURBO_DEC_SCATTER_GATHER,
> + .max_llr_modulus = INT8_MAX,
> + .num_buffers_src =
> + RTE_BBDEV_TURBO_MAX_CODE_BLOCKS,
> + .num_buffers_hard_out =
> + RTE_BBDEV_TURBO_MAX_CODE_BLOCKS,
> + .num_buffers_soft_out =
> + RTE_BBDEV_TURBO_MAX_CODE_BLOCKS,
> + }
> + },
> + {
> + .type = RTE_BBDEV_OP_TURBO_ENC,
> + .cap.turbo_enc = {
> + .capability_flags =
> + RTE_BBDEV_TURBO_CRC_24B_ATTACH |
> + RTE_BBDEV_TURBO_RV_INDEX_BYPASS |
> + RTE_BBDEV_TURBO_RATE_MATCH |
> + RTE_BBDEV_TURBO_ENC_SCATTER_GATHER,
> + .num_buffers_src =
> + RTE_BBDEV_TURBO_MAX_CODE_BLOCKS,
> + .num_buffers_dst =
> + RTE_BBDEV_TURBO_MAX_CODE_BLOCKS,
> + }
> + },
> + {
> .type = RTE_BBDEV_OP_LDPC_ENC,
> .cap.ldpc_enc = {
> .capability_flags =
> @@ -719,7 +753,6 @@
> #endif
> }
>
> -
> static const struct rte_bbdev_ops acc100_bbdev_ops = {
> .setup_queues = acc100_setup_queues,
> .close = acc100_dev_close,
> @@ -763,6 +796,58 @@
> return tail;
> }
>
> +/* Fill in a frame control word for turbo encoding. */
> +static inline void
> +acc100_fcw_te_fill(const struct rte_bbdev_enc_op *op, struct acc100_fcw_te
> *fcw)
> +{
> + fcw->code_block_mode = op->turbo_enc.code_block_mode;
> + if (fcw->code_block_mode == 0) { /* For TB mode */
> + fcw->k_neg = op->turbo_enc.tb_params.k_neg;
> + fcw->k_pos = op->turbo_enc.tb_params.k_pos;
> + fcw->c_neg = op->turbo_enc.tb_params.c_neg;
> + fcw->c = op->turbo_enc.tb_params.c;
> + fcw->ncb_neg = op->turbo_enc.tb_params.ncb_neg;
> + fcw->ncb_pos = op->turbo_enc.tb_params.ncb_pos;
> +
> + if (check_bit(op->turbo_enc.op_flags,
> + RTE_BBDEV_TURBO_RATE_MATCH)) {
> + fcw->bypass_rm = 0;
> + fcw->cab = op->turbo_enc.tb_params.cab;
> + fcw->ea = op->turbo_enc.tb_params.ea;
> + fcw->eb = op->turbo_enc.tb_params.eb;
> + } else {
> + /* E is set to the
Re: [dpdk-dev] [PATCH v9 08/10] baseband/acc100: add interrupt support to PMD
On 9/28/20 5:29 PM, Nicolas Chautru wrote:
> Adding capability and functions to support MSI
> interrupts, call backs and inforing.
>
> Signed-off-by: Nicolas Chautru
> Acked-by: Liu Tianjiao
> ---
> drivers/baseband/acc100/rte_acc100_pmd.c | 288
> ++-
> drivers/baseband/acc100/rte_acc100_pmd.h | 15 ++
> 2 files changed, 300 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/baseband/acc100/rte_acc100_pmd.c
> b/drivers/baseband/acc100/rte_acc100_pmd.c
> index 7d4c3df..b6d9e7c 100644
> --- a/drivers/baseband/acc100/rte_acc100_pmd.c
> +++ b/drivers/baseband/acc100/rte_acc100_pmd.c
> @@ -339,6 +339,213 @@
> free_base_addresses(base_addrs, i);
> }
>
> +/*
> + * Find queue_id of a device queue based on details from the Info Ring.
> + * If a queue isn't found UINT16_MAX is returned.
> + */
> +static inline uint16_t
> +get_queue_id_from_ring_info(struct rte_bbdev_data *data,
> + const union acc100_info_ring_data ring_data)
> +{
> + uint16_t queue_id;
> +
> + for (queue_id = 0; queue_id < data->num_queues; ++queue_id) {
> + struct acc100_queue *acc100_q =
> + data->queues[queue_id].queue_private;
> + if (acc100_q != NULL && acc100_q->aq_id == ring_data.aq_id &&
> + acc100_q->qgrp_id == ring_data.qg_id &&
> + acc100_q->vf_id == ring_data.vf_id)
> + return queue_id;
If num_queues is large, this linear search will be slow.
Consider changing the search algorithm.
> + }
> +
> + return UINT16_MAX;
the interrupt handlers that use this function do not a great job of handling
this error.
> +}
> +
> +/* Checks PF Info Ring to find the interrupt cause and handles it
> accordingly */
> +static inline void
> +acc100_check_ir(struct acc100_device *acc100_dev)
> +{
> + volatile union acc100_info_ring_data *ring_data;
> + uint16_t info_ring_head = acc100_dev->info_ring_head;
> + if (acc100_dev->info_ring == NULL)
> + return;
> +
> + ring_data = acc100_dev->info_ring + (acc100_dev->info_ring_head &
> + ACC100_INFO_RING_MASK);
> +
> + while (ring_data->valid) {
> + if ((ring_data->int_nb < ACC100_PF_INT_DMA_DL_DESC_IRQ) || (
> + ring_data->int_nb >
> + ACC100_PF_INT_DMA_DL5G_DESC_IRQ))
> + rte_bbdev_log(WARNING, "InfoRing: ITR:%d Info:0x%x",
> + ring_data->int_nb, ring_data->detailed_info);
> + /* Initialize Info Ring entry and move forward */
> + ring_data->val = 0;
> + info_ring_head++;
> + ring_data = acc100_dev->info_ring +
> + (info_ring_head & ACC100_INFO_RING_MASK);
These three statements are common for the ring handling, consider a macro or
inline function.
> + }
> +}
> +
> +/* Checks PF Info Ring to find the interrupt cause and handles it
> accordingly */
> +static inline void
> +acc100_pf_interrupt_handler(struct rte_bbdev *dev)
> +{
> + struct acc100_device *acc100_dev = dev->data->dev_private;
> + volatile union acc100_info_ring_data *ring_data;
> + struct acc100_deq_intr_details deq_intr_det;
> +
> + ring_data = acc100_dev->info_ring + (acc100_dev->info_ring_head &
> + ACC100_INFO_RING_MASK);
> +
> + while (ring_data->valid) {
> +
> + rte_bbdev_log_debug(
> + "ACC100 PF Interrupt received, Info Ring data:
> 0x%x",
> + ring_data->val);
> +
> + switch (ring_data->int_nb) {
> + case ACC100_PF_INT_DMA_DL_DESC_IRQ:
> + case ACC100_PF_INT_DMA_UL_DESC_IRQ:
> + case ACC100_PF_INT_DMA_UL5G_DESC_IRQ:
> + case ACC100_PF_INT_DMA_DL5G_DESC_IRQ:
> + deq_intr_det.queue_id = get_queue_id_from_ring_info(
> + dev->data, *ring_data);
> + if (deq_intr_det.queue_id == UINT16_MAX) {
> + rte_bbdev_log(ERR,
> + "Couldn't find queue: aq_id:
> %u, qg_id: %u, vf_id: %u",
> + ring_data->aq_id,
> + ring_data->qg_id,
> + ring_data->vf_id);
> + return;
> + }
> + rte_bbdev_pmd_callback_process(dev,
> + RTE_BBDEV_EVENT_DEQUEUE, &deq_intr_det);
> + break;
> + default:
> + rte_bbdev_pmd_callback_process(dev,
> + RTE_BBDEV_EVENT_ERROR, NULL);
> + break;
> + }
> +
> + /* Initialize Info Ring entry and move forward */
> +
Re: [dpdk-dev] [PATCH v9 09/10] baseband/acc100: add debug function to validate input
On 9/28/20 5:29 PM, Nicolas Chautru wrote:
> Debug functions to validate the input API from user
> Only enabled in DEBUG mode at build time
>
> Signed-off-by: Nicolas Chautru
> Acked-by: Liu Tianjiao
> ---
> drivers/baseband/acc100/rte_acc100_pmd.c | 424
> +++
> 1 file changed, 424 insertions(+)
>
> diff --git a/drivers/baseband/acc100/rte_acc100_pmd.c
> b/drivers/baseband/acc100/rte_acc100_pmd.c
> index b6d9e7c..3589814 100644
> --- a/drivers/baseband/acc100/rte_acc100_pmd.c
> +++ b/drivers/baseband/acc100/rte_acc100_pmd.c
> @@ -1945,6 +1945,231 @@
>
> }
>
> +#ifdef RTE_LIBRTE_BBDEV_DEBUG
> +/* Validates turbo encoder parameters */
> +static inline int
> +validate_enc_op(struct rte_bbdev_enc_op *op)
> +{
> + struct rte_bbdev_op_turbo_enc *turbo_enc = &op->turbo_enc;
> + struct rte_bbdev_op_enc_turbo_cb_params *cb = NULL;
> + struct rte_bbdev_op_enc_turbo_tb_params *tb = NULL;
> + uint16_t kw, kw_neg, kw_pos;
> +
> + if (op->mempool == NULL) {
> + rte_bbdev_log(ERR, "Invalid mempool pointer");
> + return -1;
> + }
> + if (turbo_enc->input.data == NULL) {
> + rte_bbdev_log(ERR, "Invalid input pointer");
> + return -1;
> + }
> + if (turbo_enc->output.data == NULL) {
> + rte_bbdev_log(ERR, "Invalid output pointer");
> + return -1;
> + }
> + if (turbo_enc->rv_index > 3) {
> + rte_bbdev_log(ERR,
> + "rv_index (%u) is out of range 0 <= value <= 3",
> + turbo_enc->rv_index);
> + return -1;
> + }
> + if (turbo_enc->code_block_mode != 0 &&
> + turbo_enc->code_block_mode != 1) {
> + rte_bbdev_log(ERR,
> + "code_block_mode (%u) is out of range 0 <=
> value <= 1",
> + turbo_enc->code_block_mode);
> + return -1;
> + }
> +
> + if (turbo_enc->code_block_mode == 0) {
> + tb = &turbo_enc->tb_params;
> + if ((tb->k_neg < RTE_BBDEV_TURBO_MIN_CB_SIZE
> + || tb->k_neg > RTE_BBDEV_TURBO_MAX_CB_SIZE)
> + && tb->c_neg > 0) {
> + rte_bbdev_log(ERR,
> + "k_neg (%u) is out of range %u <= value
> <= %u",
> + tb->k_neg, RTE_BBDEV_TURBO_MIN_CB_SIZE,
> + RTE_BBDEV_TURBO_MAX_CB_SIZE);
> + return -1;
> + }
> + if (tb->k_pos < RTE_BBDEV_TURBO_MIN_CB_SIZE
> + || tb->k_pos > RTE_BBDEV_TURBO_MAX_CB_SIZE) {
> + rte_bbdev_log(ERR,
> + "k_pos (%u) is out of range %u <= value
> <= %u",
> + tb->k_pos, RTE_BBDEV_TURBO_MIN_CB_SIZE,
> + RTE_BBDEV_TURBO_MAX_CB_SIZE);
> + return -1;
> + }
> + if (tb->c_neg > (RTE_BBDEV_TURBO_MAX_CODE_BLOCKS - 1))
> + rte_bbdev_log(ERR,
> + "c_neg (%u) is out of range 0 <= value
> <= %u",
> + tb->c_neg,
> + RTE_BBDEV_TURBO_MAX_CODE_BLOCKS - 1);
> + if (tb->c < 1 || tb->c > RTE_BBDEV_TURBO_MAX_CODE_BLOCKS) {
> + rte_bbdev_log(ERR,
> + "c (%u) is out of range 1 <= value <=
> %u",
> + tb->c, RTE_BBDEV_TURBO_MAX_CODE_BLOCKS);
> + return -1;
> + }
> + if (tb->cab > tb->c) {
> + rte_bbdev_log(ERR,
> + "cab (%u) is greater than c (%u)",
> + tb->cab, tb->c);
> + return -1;
> + }
> + if ((tb->ea < RTE_BBDEV_TURBO_MIN_CB_SIZE || (tb->ea % 2))
> + && tb->r < tb->cab) {
> + rte_bbdev_log(ERR,
> + "ea (%u) is less than %u or it is not
> even",
> + tb->ea, RTE_BBDEV_TURBO_MIN_CB_SIZE);
> + return -1;
> + }
> + if ((tb->eb < RTE_BBDEV_TURBO_MIN_CB_SIZE || (tb->eb % 2))
> + && tb->c > tb->cab) {
> + rte_bbdev_log(ERR,
> + "eb (%u) is less than %u or it is not
> even",
> + tb->eb, RTE_BBDEV_TURBO_MIN_CB_SIZE);
> + return -1;
> + }
> +
> + kw_neg = 3 * RTE_ALIGN_CEIL(tb->k_neg + 4,
> + RTE_BBDEV_TURBO_C_SUBBLOCK);
> + if (tb->ncb_neg < tb->k_neg || tb->ncb_neg > kw_neg
Re: [dpdk-dev] [PATCH v9 10/10] baseband/acc100: add configure function
On 9/28/20 5:29 PM, Nicolas Chautru wrote:
> Add configure function to configure the PF from within
> the bbdev-test itself without external application
> configuration the device.
>
> Signed-off-by: Nicolas Chautru
> Acked-by: Liu Tianjiao
> ---
> app/test-bbdev/test_bbdev_perf.c | 72 +++
> doc/guides/rel_notes/release_20_11.rst | 5 +
> drivers/baseband/acc100/meson.build| 2 +
> drivers/baseband/acc100/rte_acc100_cfg.h | 17 +
> drivers/baseband/acc100/rte_acc100_pmd.c | 505
> +
> .../acc100/rte_pmd_bbdev_acc100_version.map| 7 +
> 6 files changed, 608 insertions(+)
>
> diff --git a/app/test-bbdev/test_bbdev_perf.c
> b/app/test-bbdev/test_bbdev_perf.c
> index 45c0d62..32f23ff 100644
> --- a/app/test-bbdev/test_bbdev_perf.c
> +++ b/app/test-bbdev/test_bbdev_perf.c
> @@ -52,6 +52,18 @@
> #define FLR_5G_TIMEOUT 610
> #endif
>
> +#ifdef RTE_LIBRTE_PMD_BBDEV_ACC100
> +#include
> +#define ACC100PF_DRIVER_NAME ("intel_acc100_pf")
> +#define ACC100VF_DRIVER_NAME ("intel_acc100_vf")
> +#define ACC100_QMGR_NUM_AQS 16
> +#define ACC100_QMGR_NUM_QGS 2
> +#define ACC100_QMGR_AQ_DEPTH 5
> +#define ACC100_QMGR_INVALID_IDX -1
> +#define ACC100_QMGR_RR 1
> +#define ACC100_QOS_GBR 0
> +#endif
> +
> #define OPS_CACHE_SIZE 256U
> #define OPS_POOL_SIZE_MIN 511U /* 0.5K per queue */
>
> @@ -653,6 +665,66 @@ typedef int (test_case_function)(struct active_device
> *ad,
> info->dev_name);
> }
> #endif
> +#ifdef RTE_LIBRTE_PMD_BBDEV_ACC100
seems like this function would break if one of the other bbdev's were #defined.
> + if ((get_init_device() == true) &&
> + (!strcmp(info->drv.driver_name, ACC100PF_DRIVER_NAME))) {
> + struct acc100_conf conf;
> + unsigned int i;
> +
> + printf("Configure ACC100 FEC Driver %s with default values\n",
> + info->drv.driver_name);
> +
> + /* clear default configuration before initialization */
> + memset(&conf, 0, sizeof(struct acc100_conf));
> +
> + /* Always set in PF mode for built-in configuration */
> + conf.pf_mode_en = true;
> + for (i = 0; i < RTE_ACC100_NUM_VFS; ++i) {
> + conf.arb_dl_4g[i].gbr_threshold1 = ACC100_QOS_GBR;
> + conf.arb_dl_4g[i].gbr_threshold1 = ACC100_QOS_GBR;
> + conf.arb_dl_4g[i].round_robin_weight = ACC100_QMGR_RR;
> + conf.arb_ul_4g[i].gbr_threshold1 = ACC100_QOS_GBR;
> + conf.arb_ul_4g[i].gbr_threshold1 = ACC100_QOS_GBR;
> + conf.arb_ul_4g[i].round_robin_weight = ACC100_QMGR_RR;
> + conf.arb_dl_5g[i].gbr_threshold1 = ACC100_QOS_GBR;
> + conf.arb_dl_5g[i].gbr_threshold1 = ACC100_QOS_GBR;
> + conf.arb_dl_5g[i].round_robin_weight = ACC100_QMGR_RR;
> + conf.arb_ul_5g[i].gbr_threshold1 = ACC100_QOS_GBR;
> + conf.arb_ul_5g[i].gbr_threshold1 = ACC100_QOS_GBR;
> + conf.arb_ul_5g[i].round_robin_weight = ACC100_QMGR_RR;
> + }
> +
> + conf.input_pos_llr_1_bit = true;
> + conf.output_pos_llr_1_bit = true;
> + conf.num_vf_bundles = 1; /**< Number of VF bundles to setup */
> +
> + conf.q_ul_4g.num_qgroups = ACC100_QMGR_NUM_QGS;
> + conf.q_ul_4g.first_qgroup_index = ACC100_QMGR_INVALID_IDX;
> + conf.q_ul_4g.num_aqs_per_groups = ACC100_QMGR_NUM_AQS;
> + conf.q_ul_4g.aq_depth_log2 = ACC100_QMGR_AQ_DEPTH;
> + conf.q_dl_4g.num_qgroups = ACC100_QMGR_NUM_QGS;
> + conf.q_dl_4g.first_qgroup_index = ACC100_QMGR_INVALID_IDX;
> + conf.q_dl_4g.num_aqs_per_groups = ACC100_QMGR_NUM_AQS;
> + conf.q_dl_4g.aq_depth_log2 = ACC100_QMGR_AQ_DEPTH;
> + conf.q_ul_5g.num_qgroups = ACC100_QMGR_NUM_QGS;
> + conf.q_ul_5g.first_qgroup_index = ACC100_QMGR_INVALID_IDX;
> + conf.q_ul_5g.num_aqs_per_groups = ACC100_QMGR_NUM_AQS;
> + conf.q_ul_5g.aq_depth_log2 = ACC100_QMGR_AQ_DEPTH;
> + conf.q_dl_5g.num_qgroups = ACC100_QMGR_NUM_QGS;
> + conf.q_dl_5g.first_qgroup_index = ACC100_QMGR_INVALID_IDX;
> + conf.q_dl_5g.num_aqs_per_groups = ACC100_QMGR_NUM_AQS;
> + conf.q_dl_5g.aq_depth_log2 = ACC100_QMGR_AQ_DEPTH;
> +
> + /* setup PF with configuration information */
> + ret = acc100_configure(info->dev_name, &conf);
> + TEST_ASSERT_SUCCESS(ret,
> + "Failed to configure ACC100 PF for bbdev %s",
> + info->dev_name);
> + /* Let's refresh this now this is configured */
> + }
> + rte_bbdev_info_get(dev_id, info);
The other bbdev's do not call rte_
Re: [dpdk-dev] [PATCH v9 01/10] drivers/baseband: add PMD for ACC100
On 9/29/20 4:17 PM, Chautru, Nicolas wrote: > Hi Tom, > >> -Original Message----- >> From: Tom Rix >> Sent: Tuesday, September 29, 2020 12:54 PM >> To: Chautru, Nicolas ; dev@dpdk.org; >> akhil.go...@nxp.com >> Cc: Richardson, Bruce ; Xu, Rosen >> ; dave.bur...@accelercomm.com; >> aidan.godd...@accelercomm.com; Yigit, Ferruh ; >> Liu, Tianjiao >> Subject: Re: [dpdk-dev] [PATCH v9 01/10] drivers/baseband: add PMD for >> ACC100 >> >> >> On 9/28/20 5:29 PM, Nicolas Chautru wrote: >>> Add stubs for the ACC100 PMD >>> >>> Signed-off-by: Nicolas Chautru >>> Acked-by: Liu Tianjiao >>> --- >>> doc/guides/bbdevs/acc100.rst | 233 >>> + >>> doc/guides/bbdevs/features/acc100.ini | 14 ++ >>> doc/guides/bbdevs/index.rst| 1 + >>> drivers/baseband/acc100/meson.build| 6 + >>> drivers/baseband/acc100/rte_acc100_pmd.c | 175 >> >>> drivers/baseband/acc100/rte_acc100_pmd.h | 37 >>> .../acc100/rte_pmd_bbdev_acc100_version.map| 3 + >>> drivers/baseband/meson.build | 2 +- >>> 8 files changed, 470 insertions(+), 1 deletion(-) create mode 100644 >>> doc/guides/bbdevs/acc100.rst create mode 100644 >>> doc/guides/bbdevs/features/acc100.ini >>> create mode 100644 drivers/baseband/acc100/meson.build >>> create mode 100644 drivers/baseband/acc100/rte_acc100_pmd.c >>> create mode 100644 drivers/baseband/acc100/rte_acc100_pmd.h >>> create mode 100644 >>> drivers/baseband/acc100/rte_pmd_bbdev_acc100_version.map >>> >>> diff --git a/doc/guides/bbdevs/acc100.rst >>> b/doc/guides/bbdevs/acc100.rst new file mode 100644 index >>> 000..f87ee09 >>> --- /dev/null >>> +++ b/doc/guides/bbdevs/acc100.rst >>> @@ -0,0 +1,233 @@ >>> +.. SPDX-License-Identifier: BSD-3-Clause >>> +Copyright(c) 2020 Intel Corporation >>> + >>> +Intel(R) ACC100 5G/4G FEC Poll Mode Driver >>> +== >>> + >>> +The BBDEV ACC100 5G/4G FEC poll mode driver (PMD) supports an >>> +implementation of a VRAN FEC wireless acceleration function. >>> +This device is also known as Mount Bryce. >> If this is code name or general chip name it should be removed. > We have used general chip name for other PMDs (ie. Vista Creek), I can remove > but > why should this be removed for my benefit? This tends to be the most user > friendly > name so arguablygood to name drop in documentation . VistaCreek is the code name, the chip would be aria10. Since mt bryce is the chip name, after more than 1 eASIC this becomes confusing. Generally public product names should be used because only the early developers will know the development code names. > > >>> + >>> +Features >>> + >>> + >>> +ACC100 5G/4G FEC PMD supports the following features: >>> + >>> +- LDPC Encode in the DL (5GNR) >>> +- LDPC Decode in the UL (5GNR) >>> +- Turbo Encode in the DL (4G) >>> +- Turbo Decode in the UL (4G) >>> +- 16 VFs per PF (physical device) >>> +- Maximum of 128 queues per VF >>> +- PCIe Gen-3 x16 Interface >>> +- MSI >>> +- SR-IOV >>> + >>> +ACC100 5G/4G FEC PMD supports the following BBDEV capabilities: >>> + >>> +* For the LDPC encode operation: >>> + - ``RTE_BBDEV_LDPC_CRC_24B_ATTACH`` : set to attach CRC24B to >> CB(s) >>> + - ``RTE_BBDEV_LDPC_RATE_MATCH`` : if set then do not do Rate Match >> bypass >>> + - ``RTE_BBDEV_LDPC_INTERLEAVER_BYPASS`` : if set then bypass >>> +interleaver >>> + >>> +* For the LDPC decode operation: >>> + - ``RTE_BBDEV_LDPC_CRC_TYPE_24B_CHECK`` : check CRC24B from >> CB(s) >>> + - ``RTE_BBDEV_LDPC_ITERATION_STOP_ENABLE`` : disable early >> termination >>> + - ``RTE_BBDEV_LDPC_CRC_TYPE_24B_DROP`` : drops CRC24B bits >> appended while decoding >>> + - ``RTE_BBDEV_LDPC_HQ_COMBINE_IN_ENABLE`` : provides an input >> for HARQ combining >>> + - ``RTE_BBDEV_LDPC_HQ_COMBINE_OUT_ENABLE`` : provides an input >> for HARQ combining >>> + - ``RTE_BBDEV_LDPC_INTERNAL_HARQ_MEMORY_IN_ENABLE`` : HARQ >> memory input is internal >>> + - ``RTE_BBDEV_LDPC_INTERNAL_HARQ_MEMORY_OUT_ENABLE`` : >> HARQ memor
Re: [dpdk-dev] [PATCH v9 02/10] baseband/acc100: add register definition file
On 9/29/20 4:30 PM, Chautru, Nicolas wrote:
> Hi Tom,
>
>> From: Tom Rix
>> On 9/28/20 5:29 PM, Nicolas Chautru wrote:
>>> Add in the list of registers for the device and related
>>> HW specs definitions.
>>>
>>> Signed-off-by: Nicolas Chautru
>>> Reviewed-by: Rosen Xu
>>> Acked-by: Liu Tianjiao
>>> ---
>>> drivers/baseband/acc100/acc100_pf_enum.h | 1068
>> ++
>>> drivers/baseband/acc100/acc100_vf_enum.h | 73 ++
>>> drivers/baseband/acc100/rte_acc100_pmd.h | 490 ++
>>> 3 files changed, 1631 insertions(+)
>>> create mode 100644 drivers/baseband/acc100/acc100_pf_enum.h
>>> create mode 100644 drivers/baseband/acc100/acc100_vf_enum.h
>>>
>>> diff --git a/drivers/baseband/acc100/acc100_pf_enum.h
>> b/drivers/baseband/acc100/acc100_pf_enum.h
>>> new file mode 100644
>>> index 000..a1ee416
>>> --- /dev/null
>>> +++ b/drivers/baseband/acc100/acc100_pf_enum.h
>>> @@ -0,0 +1,1068 @@
>>> +/* SPDX-License-Identifier: BSD-3-Clause
>>> + * Copyright(c) 2017 Intel Corporation
>>> + */
>>> +
>>> +#ifndef ACC100_PF_ENUM_H
>>> +#define ACC100_PF_ENUM_H
>>> +
>>> +/*
>>> + * ACC100 Register mapping on PF BAR0
>>> + * This is automatically generated from RDL, format may change with new
>> RDL
>>> + * Release.
>>> + * Variable names are as is
>>> + */
>>> +enum {
>>> + HWPfQmgrEgressQueuesTemplate = 0x0007FE00,
>>> + HWPfQmgrIngressAq = 0x0008,
>>> + HWPfQmgrArbQAvail = 0x00A00010,
>>> + HWPfQmgrArbQBlock = 0x00A00014,
>>> + HWPfQmgrAqueueDropNotifEn = 0x00A00024,
>>> + HWPfQmgrAqueueDisableNotifEn = 0x00A00028,
>>> + HWPfQmgrSoftReset = 0x00A00038,
>>> + HWPfQmgrInitStatus= 0x00A0003C,
>>> + HWPfQmgrAramWatchdogCount = 0x00A00040,
>>> + HWPfQmgrAramWatchdogCounterEn = 0x00A00044,
>>> + HWPfQmgrAxiWatchdogCount = 0x00A00048,
>>> + HWPfQmgrAxiWatchdogCounterEn = 0x00A0004C,
>>> + HWPfQmgrProcessWatchdogCount = 0x00A00050,
>>> + HWPfQmgrProcessWatchdogCounterEn = 0x00A00054,
>>> + HWPfQmgrProcessUl4GWatchdogCounter= 0x00A00058,
>>> + HWPfQmgrProcessDl4GWatchdogCounter= 0x00A0005C,
>>> + HWPfQmgrProcessUl5GWatchdogCounter= 0x00A00060,
>>> + HWPfQmgrProcessDl5GWatchdogCounter= 0x00A00064,
>>> + HWPfQmgrProcessMldWatchdogCounter = 0x00A00068,
>>> + HWPfQmgrMsiOverflowUpperVf= 0x00A00070,
>>> + HWPfQmgrMsiOverflowLowerVf= 0x00A00074,
>>> + HWPfQmgrMsiWatchdogOverflow = 0x00A00078,
>>> + HWPfQmgrMsiOverflowEnable = 0x00A0007C,
>>> + HWPfQmgrDebugAqPointerMemGrp = 0x00A00100,
>>> + HWPfQmgrDebugOutputArbQFifoGrp= 0x00A00140,
>>> + HWPfQmgrDebugMsiFifoGrp = 0x00A00180,
>>> + HWPfQmgrDebugAxiWdTimeoutMsiFifo = 0x00A001C0,
>>> + HWPfQmgrDebugProcessWdTimeoutMsiFifo = 0x00A001C4,
>>> + HWPfQmgrDepthLog2Grp = 0x00A00200,
>>> + HWPfQmgrTholdGrp = 0x00A00300,
>>> + HWPfQmgrGrpTmplateReg0Indx= 0x00A00600,
>>> + HWPfQmgrGrpTmplateReg1Indx= 0x00A00680,
>>> + HWPfQmgrGrpTmplateReg2indx= 0x00A00700,
>>> + HWPfQmgrGrpTmplateReg3Indx= 0x00A00780,
>>> + HWPfQmgrGrpTmplateReg4Indx= 0x00A00800,
>>> + HWPfQmgrVfBaseAddr= 0x00A01000,
>>> + HWPfQmgrUl4GWeightRrVf= 0x00A02000,
>>> + HWPfQmgrDl4GWeightRrVf= 0x00A02100,
>>> + HWPfQmgrUl5GWeightRrVf= 0x00A02200,
>>> + HWPfQmgrDl5GWeightRrVf= 0x00A02300,
>>> + HWPfQmgrMldWeightRrVf = 0x00A02400,
>>> + HWPfQmgrArbQDepthGrp = 0x00A02F00,
>>> + HWPfQmgrGrpFunction0 = 0x00A02F40,
>>> + HWPfQmgrGrpFunction1 = 0x00A02F44,
>>> + HWPfQmgrGrpPriority = 0x00A02F48,
>>> + HWPfQmgrWeightSync= 0x00A03000,
>>> + HWPfQmgrAqEnableVf= 0x00A1,
>>> + HWPfQmgrA
Re: [dpdk-dev] [PATCH v9 03/10] baseband/acc100: add info get function
On 9/29/20 5:25 PM, Chautru, Nicolas wrote:
> Hi Tom,
>
>> From: Tom Rix
>> On 9/28/20 5:29 PM, Nicolas Chautru wrote:
>>> Add in the "info_get" function to the driver, to allow us to query the
>>> device.
>>> No processing capability are available yet.
>>> Linking bbdev-test to support the PMD with null capability.
>>>
>>> Signed-off-by: Nicolas Chautru
>>> Acked-by: Liu Tianjiao
>>> ---
>>> app/test-bbdev/meson.build | 3 +
>>> drivers/baseband/acc100/rte_acc100_cfg.h | 96 +
>>> drivers/baseband/acc100/rte_acc100_pmd.c | 225
>> +++
>>> drivers/baseband/acc100/rte_acc100_pmd.h | 3 +
>>> 4 files changed, 327 insertions(+)
>>> create mode 100644 drivers/baseband/acc100/rte_acc100_cfg.h
>>>
>>> diff --git a/app/test-bbdev/meson.build b/app/test-bbdev/meson.build
>>> index 18ab6a8..fbd8ae3 100644
>>> --- a/app/test-bbdev/meson.build
>>> +++ b/app/test-bbdev/meson.build
>>> @@ -12,3 +12,6 @@ endif
>>> if dpdk_conf.has('RTE_LIBRTE_PMD_BBDEV_FPGA_5GNR_FEC')
>>> deps += ['pmd_bbdev_fpga_5gnr_fec']
>>> endif
>>> +if dpdk_conf.has('RTE_LIBRTE_PMD_BBDEV_ACC100')
>>> + deps += ['pmd_bbdev_acc100']
>>> +endif
>>> \ No newline at end of file
>>> diff --git a/drivers/baseband/acc100/rte_acc100_cfg.h
>>> b/drivers/baseband/acc100/rte_acc100_cfg.h
>>> new file mode 100644
>>> index 000..73bbe36
>>> --- /dev/null
>>> +++ b/drivers/baseband/acc100/rte_acc100_cfg.h
>>> @@ -0,0 +1,96 @@
>>> +/* SPDX-License-Identifier: BSD-3-Clause
>>> + * Copyright(c) 2020 Intel Corporation */
>>> +
>>> +#ifndef _RTE_ACC100_CFG_H_
>>> +#define _RTE_ACC100_CFG_H_
>>> +
>>> +/**
>>> + * @file rte_acc100_cfg.h
>>> + *
>>> + * Functions for configuring ACC100 HW, exposed directly to applications.
>>> + * Configuration related to encoding/decoding is done through the
>>> + * librte_bbdev library.
>>> + *
>>> + * @warning
>>> + * @b EXPERIMENTAL: this API may change without prior notice
>> When will this experimental tag be removed ?
> I have pushed a patch to remove it. But the feedback from some of the
> community was to wait a bit more until next year.
ok, i am late to the party. i'll chip in when this issue comes around again.
>
>>> + */
>>> +
>>> +#include
>>> +#include
>>> +
>>> +#ifdef __cplusplus
>>> +extern "C" {
>>> +#endif
>>> +/**< Number of Virtual Functions ACC100 supports */ #define
>>> +RTE_ACC100_NUM_VFS 16
>> This is already defined with ACC100_NUM_VFS
> Thanks.
>
>>> +
>>> +/**
>>> + * Definition of Queue Topology for ACC100 Configuration
>>> + * Some level of details is abstracted out to expose a clean
>>> +interface
>>> + * given that comprehensive flexibility is not required */ struct
>>> +rte_q_topology_t {
>>> + /** Number of QGroups in incremental order of priority */
>>> + uint16_t num_qgroups;
>>> + /**
>>> +* All QGroups have the same number of AQs here.
>>> +* Note : Could be made a 16-array if more flexibility is really
>>> +* required
>>> +*/
>>> + uint16_t num_aqs_per_groups;
>>> + /**
>>> +* Depth of the AQs is the same of all QGroups here. Log2 Enum : 2^N
>>> +* Note : Could be made a 16-array if more flexibility is really
>>> +* required
>>> +*/
>>> + uint16_t aq_depth_log2;
>>> + /**
>>> +* Index of the first Queue Group Index - assuming contiguity
>>> +* Initialized as -1
>>> +*/
>>> + int8_t first_qgroup_index;
>>> +};
>>> +
>>> +/**
>>> + * Definition of Arbitration related parameters for ACC100
>>> +Configuration */ struct rte_arbitration_t {
>>> + /** Default Weight for VF Fairness Arbitration */
>>> + uint16_t round_robin_weight;
>>> + uint32_t gbr_threshold1; /**< Guaranteed Bitrate Threshold 1 */
>>> + uint32_t gbr_threshold2; /**< Guaranteed Bitrate Threshold 2 */ };
>>> +
>>> +/**
>>> + * Structure to pass ACC100 configuration.
>>> + * Note: all VF Bundles will have the same configuration.
>>> + */
>>> +struct acc100_conf {
>>
Re: [dpdk-dev] [PATCH v9 04/10] baseband/acc100: add queue configuration
On 9/29/20 6:03 PM, Chautru, Nicolas wrote:
> Hi Tom,
>
>> From: Tom Rix
>> On 9/28/20 5:29 PM, Nicolas Chautru wrote:
>>> Adding function to create and configure queues for the device. Still
>>> no capability.
>>>
>>> Signed-off-by: Nicolas Chautru
>>> Reviewed-by: Rosen Xu
>>> Acked-by: Liu Tianjiao
>>> ---
>>> drivers/baseband/acc100/rte_acc100_pmd.c | 420
>>> ++-
>>> drivers/baseband/acc100/rte_acc100_pmd.h | 45
>>> 2 files changed, 464 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/baseband/acc100/rte_acc100_pmd.c
>>> b/drivers/baseband/acc100/rte_acc100_pmd.c
>>> index 7807a30..7a21c57 100644
>>> --- a/drivers/baseband/acc100/rte_acc100_pmd.c
>>> +++ b/drivers/baseband/acc100/rte_acc100_pmd.c
>>> @@ -26,6 +26,22 @@
>>> RTE_LOG_REGISTER(acc100_logtype, pmd.bb.acc100, NOTICE); #endif
>>>
>>> +/* Write to MMIO register address */
>>> +static inline void
>>> +mmio_write(void *addr, uint32_t value) {
>>> + *((volatile uint32_t *)(addr)) = rte_cpu_to_le_32(value); }
>>> +
>>> +/* Write a register of a ACC100 device */ static inline void
>>> +acc100_reg_write(struct acc100_device *d, uint32_t offset, uint32_t
>>> +payload) {
>>> + void *reg_addr = RTE_PTR_ADD(d->mmio_base, offset);
>>> + mmio_write(reg_addr, payload);
>>> + usleep(1000);
>> rte_acc100_pmd.h defines LONG_WAIT , could this #define be used instead
>> ?
> ok
>
>>> +}
>>> +
>>> /* Read a register of a ACC100 device */ static inline uint32_t
>>> acc100_reg_read(struct acc100_device *d, uint32_t offset) @@ -36,6
>>> +52,22 @@
>>> return rte_le_to_cpu_32(ret);
>>> }
>>>
>>> +/* Basic Implementation of Log2 for exact 2^N */ static inline
>>> +uint32_t log2_basic(uint32_t value)
>> mirrors the function rte_bsf32
> rte_bsf32 is also undefined for zero input.
> I could just replace __builtin_ctz() by rte_bsf32() indeed.
>
>>> +{
>>> + return (value == 0) ? 0 : __builtin_ctz(value); }
>>> +
>>> +/* Calculate memory alignment offset assuming alignment is 2^N */
>>> +static inline uint32_t calc_mem_alignment_offset(void
>>> +*unaligned_virt_mem, uint32_t alignment) {
>>> + rte_iova_t unaligned_phy_mem =
>> rte_malloc_virt2iova(unaligned_virt_mem);
>>> + return (uint32_t)(alignment -
>>> + (unaligned_phy_mem & (alignment-1))); }
>>> +
>>> /* Calculate the offset of the enqueue register */ static inline
>>> uint32_t queue_offset(bool pf_device, uint8_t vf_id, uint8_t qgrp_id,
>>> uint16_t aq_id) @@ -204,10 +236,393 @@
>>> acc100_conf->q_dl_5g.aq_depth_log2);
>>> }
>>>
>>> +static void
>>> +free_base_addresses(void **base_addrs, int size) {
>>> + int i;
>>> + for (i = 0; i < size; i++)
>>> + rte_free(base_addrs[i]);
>>> +}
>>> +
>>> +static inline uint32_t
>>> +get_desc_len(void)
>>> +{
>>> + return sizeof(union acc100_dma_desc); }
>>> +
>>> +/* Allocate the 2 * 64MB block for the sw rings */ static int
>>> +alloc_2x64mb_sw_rings_mem(struct rte_bbdev *dev, struct
>> acc100_device *d,
>>> + int socket)
>> see earlier comment about name of function.
> replied in other patch set
>
>>> +{
>>> + uint32_t sw_ring_size = ACC100_SIZE_64MBYTE;
>>> + d->sw_rings_base = rte_zmalloc_socket(dev->device->driver->name,
>>> + 2 * sw_ring_size, RTE_CACHE_LINE_SIZE, socket);
>>> + if (d->sw_rings_base == NULL) {
>>> + rte_bbdev_log(ERR, "Failed to allocate memory for %s:%u",
>>> + dev->device->driver->name,
>>> + dev->data->dev_id);
>>> + return -ENOMEM;
>>> + }
>>> + memset(d->sw_rings_base, 0, ACC100_SIZE_64MBYTE);
>>> + uint32_t next_64mb_align_offset = calc_mem_alignment_offset(
>>> + d->sw_rings_base, ACC100_SIZE_64MBYTE);
>>> + d->sw_rings = RTE_PTR_ADD(d->sw_rings_base,
>> next_64mb_align_offset);
>>> + d->sw_rings_phys = rte_malloc_virt2iova(d->sw_rings_base) +
>>> + next_64mb_align_offset;
>>> + d->sw_ring_size = MAX_QUEUE_DEPTH * get_desc_len(
Re: [dpdk-dev] [PATCH v9 05/10] baseband/acc100: add LDPC processing functions
On 9/30/20 11:52 AM, Chautru, Nicolas wrote:
> Hi Tom,
>
>> From: Tom Rix
>> On 9/28/20 5:29 PM, Nicolas Chautru wrote:
>>> Adding LDPC decode and encode processing operations
>>>
>>> Signed-off-by: Nicolas Chautru
>>> Acked-by: Liu Tianjiao
>>> Acked-by: Dave Burley
>>> ---
>>> doc/guides/bbdevs/features/acc100.ini|8 +-
>>> drivers/baseband/acc100/rte_acc100_pmd.c | 1625
>> +-
>>> drivers/baseband/acc100/rte_acc100_pmd.h |3 +
>>> 3 files changed, 1630 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/doc/guides/bbdevs/features/acc100.ini
>> b/doc/guides/bbdevs/features/acc100.ini
>>> index c89a4d7..40c7adc 100644
>>> --- a/doc/guides/bbdevs/features/acc100.ini
>>> +++ b/doc/guides/bbdevs/features/acc100.ini
>>> @@ -6,9 +6,9 @@
>>> [Features]
>>> Turbo Decoder (4G) = N
>>> Turbo Encoder (4G) = N
>>> -LDPC Decoder (5G) = N
>>> -LDPC Encoder (5G) = N
>>> -LLR/HARQ Compression = N
>>> -External DDR Access= N
>>> +LDPC Decoder (5G) = Y
>>> +LDPC Encoder (5G) = Y
>>> +LLR/HARQ Compression = Y
>>> +External DDR Access= Y
>>> HW Accelerated = Y
>>> BBDEV API = Y
>>> diff --git a/drivers/baseband/acc100/rte_acc100_pmd.c
>> b/drivers/baseband/acc100/rte_acc100_pmd.c
>>> index 7a21c57..b223547 100644
>>> --- a/drivers/baseband/acc100/rte_acc100_pmd.c
>>> +++ b/drivers/baseband/acc100/rte_acc100_pmd.c
>>> @@ -15,6 +15,9 @@
>>> #include
>>> #include
>>> #include
>>> +#ifdef RTE_BBDEV_OFFLOAD_COST
>>> +#include
>>> +#endif
>>>
>>> #include
>>> #include
>>> @@ -449,7 +452,6 @@
>>> return 0;
>>> }
>>>
>>> -
>>> /**
>>> * Report a ACC100 queue index which is free
>>> * Return 0 to 16k for a valid queue_idx or -1 when no queue is available
>>> @@ -634,6 +636,46 @@
>>> struct acc100_device *d = dev->data->dev_private;
>>>
>>> static const struct rte_bbdev_op_cap bbdev_capabilities[] = {
>>> + {
>>> + .type = RTE_BBDEV_OP_LDPC_ENC,
>>> + .cap.ldpc_enc = {
>>> + .capability_flags =
>>> + RTE_BBDEV_LDPC_RATE_MATCH |
>>> +
>> RTE_BBDEV_LDPC_CRC_24B_ATTACH |
>>> +
>> RTE_BBDEV_LDPC_INTERLEAVER_BYPASS,
>>> + .num_buffers_src =
>>> +
>> RTE_BBDEV_LDPC_MAX_CODE_BLOCKS,
>>> + .num_buffers_dst =
>>> +
>> RTE_BBDEV_LDPC_MAX_CODE_BLOCKS,
>>> + }
>>> + },
>>> + {
>>> + .type = RTE_BBDEV_OP_LDPC_DEC,
>>> + .cap.ldpc_dec = {
>>> + .capability_flags =
>>> + RTE_BBDEV_LDPC_CRC_TYPE_24B_CHECK |
>>> + RTE_BBDEV_LDPC_CRC_TYPE_24B_DROP |
>>> +
>> RTE_BBDEV_LDPC_HQ_COMBINE_IN_ENABLE |
>>> +
>> RTE_BBDEV_LDPC_HQ_COMBINE_OUT_ENABLE |
>>> +#ifdef ACC100_EXT_MEM
>> This is unconditionally defined in rte_acc100_pmd.h but it seems
>>
>> like it could be a hw config. Please add a comment in the *.h
>>
> It is not really an HW config, just a potential alternate way to run
> the device notably for troubleshooting.
> I can add a comment though
>
>> Could also change to
>>
>> #if ACC100_EXT_MEM
>>
>> and change the #define ACC100_EXT_MEM 1
> ok
>
>>> +
>> RTE_BBDEV_LDPC_INTERNAL_HARQ_MEMORY_IN_ENABLE |
>>> +
>> RTE_BBDEV_LDPC_INTERNAL_HARQ_MEMORY_OUT_ENABLE |
>>> +#endif
>>> +
>> RTE_BBDEV_LDPC_ITERATION_STOP_ENABLE |
>>> + RTE_BBDEV_LDPC_DEINTERLEAVER_BYPASS
>> |
>>> + RTE_BBDEV_LDPC_DECODE_BYPASS |
>>> + RTE_BBDEV_LDPC_DEC_SCATTER_GATHER |
>>> +
>> RTE_BBDEV_LDPC_HARQ_6BIT_COMPRESSION |
>>> + RTE_BBDEV_LDPC_LLR_COMPRESSION,
>>> + .llr_size = 8,
>>> + .llr_decimals = 1,
>>> + .num_buffers_src =
>>> +
>> RTE_BBDEV_LDPC_MA
Re: [dpdk-dev] [PATCH v9 06/10] baseband/acc100: add HARQ loopback support
On 9/30/20 11:55 AM, Chautru, Nicolas wrote:
> Hi Tom,
>
>
>> From: Tom Rix
>> On 9/28/20 5:29 PM, Nicolas Chautru wrote:
>>> Additional support for HARQ memory loopback
>>>
>>> Signed-off-by: Nicolas Chautru
>>> Acked-by: Liu Tianjiao
>>> ---
>>> drivers/baseband/acc100/rte_acc100_pmd.c | 158
>>> +++
>>> 1 file changed, 158 insertions(+)
>>>
>>> diff --git a/drivers/baseband/acc100/rte_acc100_pmd.c
>>> b/drivers/baseband/acc100/rte_acc100_pmd.c
>>> index b223547..e484c0a 100644
>>> --- a/drivers/baseband/acc100/rte_acc100_pmd.c
>>> +++ b/drivers/baseband/acc100/rte_acc100_pmd.c
>>> @@ -658,6 +658,7 @@
>>>
>> RTE_BBDEV_LDPC_HQ_COMBINE_IN_ENABLE |
>> RTE_BBDEV_LDPC_HQ_COMBINE_OUT_ENABLE | #ifdef
>> ACC100_EXT_MEM
>>> +
>> RTE_BBDEV_LDPC_INTERNAL_HARQ_MEMORY_LOOPBACK |
>> RTE_BBDEV_LDPC_INTERNAL_HARQ_MEMORY_IN_ENABLE |
>> RTE_BBDEV_LDPC_INTERNAL_HARQ_MEMORY_OUT_ENABLE |
>> #endif @@
>>> -1480,12 +1481,169 @@
>>> return 1;
>>> }
>>>
>>> +static inline int
>>> +harq_loopback(struct acc100_queue *q, struct rte_bbdev_dec_op *op,
>>> + uint16_t total_enqueued_cbs) {
>>> + struct acc100_fcw_ld *fcw;
>>> + union acc100_dma_desc *desc;
>>> + int next_triplet = 1;
>>> + struct rte_mbuf *hq_output_head, *hq_output;
>>> + uint16_t harq_in_length = op-
>>> ldpc_dec.harq_combined_input.length;
>>> + if (harq_in_length == 0) {
>>> + rte_bbdev_log(ERR, "Loopback of invalid null size\n");
>>> + return -EINVAL;
>>> + }
>>> +
>>> + int h_comp = check_bit(op->ldpc_dec.op_flags,
>>> + RTE_BBDEV_LDPC_HARQ_6BIT_COMPRESSION
>>> + ) ? 1 : 0;
>> bool
> Not in that case as this is used explictly as an integer in the FCW.
ok.
Reviewed-by: Tom Rix
>
> Thanks
> Nic
>
>
>> Tom
>>
>>> + if (h_comp == 1)
>>> + harq_in_length = harq_in_length * 8 / 6;
>>> + harq_in_length = RTE_ALIGN(harq_in_length, 64);
>>> + uint16_t harq_dma_length_in = (h_comp == 0) ?
>>> + harq_in_length :
>>> + harq_in_length * 6 / 8;
>>> + uint16_t harq_dma_length_out = harq_dma_length_in;
>>> + bool ddr_mem_in = check_bit(op->ldpc_dec.op_flags,
>>> +
>> RTE_BBDEV_LDPC_INTERNAL_HARQ_MEMORY_IN_ENABLE);
>>> + union acc100_harq_layout_data *harq_layout = q->d->harq_layout;
>>> + uint16_t harq_index = (ddr_mem_in ?
>>> + op->ldpc_dec.harq_combined_input.offset :
>>> + op->ldpc_dec.harq_combined_output.offset)
>>> + / ACC100_HARQ_OFFSET;
>>> +
>>> + uint16_t desc_idx = ((q->sw_ring_head + total_enqueued_cbs)
>>> + & q->sw_ring_wrap_mask);
>>> + desc = q->ring_addr + desc_idx;
>>> + fcw = &desc->req.fcw_ld;
>>> + /* Set the FCW from loopback into DDR */
>>> + memset(fcw, 0, sizeof(struct acc100_fcw_ld));
>>> + fcw->FCWversion = ACC100_FCW_VER;
>>> + fcw->qm = 2;
>>> + fcw->Zc = 384;
>>> + if (harq_in_length < 16 * N_ZC_1)
>>> + fcw->Zc = 16;
>>> + fcw->ncb = fcw->Zc * N_ZC_1;
>>> + fcw->rm_e = 2;
>>> + fcw->hcin_en = 1;
>>> + fcw->hcout_en = 1;
>>> +
>>> + rte_bbdev_log(DEBUG, "Loopback IN %d Index %d offset %d length
>> %d %d\n",
>>> + ddr_mem_in, harq_index,
>>> + harq_layout[harq_index].offset, harq_in_length,
>>> + harq_dma_length_in);
>>> +
>>> + if (ddr_mem_in && (harq_layout[harq_index].offset > 0)) {
>>> + fcw->hcin_size0 = harq_layout[harq_index].size0;
>>> + fcw->hcin_offset = harq_layout[harq_index].offset;
>>> + fcw->hcin_size1 = harq_in_length - fcw->hcin_offset;
>>> + harq_dma_length_in = (fcw->hcin_size0 + fcw->hcin_size1);
>>> + if (h_comp == 1)
>>> + harq_dma_length_in = harq_dma_length_in * 6 / 8;
>>> + } else {
>>> + fcw->hcin_size0 = harq_in_length;
>>> + }
>>> + harq_layout[harq_index].val = 0;
>
Re: [dpdk-dev] [PATCH v9 07/10] baseband/acc100: add support for 4G processing
On 9/30/20 12:10 PM, Chautru, Nicolas wrote:
> Hi Tom,
>
>> From: Tom Rix
>> On 9/28/20 5:29 PM, Nicolas Chautru wrote:
>>> Adding capability for 4G encode and decoder processing
>>>
>>> Signed-off-by: Nicolas Chautru
>>> Acked-by: Liu Tianjiao
>>> ---
>>> doc/guides/bbdevs/features/acc100.ini|4 +-
>>> drivers/baseband/acc100/rte_acc100_pmd.c | 1010
>>> --
>>> 2 files changed, 945 insertions(+), 69 deletions(-)
>>>
>>> diff --git a/doc/guides/bbdevs/features/acc100.ini
>>> b/doc/guides/bbdevs/features/acc100.ini
>>> index 40c7adc..642cd48 100644
>>> --- a/doc/guides/bbdevs/features/acc100.ini
>>> +++ b/doc/guides/bbdevs/features/acc100.ini
>>> @@ -4,8 +4,8 @@
>>> ; Refer to default.ini for the full list of available PMD features.
>>> ;
>>> [Features]
>>> -Turbo Decoder (4G) = N
>>> -Turbo Encoder (4G) = N
>>> +Turbo Decoder (4G) = Y
>>> +Turbo Encoder (4G) = Y
>>> LDPC Decoder (5G) = Y
>>> LDPC Encoder (5G) = Y
>>> LLR/HARQ Compression = Y
>>> diff --git a/drivers/baseband/acc100/rte_acc100_pmd.c
>>> b/drivers/baseband/acc100/rte_acc100_pmd.c
>>> index e484c0a..7d4c3df 100644
>>> --- a/drivers/baseband/acc100/rte_acc100_pmd.c
>>> +++ b/drivers/baseband/acc100/rte_acc100_pmd.c
>>> @@ -339,7 +339,6 @@
>>> free_base_addresses(base_addrs, i);
>>> }
>>>
>>> -
>>> /* Allocate 64MB memory used for all software rings */ static int
>>> acc100_setup_queues(struct rte_bbdev *dev, uint16_t num_queues, int
>>> socket_id) @@ -637,6 +636,41 @@
>>>
>>> static const struct rte_bbdev_op_cap bbdev_capabilities[] = {
>>> {
>>> + .type = RTE_BBDEV_OP_TURBO_DEC,
>>> + .cap.turbo_dec = {
>>> + .capability_flags =
>>> +
>> RTE_BBDEV_TURBO_SUBBLOCK_DEINTERLEAVE |
>>> + RTE_BBDEV_TURBO_CRC_TYPE_24B
>> |
>>> +
>> RTE_BBDEV_TURBO_HALF_ITERATION_EVEN |
>>> +
>> RTE_BBDEV_TURBO_EARLY_TERMINATION |
>>> +
>> RTE_BBDEV_TURBO_NEG_LLR_1_BIT_IN |
>>> + RTE_BBDEV_TURBO_MAP_DEC |
>>> +
>> RTE_BBDEV_TURBO_DEC_TB_CRC_24B_KEEP |
>>> +
>> RTE_BBDEV_TURBO_DEC_SCATTER_GATHER,
>>> + .max_llr_modulus = INT8_MAX,
>>> + .num_buffers_src =
>>> +
>> RTE_BBDEV_TURBO_MAX_CODE_BLOCKS,
>>> + .num_buffers_hard_out =
>>> +
>> RTE_BBDEV_TURBO_MAX_CODE_BLOCKS,
>>> + .num_buffers_soft_out =
>>> +
>> RTE_BBDEV_TURBO_MAX_CODE_BLOCKS,
>>> + }
>>> + },
>>> + {
>>> + .type = RTE_BBDEV_OP_TURBO_ENC,
>>> + .cap.turbo_enc = {
>>> + .capability_flags =
>>> +
>> RTE_BBDEV_TURBO_CRC_24B_ATTACH |
>>> +
>> RTE_BBDEV_TURBO_RV_INDEX_BYPASS |
>>> + RTE_BBDEV_TURBO_RATE_MATCH |
>>> +
>> RTE_BBDEV_TURBO_ENC_SCATTER_GATHER,
>>> + .num_buffers_src =
>>> +
>> RTE_BBDEV_TURBO_MAX_CODE_BLOCKS,
>>> + .num_buffers_dst =
>>> +
>> RTE_BBDEV_TURBO_MAX_CODE_BLOCKS,
>>> + }
>>> + },
>>> + {
>>> .type = RTE_BBDEV_OP_LDPC_ENC,
>>> .cap.ldpc_enc = {
>>> .capability_flags =
>>> @@ -719,7 +753,6 @@
>>> #endif
>>> }
>>>
>>> -
>>> static const struct rte_bbdev_ops acc100_bbdev_ops = {
>>> .setup_queues = acc100_setup_queues,
>>> .close = acc100_dev_close,
>>> @@ -763,6 +796,58 @@
>>> return tail;
>>> }
>>>
>>> +/* Fill in a frame control word for turbo encoding. */ static inline
>>> +void acc100_fcw_te_fill(const struct rte_bbdev_enc_op *op, struct
>>> +acc100_fcw_te *fcw) {
>>> + fcw->code_block_mode = op->turbo_enc.code_block_mode;
>>> + if (fcw->code_block_mode == 0) { /* For TB mode */
>>> + fcw-
Re: [dpdk-dev] [PATCH v9 08/10] baseband/acc100: add interrupt support to PMD
On 9/30/20 12:45 PM, Chautru, Nicolas wrote:
> Hi Tom,
>
>> From: Tom Rix
>> On 9/28/20 5:29 PM, Nicolas Chautru wrote:
>>> Adding capability and functions to support MSI interrupts, call backs
>>> and inforing.
>>>
>>> Signed-off-by: Nicolas Chautru
>>> Acked-by: Liu Tianjiao
>>> ---
>>> drivers/baseband/acc100/rte_acc100_pmd.c | 288
>>> ++-
>>> drivers/baseband/acc100/rte_acc100_pmd.h | 15 ++
>>> 2 files changed, 300 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/baseband/acc100/rte_acc100_pmd.c
>>> b/drivers/baseband/acc100/rte_acc100_pmd.c
>>> index 7d4c3df..b6d9e7c 100644
>>> --- a/drivers/baseband/acc100/rte_acc100_pmd.c
>>> +++ b/drivers/baseband/acc100/rte_acc100_pmd.c
>>> @@ -339,6 +339,213 @@
>>> free_base_addresses(base_addrs, i);
>>> }
>>>
>>> +/*
>>> + * Find queue_id of a device queue based on details from the Info Ring.
>>> + * If a queue isn't found UINT16_MAX is returned.
>>> + */
>>> +static inline uint16_t
>>> +get_queue_id_from_ring_info(struct rte_bbdev_data *data,
>>> + const union acc100_info_ring_data ring_data) {
>>> + uint16_t queue_id;
>>> +
>>> + for (queue_id = 0; queue_id < data->num_queues; ++queue_id) {
>>> + struct acc100_queue *acc100_q =
>>> + data->queues[queue_id].queue_private;
>>> + if (acc100_q != NULL && acc100_q->aq_id == ring_data.aq_id
>> &&
>>> + acc100_q->qgrp_id == ring_data.qg_id &&
>>> + acc100_q->vf_id == ring_data.vf_id)
>>> + return queue_id;
>> If num_queues is large, this linear search will be slow.
>>
>> Consider changing the search algorithm.
> This is not in the time critical part of the code
ok
>
>
>>> + }
>>> +
>>> + return UINT16_MAX;
>> the interrupt handlers that use this function do not a great job of handling
>> this error.
> if that error actualy happened then there is not much else that can be done
> except reporting the unexpected data.
ok
>
>>> +}
>>> +
>>> +/* Checks PF Info Ring to find the interrupt cause and handles it
>>> +accordingly */ static inline void acc100_check_ir(struct
>>> +acc100_device *acc100_dev) {
>>> + volatile union acc100_info_ring_data *ring_data;
>>> + uint16_t info_ring_head = acc100_dev->info_ring_head;
>>> + if (acc100_dev->info_ring == NULL)
>>> + return;
>>> +
>>> + ring_data = acc100_dev->info_ring + (acc100_dev->info_ring_head &
>>> + ACC100_INFO_RING_MASK);
>>> +
>>> + while (ring_data->valid) {
>>> + if ((ring_data->int_nb <
>> ACC100_PF_INT_DMA_DL_DESC_IRQ) || (
>>> + ring_data->int_nb >
>>> + ACC100_PF_INT_DMA_DL5G_DESC_IRQ))
>>> + rte_bbdev_log(WARNING, "InfoRing: ITR:%d
>> Info:0x%x",
>>> + ring_data->int_nb, ring_data-
>>> detailed_info);
>>> + /* Initialize Info Ring entry and move forward */
>>> + ring_data->val = 0;
>>> + info_ring_head++;
>>> + ring_data = acc100_dev->info_ring +
>>> + (info_ring_head &
>> ACC100_INFO_RING_MASK);
>> These three statements are common for the ring handling, consider a macro
>> or inline function.
> ok
>
>>> + }
>>> +}
>>> +
>>> +/* Checks PF Info Ring to find the interrupt cause and handles it
>>> +accordingly */ static inline void acc100_pf_interrupt_handler(struct
>>> +rte_bbdev *dev) {
>>> + struct acc100_device *acc100_dev = dev->data->dev_private;
>>> + volatile union acc100_info_ring_data *ring_data;
>>> + struct acc100_deq_intr_details deq_intr_det;
>>> +
>>> + ring_data = acc100_dev->info_ring + (acc100_dev->info_ring_head &
>>> + ACC100_INFO_RING_MASK);
>>> +
>>> + while (ring_data->valid) {
>>> +
>>> + rte_bbdev_log_debug(
>>> + "ACC100 PF Interrupt received, Info Ring
>> data: 0x%x",
>>> +
Re: [dpdk-dev] [PATCH v9 09/10] baseband/acc100: add debug function to validate input
On 9/30/20 12:53 PM, Chautru, Nicolas wrote:
> Hi Tom,
>
>> From: Tom Rix
>> On 9/28/20 5:29 PM, Nicolas Chautru wrote:
>>> Debug functions to validate the input API from user Only enabled in
>>> DEBUG mode at build time
>>>
>>> Signed-off-by: Nicolas Chautru
>>> Acked-by: Liu Tianjiao
>>> ---
>>> drivers/baseband/acc100/rte_acc100_pmd.c | 424
>>> +++
>>> 1 file changed, 424 insertions(+)
>>>
>>> diff --git a/drivers/baseband/acc100/rte_acc100_pmd.c
>>> b/drivers/baseband/acc100/rte_acc100_pmd.c
>>> index b6d9e7c..3589814 100644
>>> --- a/drivers/baseband/acc100/rte_acc100_pmd.c
>>> +++ b/drivers/baseband/acc100/rte_acc100_pmd.c
>>> @@ -1945,6 +1945,231 @@
>>>
>>> }
>>>
>>> +#ifdef RTE_LIBRTE_BBDEV_DEBUG
>>> +/* Validates turbo encoder parameters */ static inline int
>>> +validate_enc_op(struct rte_bbdev_enc_op *op) {
>>> + struct rte_bbdev_op_turbo_enc *turbo_enc = &op->turbo_enc;
>>> + struct rte_bbdev_op_enc_turbo_cb_params *cb = NULL;
>>> + struct rte_bbdev_op_enc_turbo_tb_params *tb = NULL;
>>> + uint16_t kw, kw_neg, kw_pos;
>>> +
>>> + if (op->mempool == NULL) {
>>> + rte_bbdev_log(ERR, "Invalid mempool pointer");
>>> + return -1;
>>> + }
>>> + if (turbo_enc->input.data == NULL) {
>>> + rte_bbdev_log(ERR, "Invalid input pointer");
>>> + return -1;
>>> + }
>>> + if (turbo_enc->output.data == NULL) {
>>> + rte_bbdev_log(ERR, "Invalid output pointer");
>>> + return -1;
>>> + }
>>> + if (turbo_enc->rv_index > 3) {
>>> + rte_bbdev_log(ERR,
>>> + "rv_index (%u) is out of range 0 <= value <=
>> 3",
>>> + turbo_enc->rv_index);
>>> + return -1;
>>> + }
>>> + if (turbo_enc->code_block_mode != 0 &&
>>> + turbo_enc->code_block_mode != 1) {
>>> + rte_bbdev_log(ERR,
>>> + "code_block_mode (%u) is out of range 0 <=
>> value <= 1",
>>> + turbo_enc->code_block_mode);
>>> + return -1;
>>> + }
>>> +
>>> + if (turbo_enc->code_block_mode == 0) {
>>> + tb = &turbo_enc->tb_params;
>>> + if ((tb->k_neg < RTE_BBDEV_TURBO_MIN_CB_SIZE
>>> + || tb->k_neg >
>> RTE_BBDEV_TURBO_MAX_CB_SIZE)
>>> + && tb->c_neg > 0) {
>>> + rte_bbdev_log(ERR,
>>> + "k_neg (%u) is out of range %u <=
>> value <= %u",
>>> + tb->k_neg,
>> RTE_BBDEV_TURBO_MIN_CB_SIZE,
>>> + RTE_BBDEV_TURBO_MAX_CB_SIZE);
>>> + return -1;
>>> + }
>>> + if (tb->k_pos < RTE_BBDEV_TURBO_MIN_CB_SIZE
>>> + || tb->k_pos >
>> RTE_BBDEV_TURBO_MAX_CB_SIZE) {
>>> + rte_bbdev_log(ERR,
>>> + "k_pos (%u) is out of range %u <=
>> value <= %u",
>>> + tb->k_pos,
>> RTE_BBDEV_TURBO_MIN_CB_SIZE,
>>> + RTE_BBDEV_TURBO_MAX_CB_SIZE);
>>> + return -1;
>>> + }
>>> + if (tb->c_neg > (RTE_BBDEV_TURBO_MAX_CODE_BLOCKS -
>> 1))
>>> + rte_bbdev_log(ERR,
>>> + "c_neg (%u) is out of range 0 <= value
>> <= %u",
>>> + tb->c_neg,
>>> +
>> RTE_BBDEV_TURBO_MAX_CODE_BLOCKS - 1);
>>> + if (tb->c < 1 || tb->c >
>> RTE_BBDEV_TURBO_MAX_CODE_BLOCKS) {
>>> + rte_bbdev_log(ERR,
>>> + "c (%u) is out of range 1 <= value <=
>> %u",
>>> + tb->c,
>> RTE_BBDEV_TURBO_MAX_CODE_BLOCKS);
>>> + return -1;
>>> + }
>>> + if (
Re: [dpdk-dev] [PATCH v9 10/10] baseband/acc100: add configure function
On 9/30/20 3:54 PM, Chautru, Nicolas wrote:
> Hi Tom,
>
>> From: Tom Rix
>> On 9/28/20 5:29 PM, Nicolas Chautru wrote:
>>> Add configure function to configure the PF from within the
>>> bbdev-test itself without external application configuration the device.
>>>
>>> Signed-off-by: Nicolas Chautru
>>> Acked-by: Liu Tianjiao
>>> ---
>>> app/test-bbdev/test_bbdev_perf.c | 72 +++
>>> doc/guides/rel_notes/release_20_11.rst | 5 +
>>> drivers/baseband/acc100/meson.build| 2 +
>>> drivers/baseband/acc100/rte_acc100_cfg.h | 17 +
>>> drivers/baseband/acc100/rte_acc100_pmd.c | 505
>> +
>>> .../acc100/rte_pmd_bbdev_acc100_version.map| 7 +
>>> 6 files changed, 608 insertions(+)
>>>
>>> diff --git a/app/test-bbdev/test_bbdev_perf.c
>>> b/app/test-bbdev/test_bbdev_perf.c
>>> index 45c0d62..32f23ff 100644
>>> --- a/app/test-bbdev/test_bbdev_perf.c
>>> +++ b/app/test-bbdev/test_bbdev_perf.c
>>> @@ -52,6 +52,18 @@
>>> #define FLR_5G_TIMEOUT 610
>>> #endif
>>>
>>> +#ifdef RTE_LIBRTE_PMD_BBDEV_ACC100
>>> +#include
>>> +#define ACC100PF_DRIVER_NAME ("intel_acc100_pf")
>>> +#define ACC100VF_DRIVER_NAME ("intel_acc100_vf")
>>> +#define ACC100_QMGR_NUM_AQS 16
>>> +#define ACC100_QMGR_NUM_QGS 2
>>> +#define ACC100_QMGR_AQ_DEPTH 5
>>> +#define ACC100_QMGR_INVALID_IDX -1
>>> +#define ACC100_QMGR_RR 1
>>> +#define ACC100_QOS_GBR 0
>>> +#endif
>>> +
>>> #define OPS_CACHE_SIZE 256U
>>> #define OPS_POOL_SIZE_MIN 511U /* 0.5K per queue */
>>>
>>> @@ -653,6 +665,66 @@ typedef int (test_case_function)(struct
>> active_device *ad,
>>> info->dev_name);
>>> }
>>> #endif
>>> +#ifdef RTE_LIBRTE_PMD_BBDEV_ACC100
>> seems like this function would break if one of the other bbdev's were
>> #defined.
> No these are independent. By default they are all defined.
ok
>
>
>>> + if ((get_init_device() == true) &&
>>> + (!strcmp(info->drv.driver_name,
>> ACC100PF_DRIVER_NAME))) {
>>> + struct acc100_conf conf;
>>> + unsigned int i;
>>> +
>>> + printf("Configure ACC100 FEC Driver %s with default
>> values\n",
>>> + info->drv.driver_name);
>>> +
>>> + /* clear default configuration before initialization */
>>> + memset(&conf, 0, sizeof(struct acc100_conf));
>>> +
>>> + /* Always set in PF mode for built-in configuration */
>>> + conf.pf_mode_en = true;
>>> + for (i = 0; i < RTE_ACC100_NUM_VFS; ++i) {
>>> + conf.arb_dl_4g[i].gbr_threshold1 =
>> ACC100_QOS_GBR;
>>> + conf.arb_dl_4g[i].gbr_threshold1 =
>> ACC100_QOS_GBR;
>>> + conf.arb_dl_4g[i].round_robin_weight =
>> ACC100_QMGR_RR;
>>> + conf.arb_ul_4g[i].gbr_threshold1 =
>> ACC100_QOS_GBR;
>>> + conf.arb_ul_4g[i].gbr_threshold1 =
>> ACC100_QOS_GBR;
>>> + conf.arb_ul_4g[i].round_robin_weight =
>> ACC100_QMGR_RR;
>>> + conf.arb_dl_5g[i].gbr_threshold1 =
>> ACC100_QOS_GBR;
>>> + conf.arb_dl_5g[i].gbr_threshold1 =
>> ACC100_QOS_GBR;
>>> + conf.arb_dl_5g[i].round_robin_weight =
>> ACC100_QMGR_RR;
>>> + conf.arb_ul_5g[i].gbr_threshold1 =
>> ACC100_QOS_GBR;
>>> + conf.arb_ul_5g[i].gbr_threshold1 =
>> ACC100_QOS_GBR;
>>> + conf.arb_ul_5g[i].round_robin_weight =
>> ACC100_QMGR_RR;
>>> + }
>>> +
>>> + conf.input_pos_llr_1_bit = true;
>>> + conf.output_pos_llr_1_bit = true;
>>> + conf.num_vf_bundles = 1; /**< Number of VF bundles to
>> setup */
>>> +
>>> + conf.q_ul_4g.num_qgroups = ACC100_QMGR_NUM_QGS;
>>> + conf.q_ul_4g.first_qgroup_index =
>> ACC100_QMGR_INVALID_IDX;
>>> + conf.q_ul_4g.num_aqs_per_groups =
>> ACC100_QMGR_NUM_AQS;
>>> + conf.q_ul_4g.aq_depth_log2 = ACC100_QMGR_AQ_DEPTH;
>>> + conf.q_dl_4g.num_qgroups =
Re: [dpdk-dev] [PATCH] maintainers: New Reviewer entry type added to MAINTAINERS
On 10/1/20 2:54 PM, Thomas Monjalon wrote: > 01/10/2020 23:22, Chautru, Nicolas: >> From: t...@redhat.com >>> From: Tom Rix >>> >>> Copied from the Linux kernel MAINTAINERS file. >>> A Reviewer is designated person who wishes to review changes in areas of >>> interest. >>> >>> Added self as Reviewer for baseband. >>> >>> I am a Linux kernel Reviewer for the fpga n3000/vista creek which has >>> several bitstream based baseband devices. So I want to help out here as >>> well. >>> >>> Signed-off-by: Tom Rix >> Thanks for the help. >> Note that they are a few other BBDEV patches in flight for 20.11 on top of >> the acc100 PMD that you may want to be aware of. >> https://patches.dpdk.org/project/dpdk/list/?series=&submitter=chautru&state=&q=&archive=&delegate= >> >> Acked-by: Nicolas Chautru > [...] >>> Baseband API - EXPERIMENTAL >>> M: Nicolas Chautru >>> +R: Tom Rix > I don't understand the need of differenciating maintainer and reviewer. > If you are trusted enough, why not just being co-maintainer? > I want to help out with the reviews, the reviewer type makes clear this level of commitment. Maintainer is the next, higher level of commitment. Trust wise, this would allow the maintainer verify the reviewer does have the bandwidth to be responsive and effective before committing to sharing responsibility. Tom >
Re: [dpdk-dev] [PATCH] maintainers: New Reviewer entry type added to MAINTAINERS
On 10/2/20 8:41 AM, Thomas Monjalon wrote: > 02/10/2020 16:59, Tom Rix: >> On 10/1/20 2:54 PM, Thomas Monjalon wrote: >>> 01/10/2020 23:22, Chautru, Nicolas: >>>> From: t...@redhat.com >>>>> From: Tom Rix >>>>> >>>>> Copied from the Linux kernel MAINTAINERS file. >>>>> A Reviewer is designated person who wishes to review changes in areas of >>>>> interest. >>>>> >>>>> Added self as Reviewer for baseband. >>>>> >>>>> I am a Linux kernel Reviewer for the fpga n3000/vista creek which has >>>>> several bitstream based baseband devices. So I want to help out here as >>>>> well. >>>>> >>>>> Signed-off-by: Tom Rix >>>> Thanks for the help. >>>> Note that they are a few other BBDEV patches in flight for 20.11 on top of >>>> the acc100 PMD that you may want to be aware of. >>>> https://patches.dpdk.org/project/dpdk/list/?series=&submitter=chautru&state=&q=&archive=&delegate= >>>> >>>> Acked-by: Nicolas Chautru >>> [...] >>>>> Baseband API - EXPERIMENTAL >>>>> M: Nicolas Chautru >>>>> +R: Tom Rix >>> I don't understand the need of differenciating maintainer and reviewer. >>> If you are trusted enough, why not just being co-maintainer? >>> >> I want to help out with the reviews, the reviewer type makes clear this >> level of commitment. >> >> Maintainer is the next, higher level of commitment. >> >> >> Trust wise, this would allow the maintainer verify the reviewer does have >> the bandwidth to be responsive >> >> and effective before committing to sharing responsibility. > Sorry I fail to understand. > My understanding is that you want to be Cc > but not committing for responsibility. > Would it be the same if you create a mail filter on your side? > > This model is really not clear to me so I'm reluctant to add > such new category until I understand the benefit. > That's fine, i will change the patch and use the existing process. Tom
Re: [dpdk-dev] [PATCH 1/2] baseband/fpga_5gnr_fec: fix API naming
fpga_5gnr_fec_remove(struct rte_pci_device *pci_dev)
> }
>
> static inline void
> -set_default_fpga_conf(struct fpga_5gnr_fec_conf *def_conf)
> +set_default_fpga_conf(struct rte_fpga_5gnr_fec_conf *def_conf)
> {
> /* clear default configuration before initialization */
> - memset(def_conf, 0, sizeof(struct fpga_5gnr_fec_conf));
> + memset(def_conf, 0, sizeof(struct rte_fpga_5gnr_fec_conf));
> /* Set pf mode to true */
> def_conf->pf_mode_en = true;
>
> @@ -1962,15 +1962,15 @@ set_default_fpga_conf(struct fpga_5gnr_fec_conf
> *def_conf)
>
> /* Initial configuration of FPGA 5GNR FEC device */
> int
> -fpga_5gnr_fec_configure(const char *dev_name,
> - const struct fpga_5gnr_fec_conf *conf)
> +rte_fpga_5gnr_fec_configure(const char *dev_name,
> + const struct rte_fpga_5gnr_fec_conf *conf)
> {
> uint32_t payload_32, address;
> uint16_t payload_16;
> uint8_t payload_8;
> uint16_t q_id, vf_id, total_q_id, total_ul_q_id, total_dl_q_id;
> struct rte_bbdev *bbdev = rte_bbdev_get_named_dev(dev_name);
> - struct fpga_5gnr_fec_conf def_conf;
> + struct rte_fpga_5gnr_fec_conf def_conf;
>
> if (bbdev == NULL) {
> rte_bbdev_log(ERR,
> diff --git
> a/drivers/baseband/fpga_5gnr_fec/rte_pmd_bbdev_fpga_5gnr_fec_version.map
> b/drivers/baseband/fpga_5gnr_fec/rte_pmd_bbdev_fpga_5gnr_fec_version.map
> index d723bc9b0e..db43cd8403 100644
> --- a/drivers/baseband/fpga_5gnr_fec/rte_pmd_bbdev_fpga_5gnr_fec_version.map
> +++ b/drivers/baseband/fpga_5gnr_fec/rte_pmd_bbdev_fpga_5gnr_fec_version.map
> @@ -5,6 +5,6 @@ DPDK_21 {
> EXPERIMENTAL {
> global:
>
> - fpga_5gnr_fec_configure;
> + rte_fpga_5gnr_fec_configure;
>
> };
> diff --git a/drivers/baseband/fpga_5gnr_fec/rte_pmd_fpga_5gnr_fec.h
> b/drivers/baseband/fpga_5gnr_fec/rte_pmd_fpga_5gnr_fec.h
> index 70a4acf0b7..c2752fbd52 100644
> --- a/drivers/baseband/fpga_5gnr_fec/rte_pmd_fpga_5gnr_fec.h
> +++ b/drivers/baseband/fpga_5gnr_fec/rte_pmd_fpga_5gnr_fec.h
> @@ -30,7 +30,7 @@ extern "C" {
> /**
> * Structure to pass FPGA 4G FEC configuration.
4G ?
There are a number of 4G references in this file's comments.
Consider a future patch to clean this up.
> */
> -struct fpga_5gnr_fec_conf {
> +struct rte_fpga_5gnr_fec_conf {
> /** 1 if PF is used for dataplane, 0 for VFs */
> bool pf_mode_en;
> /** Number of UL queues per VF */
> @@ -64,8 +64,8 @@ struct fpga_5gnr_fec_conf {
> */
> __rte_experimental
> int
> -fpga_5gnr_fec_configure(const char *dev_name,
> - const struct fpga_5gnr_fec_conf *conf);
> +rte_fpga_5gnr_fec_configure(const char *dev_name,
> + const struct rte_fpga_5gnr_fec_conf *conf);
>
> #ifdef __cplusplus
> }
Changes look complete.
Reviewed-by: Tom Rix
Re: [dpdk-dev] [PATCH 2/2] baseband/fpga_lte_fec: fix API naming
fault_fpga_conf(struct fpga_lte_fec_conf *def_conf)
> +set_default_fpga_conf(struct rte_fpga_lte_fec_conf *def_conf)
> {
> /* clear default configuration before initialization */
> - memset(def_conf, 0, sizeof(struct fpga_lte_fec_conf));
> + memset(def_conf, 0, sizeof(struct rte_fpga_lte_fec_conf));
> /* Set pf mode to true */
> def_conf->pf_mode_en = true;
>
> @@ -2450,15 +2450,15 @@ set_default_fpga_conf(struct fpga_lte_fec_conf
> *def_conf)
>
> /* Initial configuration of FPGA LTE FEC device */
> int
> -fpga_lte_fec_configure(const char *dev_name,
> - const struct fpga_lte_fec_conf *conf)
> +rte_fpga_lte_fec_configure(const char *dev_name,
> + const struct rte_fpga_lte_fec_conf *conf)
> {
> uint32_t payload_32, address;
> uint16_t payload_16;
> uint8_t payload_8;
> uint16_t q_id, vf_id, total_q_id, total_ul_q_id, total_dl_q_id;
> struct rte_bbdev *bbdev = rte_bbdev_get_named_dev(dev_name);
> - struct fpga_lte_fec_conf def_conf;
> + struct rte_fpga_lte_fec_conf def_conf;
>
> if (bbdev == NULL) {
> rte_bbdev_log(ERR,
> diff --git a/drivers/baseband/fpga_lte_fec/fpga_lte_fec.h
> b/drivers/baseband/fpga_lte_fec/fpga_lte_fec.h
> index b2e423c87c..b35c7a484e 100644
> --- a/drivers/baseband/fpga_lte_fec/fpga_lte_fec.h
> +++ b/drivers/baseband/fpga_lte_fec/fpga_lte_fec.h
> @@ -30,7 +30,7 @@ extern "C" {
> /**
> * Structure to pass FPGA 4G FEC configuration.
> */
> -struct fpga_lte_fec_conf {
> +struct rte_fpga_lte_fec_conf {
> /**< 1 if PF is used for dataplane, 0 for VFs */
> bool pf_mode_en;
> /**< Number of UL queues per VF */
> @@ -64,8 +64,8 @@ struct fpga_lte_fec_conf {
> */
> __rte_experimental
> int
> -fpga_lte_fec_configure(const char *dev_name,
> - const struct fpga_lte_fec_conf *conf);
> +rte_fpga_lte_fec_configure(const char *dev_name,
> + const struct rte_fpga_lte_fec_conf *conf);
>
> #ifdef __cplusplus
> }
> diff --git
> a/drivers/baseband/fpga_lte_fec/rte_pmd_bbdev_fpga_lte_fec_version.map
> b/drivers/baseband/fpga_lte_fec/rte_pmd_bbdev_fpga_lte_fec_version.map
> index a2ab086cd8..b95b7838e8 100644
> --- a/drivers/baseband/fpga_lte_fec/rte_pmd_bbdev_fpga_lte_fec_version.map
> +++ b/drivers/baseband/fpga_lte_fec/rte_pmd_bbdev_fpga_lte_fec_version.map
> @@ -5,6 +5,6 @@ DPDK_21 {
> EXPERIMENTAL {
> global:
>
> - fpga_lte_fec_configure;
> + rte_fpga_lte_fec_configure;
>
> };
Looks fine.
Reviewed-by: Tom Rix
Re: [dpdk-dev] [PATCH v11 01/10] drivers/baseband: add PMD for ACC100
On 10/1/20 6:01 PM, Nicolas Chautru wrote: > Add stubs for the ACC100 PMD > > Signed-off-by: Nicolas Chautru > Acked-by: Liu Tianjiao > --- > doc/guides/bbdevs/acc100.rst | 228 > + > doc/guides/bbdevs/features/acc100.ini | 14 ++ > doc/guides/bbdevs/index.rst| 1 + > drivers/baseband/acc100/meson.build| 6 + > drivers/baseband/acc100/rte_acc100_pmd.c | 175 > drivers/baseband/acc100/rte_acc100_pmd.h | 37 > .../acc100/rte_pmd_bbdev_acc100_version.map| 3 + > drivers/baseband/meson.build | 2 +- > 8 files changed, 465 insertions(+), 1 deletion(-) > create mode 100644 doc/guides/bbdevs/acc100.rst > create mode 100644 doc/guides/bbdevs/features/acc100.ini > create mode 100644 drivers/baseband/acc100/meson.build > create mode 100644 drivers/baseband/acc100/rte_acc100_pmd.c > create mode 100644 drivers/baseband/acc100/rte_acc100_pmd.h > create mode 100644 drivers/baseband/acc100/rte_pmd_bbdev_acc100_version.map Looks fine. Reviewed-by: Tom Rix
Re: [dpdk-dev] [PATCH v11 02/10] baseband/acc100: add register definition file
On 10/1/20 6:01 PM, Nicolas Chautru wrote: > Add in the list of registers for the device and related > HW specs definitions. > > Signed-off-by: Nicolas Chautru > Reviewed-by: Rosen Xu > Acked-by: Liu Tianjiao > --- > drivers/baseband/acc100/acc100_pf_enum.h | 1068 > ++ > drivers/baseband/acc100/acc100_vf_enum.h | 73 ++ > drivers/baseband/acc100/rte_acc100_pmd.h | 487 ++ > 3 files changed, 1628 insertions(+) > create mode 100644 drivers/baseband/acc100/acc100_pf_enum.h > create mode 100644 drivers/baseband/acc100/acc100_vf_enum.h Thanks for the changes. Reviewed-by: Tom Rix
Re: [dpdk-dev] [PATCH v11 03/10] baseband/acc100: add info get function
On 10/1/20 6:01 PM, Nicolas Chautru wrote:
> Add in the "info_get" function to the driver, to allow us to query the
> device.
> No processing capability are available yet.
> Linking bbdev-test to support the PMD with null capability.
>
> Signed-off-by: Nicolas Chautru
> Acked-by: Liu Tianjiao
> ---
> app/test-bbdev/meson.build | 3 +
> drivers/baseband/acc100/rte_acc100_cfg.h | 96 +
> drivers/baseband/acc100/rte_acc100_pmd.c | 229
> +++
> drivers/baseband/acc100/rte_acc100_pmd.h | 10 ++
> 4 files changed, 338 insertions(+)
> create mode 100644 drivers/baseband/acc100/rte_acc100_cfg.h
>
> diff --git a/app/test-bbdev/meson.build b/app/test-bbdev/meson.build
> index 18ab6a8..fbd8ae3 100644
> --- a/app/test-bbdev/meson.build
> +++ b/app/test-bbdev/meson.build
> @@ -12,3 +12,6 @@ endif
> if dpdk_conf.has('RTE_LIBRTE_PMD_BBDEV_FPGA_5GNR_FEC')
> deps += ['pmd_bbdev_fpga_5gnr_fec']
> endif
> +if dpdk_conf.has('RTE_LIBRTE_PMD_BBDEV_ACC100')
> + deps += ['pmd_bbdev_acc100']
> +endif
> \ No newline at end of file
> diff --git a/drivers/baseband/acc100/rte_acc100_cfg.h
> b/drivers/baseband/acc100/rte_acc100_cfg.h
> new file mode 100644
> index 000..a1d43ef
> --- /dev/null
> +++ b/drivers/baseband/acc100/rte_acc100_cfg.h
> @@ -0,0 +1,96 @@
> +/* SPDX-License-Identifier: BSD-3-Clause
> + * Copyright(c) 2020 Intel Corporation
> + */
> +
> +#ifndef _RTE_ACC100_CFG_H_
> +#define _RTE_ACC100_CFG_H_
> +
> +/**
> + * @file rte_acc100_cfg.h
> + *
> + * Functions for configuring ACC100 HW, exposed directly to applications.
> + * Configuration related to encoding/decoding is done through the
> + * librte_bbdev library.
> + *
> + * @warning
> + * @b EXPERIMENTAL: this API may change without prior notice
> + */
> +
> +#include
> +#include
> +
> +#ifdef __cplusplus
> +extern "C" {
> +#endif
> +/**< Number of Virtual Functions ACC100 supports */
> +#define RTE_ACC100_NUM_VFS 16
I was expecting the definition of RTE_ACC100_NUM_VFS to be removed.
And its uses replaced with ACC100_NUM_VFS.
or
#define RTE_ACC100_NUM_VFS ACC100_NUM_VFS
> +
> +/**
> + * Definition of Queue Topology for ACC100 Configuration
> + * Some level of details is abstracted out to expose a clean interface
> + * given that comprehensive flexibility is not required
> + */
> +struct rte_acc100_queue_topology {
> + /** Number of QGroups in incremental order of priority */
> + uint16_t num_qgroups;
> + /**
> + * All QGroups have the same number of AQs here.
> + * Note : Could be made a 16-array if more flexibility is really
> + * required
> + */
> + uint16_t num_aqs_per_groups;
> + /**
> + * Depth of the AQs is the same of all QGroups here. Log2 Enum : 2^N
> + * Note : Could be made a 16-array if more flexibility is really
> + * required
> + */
> + uint16_t aq_depth_log2;
> + /**
> + * Index of the first Queue Group Index - assuming contiguity
> + * Initialized as -1
> + */
> + int8_t first_qgroup_index;
> +};
> +
> +/**
> + * Definition of Arbitration related parameters for ACC100 Configuration
> + */
> +struct rte_acc100_arbitration {
> + /** Default Weight for VF Fairness Arbitration */
> + uint16_t round_robin_weight;
> + uint32_t gbr_threshold1; /**< Guaranteed Bitrate Threshold 1 */
> + uint32_t gbr_threshold2; /**< Guaranteed Bitrate Threshold 2 */
> +};
> +
> +/**
> + * Structure to pass ACC100 configuration.
> + * Note: all VF Bundles will have the same configuration.
> + */
> +struct rte_acc100_conf {
> + bool pf_mode_en; /**< 1 if PF is used for dataplane, 0 for VFs */
> + /** 1 if input '1' bit is represented by a positive LLR value, 0 if '1'
> + * bit is represented by a negative value.
> + */
> + bool input_pos_llr_1_bit;
> + /** 1 if output '1' bit is represented by a positive value, 0 if '1'
> + * bit is represented by a negative value.
> + */
> + bool output_pos_llr_1_bit;
> + uint16_t num_vf_bundles; /**< Number of VF bundles to setup */
> + /** Queue topology for each operation type */
> + struct rte_acc100_queue_topology q_ul_4g;
> + struct rte_acc100_queue_topology q_dl_4g;
> + struct rte_acc100_queue_topology q_ul_5g;
> + struct rte_acc100_queue_topology q_dl_5g;
> + /** Arbitration configuration for each operation type */
> + struct rte_acc100_arbitration arb_ul_4g[RTE_ACC100_NUM_VFS];
> + struct rte_acc100_arbitration arb_dl_4g[RTE_ACC100_NUM_VFS];
> + struct rte_acc100_arbitration arb_ul_5g[RTE_ACC100_NUM_VFS];
> + struct rte_acc100_arbitration arb_dl_5g[RTE_ACC100_NUM_VFS];
> +};
> +
> +#ifdef __cplusplus
> +}
> +#endif
> +
> +#endif /* _RTE_ACC100_CFG_H_ */
> diff --git a/drivers/baseband/acc100/rte_acc100_pmd.c
> b/drivers/baseband/acc100/rte_acc100_pmd.c
> index 1b4cd13..fcba77e 100644
> --- a/drivers/baseband/acc100/rte_acc100_pmd.c
> +++ b/drivers/baseband/acc100/r
Re: [dpdk-dev] [PATCH v11 04/10] baseband/acc100: add queue configuration
On 10/1/20 6:01 PM, Nicolas Chautru wrote:
> Adding function to create and configure queues for
> the device. Still no capability.
>
> Signed-off-by: Nicolas Chautru
> Reviewed-by: Rosen Xu
> Acked-by: Liu Tianjiao
> ---
> drivers/baseband/acc100/rte_acc100_pmd.c | 445
> ++-
> drivers/baseband/acc100/rte_acc100_pmd.h | 45
> 2 files changed, 488 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/baseband/acc100/rte_acc100_pmd.c
> b/drivers/baseband/acc100/rte_acc100_pmd.c
> index fcba77e..f2bf2b5 100644
> --- a/drivers/baseband/acc100/rte_acc100_pmd.c
> +++ b/drivers/baseband/acc100/rte_acc100_pmd.c
> @@ -26,6 +26,22 @@
> RTE_LOG_REGISTER(acc100_logtype, pmd.bb.acc100, NOTICE);
> #endif
>
> +/* Write to MMIO register address */
> +static inline void
> +mmio_write(void *addr, uint32_t value)
> +{
> + *((volatile uint32_t *)(addr)) = rte_cpu_to_le_32(value);
> +}
> +
> +/* Write a register of a ACC100 device */
> +static inline void
> +acc100_reg_write(struct acc100_device *d, uint32_t offset, uint32_t payload)
> +{
> + void *reg_addr = RTE_PTR_ADD(d->mmio_base, offset);
> + mmio_write(reg_addr, payload);
> + usleep(ACC100_LONG_WAIT);
> +}
> +
> /* Read a register of a ACC100 device */
> static inline uint32_t
> acc100_reg_read(struct acc100_device *d, uint32_t offset)
> @@ -36,6 +52,22 @@
> return rte_le_to_cpu_32(ret);
> }
>
> +/* Basic Implementation of Log2 for exact 2^N */
> +static inline uint32_t
> +log2_basic(uint32_t value)
> +{
> + return (value == 0) ? 0 : rte_bsf32(value);
> +}
> +
> +/* Calculate memory alignment offset assuming alignment is 2^N */
> +static inline uint32_t
> +calc_mem_alignment_offset(void *unaligned_virt_mem, uint32_t alignment)
> +{
> + rte_iova_t unaligned_phy_mem = rte_malloc_virt2iova(unaligned_virt_mem);
> + return (uint32_t)(alignment -
> + (unaligned_phy_mem & (alignment-1)));
> +}
> +
> /* Calculate the offset of the enqueue register */
> static inline uint32_t
> queue_offset(bool pf_device, uint8_t vf_id, uint8_t qgrp_id, uint16_t aq_id)
> @@ -208,10 +240,416 @@
> acc100_conf->q_dl_5g.aq_depth_log2);
> }
>
> -/* Free 64MB memory used for software rings */
> +static void
> +free_base_addresses(void **base_addrs, int size)
> +{
> + int i;
> + for (i = 0; i < size; i++)
> + rte_free(base_addrs[i]);
> +}
> +
> +static inline uint32_t
> +get_desc_len(void)
> +{
> + return sizeof(union acc100_dma_desc);
> +}
> +
> +/* Allocate the 2 * 64MB block for the sw rings */
> static int
> -acc100_dev_close(struct rte_bbdev *dev __rte_unused)
> +alloc_2x64mb_sw_rings_mem(struct rte_bbdev *dev, struct acc100_device *d,
> + int socket)
> {
> + uint32_t sw_ring_size = ACC100_SIZE_64MBYTE;
> + d->sw_rings_base = rte_zmalloc_socket(dev->device->driver->name,
> + 2 * sw_ring_size, RTE_CACHE_LINE_SIZE, socket);
> + if (d->sw_rings_base == NULL) {
> + rte_bbdev_log(ERR, "Failed to allocate memory for %s:%u",
> + dev->device->driver->name,
> + dev->data->dev_id);
> + return -ENOMEM;
> + }
> + uint32_t next_64mb_align_offset = calc_mem_alignment_offset(
> + d->sw_rings_base, ACC100_SIZE_64MBYTE);
> + d->sw_rings = RTE_PTR_ADD(d->sw_rings_base, next_64mb_align_offset);
> + d->sw_rings_iova = rte_malloc_virt2iova(d->sw_rings_base) +
> + next_64mb_align_offset;
> + d->sw_ring_size = ACC100_MAX_QUEUE_DEPTH * get_desc_len();
> + d->sw_ring_max_depth = ACC100_MAX_QUEUE_DEPTH;
> +
> + return 0;
> +}
> +
> +/* Attempt to allocate minimised memory space for sw rings */
> +static void
> +alloc_sw_rings_min_mem(struct rte_bbdev *dev, struct acc100_device *d,
> + uint16_t num_queues, int socket)
> +{
> + rte_iova_t sw_rings_base_iova, next_64mb_align_addr_iova;
> + uint32_t next_64mb_align_offset;
> + rte_iova_t sw_ring_iova_end_addr;
> + void *base_addrs[ACC100_SW_RING_MEM_ALLOC_ATTEMPTS];
> + void *sw_rings_base;
> + int i = 0;
> + uint32_t q_sw_ring_size = ACC100_MAX_QUEUE_DEPTH * get_desc_len();
> + uint32_t dev_sw_ring_size = q_sw_ring_size * num_queues;
> +
> + /* Find an aligned block of memory to store sw rings */
> + while (i < ACC100_SW_RING_MEM_ALLOC_ATTEMPTS) {
> + /*
> + * sw_ring allocated memory is guaranteed to be aligned to
> + * q_sw_ring_size at the condition that the requested size is
> + * less than the page size
> + */
> + sw_rings_base = rte_zmalloc_socket(
> + dev->device->driver->name,
> + dev_sw_ring_size, q_sw_ring_size, socket);
> +
> + if (sw_rings_base == NULL) {
> + rte_bbdev_log(ERR,
> +
Re: [dpdk-dev] [PATCH] maintainers: add self to baseband maintainers
On 10/5/20 9:26 AM, Chautru, Nicolas wrote: > Hey Tom, > Thanks for your recent reviews. > My only concern with this is how in reality you would be able to serve the > role of maintainer for these drivers/lib/test and engage in meaningful > discussions? > Do you understand 3GPP and the related processing and what these devices are > actually doing? Supporting them in linux and generic coding guide line review > is one thing, but maintainer would need broader understanding arguably. > I think you reviews are super valuable (dpdk coding guide lines, error > handling...) and I can make sure to include you generally for review for all > related contributions, I am just unsure whether in reality that corresponds > to what would be required to be a maintainer. > I am just thinking aloud here, let me know what you think I share your concern. I am interested in reviewing baseband changes. In the kernel this is handled by the R: Reviewer tag which was part of the original patch. When i submit kernel patches, i use the get_maintainter.pl script so i do not need to remember everyone interested. When i receive patches i look at just the cc,to's to figure out which project needs help. While you can create rules to look for strings in the subject line, it does not scale at all. I went this new route based on Thomas' feed back on my original change. Now with your feedback, is there a strong enough reason to accept my original change ? If not, well that's ok. Tom > Thanks > Nic > >> -Original Message- >> From: t...@redhat.com >> Sent: Monday, October 5, 2020 8:00 AM >> To: tho...@monjalon.net; Chautru, Nicolas >> Cc: dev@dpdk.org; Tom Rix >> Subject: [PATCH] maintainers: add self to baseband maintainers >> >> From: Tom Rix >> >> I am a Linux kernel Reviewer for the fpga n3000/vista creek which has >> several bitstream based baseband devices. So I want to help out here as >> well. >> >> Signed-off-by: Tom Rix >> --- >> MAINTAINERS | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/MAINTAINERS b/MAINTAINERS >> index c0abbe0fc..22e80580a 100644 >> --- a/MAINTAINERS >> +++ b/MAINTAINERS >> @@ -18,7 +18,6 @@ Descriptions of section entries: >> K: Keyword regex pattern to match content. >> One regex pattern per line. Multiple K: lines acceptable. >> >> - >> General Project Administration >> -- >> >> @@ -392,6 +391,7 @@ F: lib/librte_ethdev/rte_mtr* >> >> Baseband API - EXPERIMENTAL >> M: Nicolas Chautru >> +M: Tom Rix >> T: git://dpdk.org/next/dpdk-next-crypto >> F: lib/librte_bbdev/ >> F: doc/guides/prog_guide/bbdev.rst >> -- >> 2.18.1
Re: [dpdk-dev] [PATCH 0/2] baseband: fix segfault in Intel drivers
This change looks fine. Reviewed-by: Tom Rix In looking at the surrounding code i see the is-pf bool being found by checking the driver name. That is a fairly expensive check. Is there a better way to do that ? Tom On 10/6/20 3:04 AM, Maxime Coquelin wrote: > This series fixes segfaults in fpga_5gnr_fec and fpga_lte_fec > drivers when bbdev debug is enabled. > > Maxime Coquelin (2): > baseband/fpga_5gnr_fec: fix segfaults with debug > baseband/fpga_lte_fec: fix segfaults with debug > > drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c | 4 ++-- > drivers/baseband/fpga_lte_fec/fpga_lte_fec.c | 4 ++-- > 2 files changed, 4 insertions(+), 4 deletions(-) >
