-----Original Message-----
From: Nipun Gupta <redacted>
Sent: Friday, September 17, 2021 1:30 AM
To: Chautru, Nicolas <redacted>; dev@dpdk.org;
gakhil@marvell.com
Cc: david.marchand@redhat.com; Hemant Agrawal
[off-list ref]; Tom Rix [off-list ref]
Subject: RE: [PATCH v5 1/9] bbdev: add big endian processing data capability

quoted

-----Original Message-----
From: Chautru, Nicolas <redacted>
Sent: Tuesday, September 14, 2021 12:10 AM
To: Nipun Gupta <redacted>; dev@dpdk.org;
gakhil@marvell.com
Cc: david.marchand@redhat.com; Hemant Agrawal
[off-list ref]; Tom Rix [off-list ref]
Subject: RE: [PATCH v5 1/9] bbdev: add big endian processing data
capability

quoted

-----Original Message-----
From: Nipun Gupta <redacted>
Sent: Sunday, September 12, 2021 5:15 AM
To: dev@dpdk.org; gakhil@marvell.com; Chautru, Nicolas
[off-list ref]
Cc: david.marchand@redhat.com; hemant.agrawal@nxp.com; Nipun

Gupta

quoted

quoted

[off-list ref]
Subject: [PATCH v5 1/9] bbdev: add big endian processing data
capability

This patch intoduces a new capability of the bbdev device to process
the LDPC data in big endian order.

Hi Gupta,

As mentioned in previous patch iteration earlier this year I believe
this is not really an operation flag but more a different device capability.
ie. you would have the same formalism for all operation (5GDL, 5GUL,
4GDL, ...) for that PMD/hw and that is not something you will change
dynamically as an option.
I would suggest to add this under "struct rte_bbdev_driver_info" which
can be used to capture device specific capability and information. In
term of processing and operation, everything is the same except
endianness assumption for the input/output data.

Okay, it can be done this way. Then it would be assumption of the driver,
that the operation is in the format as per the driver info. Ill change it in
respin.

Yes the fact that the capability is exposed out means that this is the responsibility of the application to provide input data in that format (ie. similar as for llr numerical representation).
The endianness switch can be done in bbdev-test so that all existing vectors can be run seamlessly even on your PMD (ie. different endianness than the default one so far).

quoted

quoted

Signed-off-by: Hemant Agrawal <redacted>
Signed-off-by: Nipun Gupta <redacted>
---
 doc/guides/bbdevs/features/default.ini |  1 +
 doc/guides/prog_guide/bbdev.rst        |  6 ++++++
 lib/bbdev/rte_bbdev_op.h               | 14 ++++++++++++--
 3 files changed, 19 insertions(+), 2 deletions(-)

diff --git a/doc/guides/bbdevs/features/default.ini

b/doc/guides/bbdevs/features/default.ini
index 5fe267a625..ae5aacf8f7 100644

--- a/doc/guides/bbdevs/features/default.ini
+++ b/doc/guides/bbdevs/features/default.ini

@@ -14,3 +14,4 @@ LLR/HARQ Compression   =
 External DDR Access    =
 HW Accelerated         =
 BBDEV API              =
+Big Endian Processing  =

diff --git a/doc/guides/prog_guide/bbdev.rst

b/doc/guides/prog_guide/bbdev.rst index 9619280ffc..6540b514bb
100644

--- a/doc/guides/prog_guide/bbdev.rst
+++ b/doc/guides/prog_guide/bbdev.rst

@@ -747,6 +747,9 @@ given below.
 |RTE_BBDEV_LDPC_ENC_CONCATENATION                                    |
 | Set if a device supports concatenation of non byte aligned output

|  +------
--------------------------------------------------------------+
+|RTE_BBDEV_LDPC_ENC_BIG_ENDIAN                                       |
+| Set if a device supports Big Endian data processing                |
++--------------------------------------------------------------------+

 The structure passed for each LDPC encode operation is given below,
with the operation flags forming a bitmask in the ``op_flags`` field.

@@ -942,6 +945,9 @@ given below.
 |RTE_BBDEV_LDPC_INTERNAL_HARQ_MEMORY_LOOPBACK

|

quoted

quoted

 | Set if a device supports loopback access to HARQ internal memory   |

+-------------------------------------------------------------------
-+
+|RTE_BBDEV_LDPC_DEC_BIG_ENDIAN                                       |
+| Set if a device supports Big Endian data processing                |
++--------------------------------------------------------------------+

 The structure passed for each LDPC decode operation is given below,
with the operation flags forming a bitmask in the ``op_flags`` field.

diff --git a/lib/bbdev/rte_bbdev_op.h b/lib/bbdev/rte_bbdev_op.h
index f946842727..9e9b5be81f 100644
--- a/lib/bbdev/rte_bbdev_op.h
+++ b/lib/bbdev/rte_bbdev_op.h

@@ -186,7 +186,12 @@ enum rte_bbdev_op_ldpcdec_flag_bitmasks {
 	 *  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 <<
18),
+	/** Set if a device supports Big Endian data processing.
+	 *  If not set Little Endian data processing is supported by
+	 *  default.
+	 */
+	RTE_BBDEV_LDPC_DEC_BIG_ENDIAN = (1ULL << 8)
 };

 /** Flags for LDPC encoder operation and capability structure */ @@
-206,7
+211,12 @@ enum rte_bbdev_op_ldpcenc_flag_bitmasks {
 	/** Set if a device supports scatter-gather functionality. */
 	RTE_BBDEV_LDPC_ENC_SCATTER_GATHER = (1ULL << 6),
 	/** Set if a device supports concatenation of non byte aligned
output */
-	RTE_BBDEV_LDPC_ENC_CONCATENATION = (1ULL << 7)
+	RTE_BBDEV_LDPC_ENC_CONCATENATION = (1ULL << 7),
+	/** Set if a device supports Big Endian data processing
+	 *  If not set Little Endian data processing is supported by
+	 *  default.
+	 */
+	RTE_BBDEV_LDPC_ENC_BIG_ENDIAN = (1ULL << 8)
 };

 /** Flags for the Code Block/Transport block mode  */
--
2.17.1