[DPDK/ethdev Bug 1762] Unable to use TB-mode when code blocks have different length (ACC100 / VRB drivers)

[DPDK/ethdev Bug 1762] Unable to use TB-mode when code blocks have different length (ACC100 / VRB drivers)

[bugzilla]

[-- Attachment #1: Type: text/plain, Size: 3025 bytes --]

https://bugs.dpdk.org/show_bug.cgi?id=1762

            Bug ID: 1762
           Summary: Unable to use TB-mode when code blocks have different
                    length (ACC100 / VRB drivers)
           Product: DPDK
           Version: unspecified
          Hardware: All
                OS: All
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: ethdev
          Assignee: dev@dpdk.org
          Reporter: faust1002@gmail.com
  Target Milestone: ---

Created attachment 324
  --> https://bugs.dpdk.org/attachment.cgi?id=324&action=edit
Problem with AC100 / VRB1 drivers when using TB mode

Hello,
First of all, I hope I selected the problematic component correctly. I decided
to choose ethdev, because I found a different bug in the same piece of code
reported under the same category.

Going back to the problem - based on my understanding of bbdev documentation
(https://doc.dpdk.org/guides/prog_guide/bbdev.html), it is possible to
configure two different code block lengths (denoted as tb_params.ea and
tb_params.eb) in TB mode within one OP. In other words, to decode an entire TB,
instead of doing TB segmentation in SW and then allocating one OP per CB, I can
offload everything to HW by using only one OP per TB. So, for example, I can
configure OP as follows
code_block_mode = 0
tb_params.ea = 9056
tb_params.eb = 9088
tb_params.c = 23
tb_params.r = 0
tb_params.cab = 4
In other words, the first four CBs will be 9056 bits longs and the remaining 29
CBs will be 9088 bits long. Decoding will start with CB#0.

However, looking at the attached piece of code, it seems like fcw->rm_e is
configured only onces. Then the calculated value is used for all CBs,
regardless of their size provided as part of tb_params. As a result, decoding
fails. The entire code flow is as follows: vrb_enqueue_ldpc_dec (num set to 1
as we use only one OP per TB) -> vrb_enqueue_ldpc_dec_tb ->
vrb_enqueue_ldpc_dec_one_op_tb -> vrb_fcw_ld_fill (where fcw->rm_e is set) and
then for each end every CB vrb_dma_desc_ld_fill (where possibly incorrect
fcw->rm_e is used). I hope the problem description is clear. Please do not
hesitate to contact me if you have any further questions.

It seems like both LDPC encoding and decoding are impacted by this problem.
Furthermore, drivers for ACC100 and VRB1 are almost identical.

Not sure if the described problem is an actual bug or an undocumented feature.
I would not be surprised if ACC100 / VRB1 didn't support different CB lengths
in TB mode. However, this should have been clearly documented. Furthermore,
there are no examples of how to use TB mode, only examples for CB mode are
available. This needs to be addressed as well in my humble opinion.

The original implementation was done by Nicolas Chautru from Intel. So I
believe he should be the first point of contact here. 
Kind regards

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #2: Type: text/html, Size: 5194 bytes --]