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 DBFD446C56; Wed, 30 Jul 2025 21:18:27 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 7A1B04026A; Wed, 30 Jul 2025 21:18:27 +0200 (CEST) Received: from inbox.dpdk.org (inbox.dpdk.org [95.142.172.178]) by mails.dpdk.org (Postfix) with ESMTP id 8C6484025A for ; Wed, 30 Jul 2025 21:18:26 +0200 (CEST) Received: by inbox.dpdk.org (Postfix, from userid 33) id 658B146C57; Wed, 30 Jul 2025 21:18:26 +0200 (CEST) From: bugzilla@dpdk.org To: dev@dpdk.org Subject: [DPDK/ethdev Bug 1762] Unable to use TB-mode when code blocks have different length (ACC100 / VRB drivers) Date: Wed, 30 Jul 2025 19:18:26 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: DPDK X-Bugzilla-Component: ethdev X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: faust1002@gmail.com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: dev@dpdk.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter target_milestone attachments.created Message-ID: Content-Type: multipart/alternative; boundary=17539031060.7F67C7.649321 Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.dpdk.org/ Auto-Submitted: auto-generated X-Auto-Response-Suppress: All MIME-Version: 1.0 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 --17539031060.7F67C7.649321 Date: Wed, 30 Jul 2025 21:18:26 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.dpdk.org/ Auto-Submitted: auto-generated X-Auto-Response-Suppress: All https://bugs.dpdk.org/show_bug.cgi?id=3D1762 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=3D324&action=3Dedit Problem with AC100 / VRB1 drivers when using TB mode Hello, First of all, I hope I selected the problematic component correctly. I deci= ded 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 =3D 0 tb_params.ea =3D 9056 tb_params.eb =3D 9088 tb_params.c =3D 23 tb_params.r =3D 0 tb_params.cab =3D 4 In other words, the first four CBs will be 9056 bits longs and the remainin= g 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, decodi= ng 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 featu= re. I would not be surprised if ACC100 / VRB1 didn't support different CB lengt= hs 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.=20 Kind regards --=20 You are receiving this mail because: You are the assignee for the bug.= --17539031060.7F67C7.649321 Date: Wed, 30 Jul 2025 21:18:26 +0200 MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.dpdk.org/ Auto-Submitted: auto-generated X-Auto-Response-Suppress: All
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 [details]
Problem with AC100 / VRB1 drivers when using TB mode

Hello,
First of all, I hope I selected the problematic component correctly. I deci=
ded
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 =3D 0
tb_params.ea =3D 9056
tb_params.eb =3D 9088
tb_params.c =3D 23
tb_params.r =3D 0
tb_params.cab =3D 4
In other words, the first four CBs will be 9056 bits longs and the remainin=
g 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, decodi=
ng
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 n=
ot
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 featu=
re.
I would not be surprised if ACC100 / VRB1 didn't support different CB lengt=
hs
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.=20
Kind regards

You are receiving this mail because:
  • You are the assignee for the bug.
=20=20=20=20=20=20=20=20=20=20
= --17539031060.7F67C7.649321--