From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 57A83A0542; Fri, 4 Nov 2022 12:35:10 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id E24A742D12; Fri, 4 Nov 2022 12:35:09 +0100 (CET) Received: from mail-qt1-f176.google.com (mail-qt1-f176.google.com [209.85.160.176]) by mails.dpdk.org (Postfix) with ESMTP id 045E942D10 for ; Fri, 4 Nov 2022 12:35:08 +0100 (CET) Received: by mail-qt1-f176.google.com with SMTP id l2so2811526qtq.11 for ; Fri, 04 Nov 2022 04:35:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=atomicrules-com.20210112.gappssmtp.com; s=20210112; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=40SQ19DfusdWLhByKkJIG5LakJ/mH/Yu0I7FpGuxyHw=; b=3tC+07bSn6t0ic5CTvuGRfLWycrxruua07vLo6wHb7wzf2mZcJ0TmCivWX9AYu6mDH arHDlEwZa+8Zi3xb7zI/6DmIfcCR8iyr9aPbVeQ4NYOVwXus4VmrbiTFm3z/HaSlwc9o A51EtmDX04wWFDiFAaGFcFjQmBj07dHvlM+nwMr5J7H5Ft7pR6O69I1XWFLqvUXcqtlc Epu5C46brUqQDSzQmCDx24TOJrVZAEtdMWsn62sNg79afjQ3U/+jBd/fR4HzV4gaokfe R8VwH7saNq8gcKYhEIWxkqNsPZYQvf93LYE9XEb8T7CxHnEo2yAb6NGM2GVw20sd7J1U DNvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=40SQ19DfusdWLhByKkJIG5LakJ/mH/Yu0I7FpGuxyHw=; b=NQrc+UyhFL4Uw8Bz9DciXPrvKsJAPqFJFOOWx0nVJn6cfjr7c6+VC2H9I593P9BNmg CgVoZc9UIYQIROVkczyofDm4AyZUX64s8DMCfq1/eb0fM8gcfdFJE9g5/hMwoT+bRHz4 74t7+be/BUZjODLjhJ5VO7xsUSrRu+2PpERbtC3kCjffZvq50JnQTCeL/4JmwpANuyaz fDHNxUEnvJaT5pgmIboleI8UvPfO1+HGajXFRl9rzqIe16dvDaxYIdx+Oedn0UqoQytP vhT87wrwqYR7MWQJkoNHCDK2UDn+shg5laqcpr7xW5xTqPpxDfd25gw8yr9y7DeliEt1 cOXA== X-Gm-Message-State: ACrzQf3t3vbwAQqNGrtjT0raX5zfhT1ovYjcW7AvDZiyzdjZNP60PWQ3 3WWuO9QqckFAhEnC2KMIIkxXQg== X-Google-Smtp-Source: AMsMyM6mMLs9AXT1jhOyhqJ184EqN/aqZ+AGoPFb8wLNZPjG6YKrBXrfjOjXV64fYpTjBihG5AGWUQ== X-Received: by 2002:ac8:6ecf:0:b0:3a5:226e:29e2 with SMTP id f15-20020ac86ecf000000b003a5226e29e2mr22747827qtv.641.1667561707348; Fri, 04 Nov 2022 04:35:07 -0700 (PDT) Received: from smtpclient.apple (h64-35-205-155.cntcnh.broadband.dynamic.tds.net. [64.35.205.155]) by smtp.gmail.com with ESMTPSA id f21-20020ac87f15000000b003a5430ee366sm2335980qtk.60.2022.11.04.04.35.06 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Nov 2022 04:35:06 -0700 (PDT) From: John Miller Message-Id: <6A2FEB4C-95FC-43D8-88C1-3CDBFA4E3CA7@atomicrules.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_8DFF329A-3E2F-4B98-970A-834D2AD42323" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) Subject: Re: [PATCH 11/14] baseband/ark: introduce ark baseband driver custom functions Date: Fri, 4 Nov 2022 07:35:05 -0400 In-Reply-To: Cc: "dev@dpdk.org" , "ed.czeck@atomicrules.com" , Shepard Siegel , Maxime Coquelin To: "Chautru, Nicolas" References: <20221026194613.1008232-1-john.miller@atomicrules.com> <20221026194613.1008232-11-john.miller@atomicrules.com> X-Mailer: Apple Mail (2.3696.120.41.1.1) X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org --Apple-Mail=_8DFF329A-3E2F-4B98-970A-834D2AD42323 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Nicolas, I spoke with the code author and this file was not intended to be = upstreamed. It will be removed in V2. -John > On Oct 26, 2022, at 7:22 PM, Chautru, Nicolas = wrote: >=20 > Hi John,=20 >=20 >> -----Original Message----- >> From: John Miller > >> Sent: Wednesday, October 26, 2022 12:46 PM >> To: Chautru, Nicolas > >> Cc: dev@dpdk.org ; ed.czeck@atomicrules.com = ; Shepard Siegel >> >; John Miller >> > >> Subject: [PATCH 11/14] baseband/ark: introduce ark baseband driver = custom >> functions >>=20 >> This patch introduces the Arkville baseband device driver custom = functions. >>=20 >> Signed-off-by: John Miller >> --- >> drivers/baseband/ark/ark_bbdev_custom.c | 201 = ++++++++++++++++++++++++ >> drivers/baseband/ark/ark_bbdev_custom.h | 30 ++++ >> 2 files changed, 231 insertions(+) >> create mode 100644 drivers/baseband/ark/ark_bbdev_custom.c >> create mode 100644 drivers/baseband/ark/ark_bbdev_custom.h >>=20 >> diff --git a/drivers/baseband/ark/ark_bbdev_custom.c >> b/drivers/baseband/ark/ark_bbdev_custom.c >> new file mode 100644 >> index 0000000000..6b1553abe1 >> --- /dev/null >> +++ b/drivers/baseband/ark/ark_bbdev_custom.c >> @@ -0,0 +1,201 @@ >> +/* SPDX-License-Identifier: BSD-3-Clause >> + * Copyright(c) 2016-2021 Atomic Rules LLC */ >> + >> +#include >> +#include >> + >> +#include >> +#include /* For debug */ >> + >> + >> +#include "ark_bbdev_common.h" >> +#include "ark_bbdev_custom.h" >> + >> +/* It is expected that functions in this file will be modified based = on >> + * specifics of the FPGA hardware beyond the core Arkville >> + * components. >> + */ >> + >> +/* bytyes must be range of 0 to 20 */ >> +static inline >> +uint8_t ark_bb_cvt_bytes_meta_cnt(size_t bytes) { >> + return (bytes + 3) / 8; >> +} >> + >> +void >> +ark_bbdev_info_get(struct rte_bbdev *dev, >> + struct rte_bbdev_driver_info *dev_info) { >> + struct ark_bbdevice *ark_bb =3D dev->data->dev_private; >> + >=20 > In your documentation in first commit you mentioned this > * Support for LDPC encode and decode operations. > * Support for Turbo encode and decode operations. > But I only see LDPC below. More generally not really matching the doc = I think. Good to have the code and docs in same commits for that reason.=20= >=20 >> + static const struct rte_bbdev_op_cap bbdev_capabilities[] =3D { >> + { >> + .type =3D RTE_BBDEV_OP_LDPC_DEC, >> + .cap.ldpc_dec =3D { >> + .capability_flags =3D >> + RTE_BBDEV_LDPC_CRC_24B_ATTACH >> | >> + RTE_BBDEV_LDPC_RATE_MATCH, >=20 > It doesn't look right > Basically there se flags are not for LDPC_DEC but for the encoder > There is no HARQ combine etc? > I would have expected scatter gather here as well based on your = documentation >=20 >> + .num_buffers_src =3D >> + >> RTE_BBDEV_LDPC_MAX_CODE_BLOCKS, >> + .num_buffers_hard_out =3D >> + >> RTE_BBDEV_LDPC_MAX_CODE_BLOCKS >> + } >> + }, >> + { >> + .type =3D RTE_BBDEV_OP_LDPC_ENC, >> + .cap.ldpc_enc =3D { >> + .capability_flags =3D >> + RTE_BBDEV_LDPC_CRC_24B_ATTACH >> | >> + RTE_BBDEV_LDPC_RATE_MATCH, >> + .num_buffers_src =3D >> + >> RTE_BBDEV_LDPC_MAX_CODE_BLOCKS, >> + .num_buffers_dst =3D >> + >> RTE_BBDEV_LDPC_MAX_CODE_BLOCKS >> + } >> + }, >> + RTE_BBDEV_END_OF_CAPABILITIES_LIST(), >> + }; >> + >> + static struct rte_bbdev_queue_conf default_queue_conf =3D { >> + .queue_size =3D RTE_BBDEV_QUEUE_SIZE_LIMIT, >> + }; >> + >> + default_queue_conf.socket =3D dev->data->socket_id; >> + >> + dev_info->driver_name =3D RTE_STR(DRIVER_NAME); >> + dev_info->max_num_queues =3D ark_bb->max_nb_queues; >> + dev_info->queue_size_lim =3D RTE_BBDEV_QUEUE_SIZE_LIMIT; >> + dev_info->hardware_accelerated =3D true; >> + dev_info->max_dl_queue_priority =3D 0; >> + dev_info->max_ul_queue_priority =3D 0; >> + dev_info->default_queue_conf =3D default_queue_conf; >> + dev_info->capabilities =3D bbdev_capabilities; >> + dev_info->cpu_flag_reqs =3D NULL; >> + dev_info->min_alignment =3D 4; >=20 > Is there really a 4 Bytes alignment requirement per code blocks? That = sounds extremely cumbersome, is that what you really mean? >=20 >> + >> +} >> + >> +/* Structure defining layout of the ldpc command struct */ struct >> +ark_bb_ldpc_enc_meta { >> + uint16_t header; >> + uint8_t rv_index:2, >> + basegraph:1, >> + code_block_mode:1, >> + rfu_71_68:4; >=20 > What is this? Just curious.=20 >=20 >> + >> + uint8_t q_m; >> + uint32_t e_ea; >> + uint32_t eb; >> + uint8_t c; >> + uint8_t cab; >> + uint16_t n_cb; >> + uint16_t pad; >> + uint16_t trailer; >> +} __rte_packed; >> + >> +/* The size must be less then 20 Bytes */ = static_assert(sizeof(struct >> +ark_bb_ldpc_enc_meta) <=3D 20, "struct size"); >> + >> +/* Custom operation on equeue ldpc operation */ >=20 > Typo enqueue >=20 >> +/* Do these function need queue number? */ >=20 > Who is the question for? Through bbdev api the queue index is = expected, and from your documentation I believe you support multiple = queues.=20 >=20 >> +/* Maximum of 20 bytes */ >> +int >> +ark_bb_user_enqueue_ldpc_enc(struct rte_bbdev_enc_op *enc_op, >> + uint32_t *meta, uint8_t *meta_cnt) { >> + struct rte_bbdev_op_ldpc_enc *ldpc_enc_op =3D &enc_op->ldpc_enc; >> + struct ark_bb_ldpc_enc_meta *src =3D (struct = ark_bb_ldpc_enc_meta >> +*)meta; >> + >> + src->header =3D 0x4321; /* For testings */ >> + src->trailer =3D 0xFEDC; >> + >> + src->rv_index =3D ldpc_enc_op->rv_index; >> + src->basegraph =3D ldpc_enc_op->basegraph; >> + src->code_block_mode =3D ldpc_enc_op->code_block_mode; >> + >> + src->q_m =3D ldpc_enc_op->q_m; >> + src->e_ea =3D 0xABCD; >> + src->eb =3D ldpc_enc_op->tb_params.eb; >> + src->c =3D ldpc_enc_op->tb_params.c; >> + src->cab =3D ldpc_enc_op->tb_params.cab; >> + >> + src->n_cb =3D 0; >> + >> + meta[0] =3D 0x11111110; >> + meta[1] =3D 0x22222220; >> + meta[2] =3D 0x33333330; >> + meta[3] =3D 0x44444440; >> + meta[4] =3D 0x55555550; >=20 > Should these be defined separately? >=20 >> + >> + *meta_cnt =3D ark_bb_cvt_bytes_meta_cnt( >> + sizeof(struct ark_bb_ldpc_enc_meta)); >> + return 0; >> +} >> + >> +/* Custom operation on dequeue ldpc operation */ int >> +ark_bb_user_dequeue_ldpc_enc(struct rte_bbdev_enc_op *enc_op, >> + const uint32_t *usermeta) >> +{ >> + static int dump; /* =3D 0 */ >> + /* Just compare with what was sent? */ >> + uint32_t meta_in[5] =3D {0}; >> + uint8_t meta_cnt; >> + >> + ark_bb_user_enqueue_ldpc_enc(enc_op, meta_in, &meta_cnt); >> + if (memcmp(usermeta, meta_in, 3 + (meta_cnt * 8))) { >> + fprintf(stderr, >> + "------------------------------------------\n"); >> + rte_hexdump(stdout, "meta difference for lpdc_enc IN", >> + meta_in, 20); >> + rte_hexdump(stdout, "meta difference for lpdc_enc OUT", >> + usermeta, 20); >> + } else if (dump) { >> + rte_hexdump(stdout, "DUMP lpdc_enc IN", usermeta, 20); >> + dump--; >> + } >> + >> + return 0; >> +} >> + >> + >> +/* Turbo op call backs for user meta data */ int >> +ark_bb_user_enqueue_ldpc_dec(struct rte_bbdev_dec_op *enc_op, >> + uint32_t *meta, uint8_t *meta_cnt) { >> + RTE_SET_USED(enc_op); >=20 > Is the implementation missing? >=20 > The enc_op should be called differently.=20 >=20 >> + meta[0] =3D 0xF1111110; >> + meta[1] =3D 0xF2222220; >> + meta[2] =3D 0xF3333330; >> + meta[3] =3D 0xF4444440; >> + meta[4] =3D 0xF5555550; >> + >> + *meta_cnt =3D ark_bb_cvt_bytes_meta_cnt(20); >> + return 0; >> +} >> + >> +int ark_bb_user_dequeue_ldpc_dec(struct rte_bbdev_dec_op *enc_op, >> + const uint32_t *usermeta) >> +{ >> + RTE_SET_USED(enc_op); >> + static int dump; /* =3D 0 */ >> + /* Just compare with what was sent? */ >=20 > That looks like still testcode isn't it? Doing some loopback.=20 >=20 >> + uint32_t meta_in[5] =3D {0}; >> + uint8_t meta_cnt; >> + >> + ark_bb_user_enqueue_ldpc_dec(enc_op, meta_in, &meta_cnt); >> + if (memcmp(usermeta, meta_in, 3 + (meta_cnt * 8))) { >> + fprintf(stderr, >> + "------------------------------------------\n"); >> + rte_hexdump(stdout, "meta difference for lpdc_enc IN", >> + meta_in, 20); >> + rte_hexdump(stdout, "meta difference for lpdc_enc OUT", >> + usermeta, 20); >> + } else if (dump) { >> + rte_hexdump(stdout, "DUMP lpdc_enc IN", usermeta, 20); >> + dump--; >> + } >> + return 0; >> +} >> diff --git a/drivers/baseband/ark/ark_bbdev_custom.h >> b/drivers/baseband/ark/ark_bbdev_custom.h >> new file mode 100644 >> index 0000000000..32a2ef6bb6 >> --- /dev/null >> +++ b/drivers/baseband/ark/ark_bbdev_custom.h >> @@ -0,0 +1,30 @@ >> +/* SPDX-License-Identifier: BSD-3-Clause >> + * Copyright(c) 2016-2021 Atomic Rules LLC */ >> + >> +#ifndef _ARK_BBDEV_CUSTOM_H_ >> +#define _ARK_BBDEV_CUSTOM_H_ >> + >> +#include >> + >> +/* Forward declarations */ >> +struct rte_bbdev; >> +struct rte_bbdev_driver_info; >> +struct rte_bbdev_enc_op; >> +struct rte_bbdev_dec_op; >> +struct rte_mbuf; >> + >> +void ark_bbdev_info_get(struct rte_bbdev *dev, >> + struct rte_bbdev_driver_info *dev_info); >> + >> +int ark_bb_user_enqueue_ldpc_dec(struct rte_bbdev_dec_op *enc_op, >> + uint32_t *meta, uint8_t *meta_cnt); int >> +ark_bb_user_dequeue_ldpc_dec(struct rte_bbdev_dec_op *enc_op, >> + const uint32_t *usermeta); >> + >> +int ark_bb_user_enqueue_ldpc_enc(struct rte_bbdev_enc_op *enc_op, >> + uint32_t *meta, uint8_t *meta_cnt); int >> +ark_bb_user_dequeue_ldpc_enc(struct rte_bbdev_enc_op *enc_op, >> + const uint32_t *usermeta); >> + >> +#endif >> -- >> 2.25.1 --Apple-Mail=_8DFF329A-3E2F-4B98-970A-834D2AD42323 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Nicolas,

I spoke = with the code author and this file was not intended to be upstreamed. It = will be removed in V2.

-John


On Oct = 26, 2022, at 7:22 PM, Chautru, Nicolas <nicolas.chautru@intel.com> wrote:

Hi John, 

-----Original Message-----
From: John Miller = <john.miller@atomicrules.com>
Sent: = Wednesday, October 26, 2022 12:46 PM
To: Chautru, Nicolas = <nicolas.chautru@intel.com>
Cc: dev@dpdk.org; ed.czeck@atomicrules.com; Shepard Siegel
<shepard.siegel@atomicrules.com>; John Miller
<john.miller@atomicrules.com>
Subject: = [PATCH 11/14] baseband/ark: introduce ark baseband driver custom
functions

This patch introduces = the Arkville baseband device driver custom functions.

Signed-off-by: John Miller <john.miller@atomicrules.com>
---
drivers/baseband/ark/ark_bbdev_custom.c | 201 = ++++++++++++++++++++++++
drivers/baseband/ark/ark_bbdev_custom.h |  30 ++++
2 files changed, 231 insertions(+)
create mode = 100644 drivers/baseband/ark/ark_bbdev_custom.c
create mode = 100644 drivers/baseband/ark/ark_bbdev_custom.h

diff --git a/drivers/baseband/ark/ark_bbdev_custom.c
b/drivers/baseband/ark/ark_bbdev_custom.c
new = file mode 100644
index 0000000000..6b1553abe1
--- /dev/null
+++ = b/drivers/baseband/ark/ark_bbdev_custom.c
@@ -0,0 +1,201 = @@
+/* SPDX-License-Identifier: BSD-3-Clause
+= * Copyright(c) 2016-2021 Atomic Rules LLC  */
+
+#include <rte_bbdev.h>
+#include = <rte_bbdev_pmd.h>
+
+#include = <rte_mbuf.h>
+#include <rte_hexdump.h> /* For = debug */
+
+
+#include = "ark_bbdev_common.h"
+#include "ark_bbdev_custom.h"
+
+/* It is expected that functions in this = file will be modified based on
+ * specifics of the FPGA = hardware beyond the core Arkville
+ * components.
+ */
+
+/* bytyes must be range = of 0 to 20 */
+static inline
+uint8_t = ark_bb_cvt_bytes_meta_cnt(size_t bytes) {
+ return = (bytes + 3) / 8;
+}
+
+void
+ark_bbdev_info_get(struct rte_bbdev *dev,
+    struct = rte_bbdev_driver_info *dev_info) {
+ struct = ark_bbdevice *ark_bb =3D  dev->data->dev_private;
+

In your documentation in first commit you mentioned = this
* Support for = LDPC encode and decode operations.
* Support for Turbo encode and decode operations.
But I only see LDPC below. More = generally not really matching the doc I think. Good to have the code and = docs in same commits for that reason. 

+ static = const struct rte_bbdev_op_cap bbdev_capabilities[] =3D {
+ = = {
+ .type =3D = RTE_BBDEV_OP_LDPC_DEC,
+ .cap.ldpc_dec =3D {
+ = = = = .capability_flags =3D
+ RTE_BBDEV_LDPC_CRC_24B_ATTACH
|
+ RTE_BBDEV_LDPC_RATE_MATCH,

It doesn't look right
Basically there se flags are not for LDPC_DEC but for the = encoder
There is no = HARQ combine etc?
I would have expected scatter gather here as well based on = your documentation

+ .num_buffers_src =3D
+
= RTE_BBDEV_LDPC_MAX_CODE_BLOCKS,
+ = .num_buffers_hard_out =3D
+
= RTE_BBDEV_LDPC_MAX_CODE_BLOCKS
+ }
+ = = },
+ {
+ .type =3D = RTE_BBDEV_OP_LDPC_ENC,
+ .cap.ldpc_enc =3D {
+ = = = = .capability_flags =3D
+ RTE_BBDEV_LDPC_CRC_24B_ATTACH
|
+ RTE_BBDEV_LDPC_RATE_MATCH,
+ = = = = .num_buffers_src =3D
+
= RTE_BBDEV_LDPC_MAX_CODE_BLOCKS,
+ = .num_buffers_dst =3D
+
= RTE_BBDEV_LDPC_MAX_CODE_BLOCKS
+ }
+ = = },
+ = RTE_BBDEV_END_OF_CAPABILITIES_LIST(),
+ };
+
+ static struct = rte_bbdev_queue_conf default_queue_conf =3D {
+ = .queue_size =3D RTE_BBDEV_QUEUE_SIZE_LIMIT,
+ };
+
+ default_queue_conf.socket =3D = dev->data->socket_id;
+
+ = dev_info->driver_name =3D RTE_STR(DRIVER_NAME);
+ = dev_info->max_num_queues =3D ark_bb->max_nb_queues;
+ = dev_info->queue_size_lim =3D RTE_BBDEV_QUEUE_SIZE_LIMIT;
+ = dev_info->hardware_accelerated =3D true;
+ = dev_info->max_dl_queue_priority =3D 0;
+ = dev_info->max_ul_queue_priority =3D 0;
+ = dev_info->default_queue_conf =3D default_queue_conf;
+ = dev_info->capabilities =3D bbdev_capabilities;
+ = dev_info->cpu_flag_reqs =3D NULL;
+ = dev_info->min_alignment =3D 4;

Is there really a 4 Bytes = alignment requirement per code blocks? That sounds extremely cumbersome, = is that what you really mean?

+
+}
+
+/* Structure defining layout of the ldpc command struct */ = struct
+ark_bb_ldpc_enc_meta {
+ uint16_t = header;
+ uint8_t rv_index:2,
+ = = basegraph:1,
+ code_block_mode:1,
+ = = rfu_71_68:4;

What is this? Just curious. 

+
+ = uint8_t q_m;
+ uint32_t e_ea;
+ uint32_t = eb;
+ uint8_t c;
+ uint8_t cab;
+ uint16_t = n_cb;
+ uint16_t pad;
+ uint16_t trailer;
+} = __rte_packed;
+
+/* The size must be less = then 20 Bytes */ static_assert(sizeof(struct
+ark_bb_ldpc_enc_meta) <=3D 20, "struct size");
+
+/* Custom operation on equeue ldpc operation =  */

Typo enqueue

+/* Do these function need queue = number? */

Who is the question for? Through bbdev api the queue index is = expected, and from your documentation I believe you support multiple = queues. 

+/* = Maximum of 20 bytes */
+int
+ark_bb_user_enqueue_ldpc_enc(struct rte_bbdev_enc_op = *enc_op,
+   uint32_t *meta, = uint8_t *meta_cnt) {
+ struct rte_bbdev_op_ldpc_enc = *ldpc_enc_op =3D &enc_op->ldpc_enc;
+ struct = ark_bb_ldpc_enc_meta *src =3D (struct ark_bb_ldpc_enc_meta
+*)meta;
+
+ = src->header =3D 0x4321; /* For testings */
+ = src->trailer =3D 0xFEDC;
+
+ = src->rv_index =3D ldpc_enc_op->rv_index;
+ = src->basegraph =3D ldpc_enc_op->basegraph;
+ = src->code_block_mode =3D ldpc_enc_op->code_block_mode;
+
+ src->q_m =3D = ldpc_enc_op->q_m;
+ src->e_ea =3D 0xABCD;
+ = src->eb =3D ldpc_enc_op->tb_params.eb;
+ src->c = =3D ldpc_enc_op->tb_params.c;
+ = src->cab =3D ldpc_enc_op->tb_params.cab;
+
+ = src->n_cb =3D 0;
+
+ meta[0] =3D= 0x11111110;
+ meta[1] =3D 0x22222220;
+ = meta[2] =3D 0x33333330;
+ meta[3] =3D= 0x44444440;
+ meta[4] =3D 0x55555550;

Should these be defined separately?

+
+ = *meta_cnt =3D ark_bb_cvt_bytes_meta_cnt(
+ = sizeof(struct ark_bb_ldpc_enc_meta));
+ return = 0;
+}
+
+/* Custom operation = on dequeue ldpc operation  */ int
+ark_bb_user_dequeue_ldpc_enc(struct rte_bbdev_enc_op = *enc_op,
+      const= uint32_t *usermeta)
+{
+ static = int dump; = /* =3D 0 */
+ /* Just compare with what was = sent? */
+ uint32_t meta_in[5] =3D {0};
+ = uint8_t  meta_cnt;
+
+ = ark_bb_user_enqueue_ldpc_enc(enc_op, meta_in, &meta_cnt);
+ = if (memcmp(usermeta, meta_in, 3 + (meta_cnt * 8))) {
+ = = fprintf(stderr,
+ = "------------------------------------------\n");
+ = = rte_hexdump(stdout, "meta difference for lpdc_enc IN",
+ = = =     meta_in, = 20);
+ rte_hexdump(stdout, "meta difference for lpdc_enc = OUT",
+     usermeta, = 20);
+ } else if (dump) {
+ = rte_hexdump(stdout, "DUMP lpdc_enc IN", usermeta, 20);
+ = = dump--;
+ }
+
+ = return 0;
+}
+
+
+/* Turbo op call backs for user meta data */ int
+ark_bb_user_enqueue_ldpc_dec(struct rte_bbdev_dec_op = *enc_op,
+  uint32_t *meta, uint8_t = *meta_cnt) {
+ RTE_SET_USED(enc_op);

Is the implementation missing?

The enc_op should be called differently. 

+ meta[0] =3D= 0xF1111110;
+ meta[1] =3D 0xF2222220;
+ = meta[2] =3D 0xF3333330;
+ meta[3] =3D= 0xF4444440;
+ meta[4] =3D 0xF5555550;
+
+ *meta_cnt =3D = ark_bb_cvt_bytes_meta_cnt(20);
+ return = 0;
+}
+
+int = ark_bb_user_dequeue_ldpc_dec(struct rte_bbdev_dec_op *enc_op,
+ = = = =  const uint32_t = *usermeta)
+{
+ RTE_SET_USED(enc_op);
+ = static int dump; /* =3D 0 */
+ /* Just = compare with what was sent? */

That looks like still testcode = isn't it? Doing some loopback. 

+ uint32_t = meta_in[5] =3D {0};
+ uint8_t  meta_cnt;
+
+ = ark_bb_user_enqueue_ldpc_dec(enc_op, meta_in, &meta_cnt);
+ = if (memcmp(usermeta, meta_in, 3 + (meta_cnt * 8))) {
+ = = fprintf(stderr,
+ = "------------------------------------------\n");
+ = = rte_hexdump(stdout, "meta difference for lpdc_enc IN",
+ = = =     meta_in, = 20);
+ rte_hexdump(stdout, "meta difference for lpdc_enc = OUT",
+     usermeta, = 20);
+ } else if (dump) {
+ = rte_hexdump(stdout, "DUMP lpdc_enc IN", usermeta, 20);
+ = = dump--;
+ }
+ return = 0;
+}
diff --git = a/drivers/baseband/ark/ark_bbdev_custom.h
b/drivers/baseband/ark/ark_bbdev_custom.h
new = file mode 100644
index 0000000000..32a2ef6bb6
--- /dev/null
+++ = b/drivers/baseband/ark/ark_bbdev_custom.h
@@ -0,0 +1,30 = @@
+/* SPDX-License-Identifier: BSD-3-Clause
+= * Copyright(c) 2016-2021 Atomic Rules LLC  */
+
+#ifndef _ARK_BBDEV_CUSTOM_H_
+#define = _ARK_BBDEV_CUSTOM_H_
+
+#include = <stdint.h>
+
+/* Forward declarations = */
+struct rte_bbdev;
+struct = rte_bbdev_driver_info;
+struct rte_bbdev_enc_op;
+struct rte_bbdev_dec_op;
+struct rte_mbuf;
+
+void ark_bbdev_info_get(struct rte_bbdev = *dev,
+ struct rte_bbdev_driver_info *dev_info);
++int ark_bb_user_enqueue_ldpc_dec(struct rte_bbdev_dec_op = *enc_op,
+  uint32_t *meta, uint8_t = *meta_cnt); int
+ark_bb_user_dequeue_ldpc_dec(struct = rte_bbdev_dec_op *enc_op,
+  const uint32_t = *usermeta);
+
+int = ark_bb_user_enqueue_ldpc_enc(struct rte_bbdev_enc_op *enc_op,
+ = = = =  uint32_t = *meta, uint8_t *meta_cnt); int
+ark_bb_user_dequeue_ldpc_enc(struct rte_bbdev_enc_op = *enc_op,
+  const uint32_t = *usermeta);
+
+#endif
--
2.25.1

= --Apple-Mail=_8DFF329A-3E2F-4B98-970A-834D2AD42323--