From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 911D7A09E0; Sat, 14 Nov 2020 00:19:37 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 21CCFC8A8; Sat, 14 Nov 2020 00:19:35 +0100 (CET) Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by dpdk.org (Postfix) with ESMTP id 8E589C87A for ; Sat, 14 Nov 2020 00:19:32 +0100 (CET) IronPort-SDR: x/+EL4PyYB1bGsscmsbRN8D8isOH7gfClvuI5bAMsq8iq9faO1kTGfLCfX+6kqAdUEL1DcWtwb ubV6hcrbW81A== X-IronPort-AV: E=McAfee;i="6000,8403,9804"; a="232161521" X-IronPort-AV: E=Sophos;i="5.77,476,1596524400"; d="scan'208";a="232161521" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Nov 2020 15:19:27 -0800 IronPort-SDR: luRmv3FNVGFE6SN3VePKwY+4YlGtFnDZwZfqOKTsdJ3BBOQzJaXYkI43A0BYYSyROPAvFjwWUp byfQVVWKou4A== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.77,476,1596524400"; d="scan'208";a="355698558" Received: from fmsmsx606.amr.corp.intel.com ([10.18.126.86]) by orsmga008.jf.intel.com with ESMTP; 13 Nov 2020 15:19:27 -0800 Received: from fmsmsx608.amr.corp.intel.com (10.18.126.88) by fmsmsx606.amr.corp.intel.com (10.18.126.86) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Fri, 13 Nov 2020 15:19:26 -0800 Received: from fmsedg601.ED.cps.intel.com (10.1.192.135) by fmsmsx608.amr.corp.intel.com (10.18.126.88) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5 via Frontend Transport; Fri, 13 Nov 2020 15:19:26 -0800 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (104.47.57.173) by edgegateway.intel.com (192.55.55.70) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1713.5; Fri, 13 Nov 2020 15:19:26 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=n8gec+lX26V/L0JxT0NDAD/9Tv2Kdsuwn0p7l1ei4MVnDqlDGvm0Gfu+xJylmpuDhsLKsEMDD+wjht1UKjPHmMzd0d1b/chWVAycK3Kl7vZp2xYSBJq73/AYd7ThonX6Ek9RShYZgoJbM0utiPQmXaSiE+jseDtu6CVfmClFQ455Dn/P1R/sQqdbUT9ij2uIJSoviRFtK8SCVfbU5koS1Bqz1pA7hIAAL8niNmkQawVYi826STkhXErnqmtl3pv++bPNttKLfrYy8M854qlKHb+c8tb5wZ7uNBko/2bMPccYOlc7iBTZb3MfjR5zd8r5fsrlA1UwoQ7PBvGSTPW0qg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=woWGGZqnhalU6hxeNivux+TQRDx0NWmJCdvFS5ew/FY=; b=ZO/iDq5FKHg1gMU0hAGXqc6qTHNCawO5YtGHss6HzSUh7nfC7Wc2fiJmlQFKcsnElbocL5sAxgxars0P4WVLKDtZyH2oGHQyYroVqkjtdz41zluSnxlNevllMODsqrdDhXg9VSlMWL9bjkIseuC8s4HdWbi0HtNM1GIVmQsGZzUHIiJEZHGu5I4yR0A2q2pUOSx03PB+S96ouGdqOK7QuNhDhgiT3IDbVC40Y294TjyZuRhbZSIXUcA7q5jcYspsz/ouLNUlJV9Gj9rk3Flzdc4zDL5KDyFwzsZ7QTYqHHsODyJ5wn25+0y+DBBwKYww9Zwz/KwOS7Aq35X0jTAVxw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel.onmicrosoft.com; s=selector2-intel-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=woWGGZqnhalU6hxeNivux+TQRDx0NWmJCdvFS5ew/FY=; b=pRDVLHXquLmNjGAAY/kG8ZL4bHzHJ0K0gFbjNBoXgZYfxTq53kFRTZEoCJz4Hht6LtOxfOF4pw+PMOocmRpxuES6004qjhSRS6l7ruqPQrwFtsRjVS3ktFeRWlUuLOfkkek7tIjhyfY0YPh2VPdzgh4ye1L8OwyZ4GfLT7+zoOY= Received: from BY5PR11MB4451.namprd11.prod.outlook.com (2603:10b6:a03:1cb::30) by SJ0PR11MB5150.namprd11.prod.outlook.com (2603:10b6:a03:2d4::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3541.25; Fri, 13 Nov 2020 23:19:25 +0000 Received: from BY5PR11MB4451.namprd11.prod.outlook.com ([fe80::2cc6:cf34:70ec:a6cf]) by BY5PR11MB4451.namprd11.prod.outlook.com ([fe80::2cc6:cf34:70ec:a6cf%7]) with mapi id 15.20.3541.025; Fri, 13 Nov 2020 23:19:25 +0000 From: "Chautru, Nicolas" To: Aidan Goddard , "akhil.goyal@nxp.com" CC: "dev@dpdk.org" , Tom Rix Thread-Topic: [PATCH v3] BBDEV: add LDPC op parameters and flags to support CBGT Thread-Index: AQHWs3+Yi68JgqUSq0eTHJh7hZ9Qa6nGv1Yg Date: Fri, 13 Nov 2020 23:19:25 +0000 Message-ID: References: <1604584637-21906-1-git-send-email-aidan.goddard@accelercomm.com> <1604586344-25634-1-git-send-email-aidan.goddard@accelercomm.com> In-Reply-To: <1604586344-25634-1-git-send-email-aidan.goddard@accelercomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-reaction: no-action dlp-version: 11.5.1.3 authentication-results: accelercomm.com; dkim=none (message not signed) header.d=none;accelercomm.com; dmarc=none action=none header.from=intel.com; x-originating-ip: [45.28.143.88] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: da637c6e-7599-49bc-9559-08d8882a8f90 x-ms-traffictypediagnostic: SJ0PR11MB5150: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7219; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: R7lZCUXi9SR1Wir1cXlutW8UNEzrZpE3GlXhmrtz3zp5Z+Kusl/uSU9UzTp0ZD/ZLKKsFLOe9mDtsy5jyg6pOScEmsP9MmU+vp0K9kpcuyPzeYdGwU2Rh4WLJEWkZdhbsmqnV9x2oyn09W5BB7GjpCfPIYqJysAVfvP+eFWTcEFtbsFnv81wR74/2jAAy2M/kHpusk7YPBVg94YldVyWbpsBCH9xnhjr4Tajga6/6gaeOp4jsb+ZRqqDBEx2YWLnpg/8IKgarW/UFjh4U9qFJIt180whfOQcG8P4Tv6IROgQM+FzEs9o1jsTVIlz8wOtvT23br8eXVxqIc8EWHuSxolX/rOcq0lj8WK/B2EjsLxjaS3sG1/8yxZfhM/MyBHySedZOGORFbfGYsg1S3lLlA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR11MB4451.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(366004)(396003)(376002)(39860400002)(346002)(8936002)(186003)(966005)(478600001)(76116006)(86362001)(8676002)(53546011)(33656002)(6506007)(55016002)(83380400001)(54906003)(9686003)(30864003)(64756008)(66446008)(26005)(4326008)(52536014)(2906002)(316002)(71200400001)(110136005)(5660300002)(7696005)(66556008)(66476007)(66946007); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: ksGQku7pF1HV9C3fJ0vaKEU4G8/1g28FwxQBUS36fTp6QU0shUgJi7NCNnBaSU0Iz54bqz601pGQfjgFm9QuTIW0VLwMVb+N3yphf3jzG/6nCsE/vDo5FmKrlRSQp3hPjx8RVNSqMw6dzJz6Rq3kSj1Xv5h2w8JyAUvVhGKLaS01V/yoamfcu4hzO5AbcDdfAzTDMMl4N5d8cxolTGl+ykAnzM1Lrt/Q00jLk4UGyr0eGGQPlajZxfdNP0K2NcG0Q1P8u92ttURKjQXBzevO2jnT5DQ7Mmx4LnXwHST8LqOCKLL5MXBS3UeFHJqjy3jWXeKFcJReT8v0o+3xVstWaHlqaooH+/h2Z+iCwAhOYebo7GKndGbHUNAlRVyIJe8XghE0UVoOpZt3UqJ6BGJzHBsNAK6jwMZc2Ye+/Y8egD/HLFpB8Qjeg5f1TuwggA7PcDkakTf5hr7jeQVDtnTLfmOTbaNZvDmZPMn/9+0KLiUzWVc1V1bukQc81B852dfPr241ddDBBk8bDnJdsUp1dekNNYLUguDWrk25j/3OYwUus1l3kRSuNyFvrlgdNcqzkhpKL43KsinbLh9biyecetI33KiS/WOW0vSs4LaRlf5olwR1ec8xZhn1IY9pZDTHGdZEp7mA6JJ6jqvXBle5yn0Jjjf+xQR9c11owbJofJJ75z2Rkc5p4caLn5sXqK6HukFRnN9sQHSwTDs7+165puanVOfKnnJ70+vVjqVmdApWN29+pQzwJd9yoygJfikZ46GCUc39YjbQTtrP1BhykybODbkQQ/XDI/j1D1wB1stdu/vk+y3Z6byXaoe0AxQNuBz3B/KU+IUmQtXfg0hwAPXlMQQ5rtfF3lu/cbchJ9/V8IswydtfasbTm4SG0yLwsV1U0mbisa2l4r4/1uxeOw== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY5PR11MB4451.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: da637c6e-7599-49bc-9559-08d8882a8f90 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Nov 2020 23:19:25.0656 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 9OnwmVQpOWiMHZZKY1vPHQJJtShEptenzvXYi7kyMcW9GC5JXIgGWvRG1dp6fv5LSk+QwUBYQnMcOLENg7RycUSWHN0cvraF7x0tDS8mTEY= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR11MB5150 X-OriginatorOrg: intel.com Subject: Re: [dpdk-dev] [PATCH v3] BBDEV: add LDPC op parameters and flags to support CBGT X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Hi Aidan, Some general comments first as I see that this is a first DPDK contribution= . I suggest to add cover-later to provide more context for the serie and incremental changes between patch versions (see https://doc.dpdk.org/gu= ides/contributing/patches.html). When do you plan on of providing a PMD version supporting that API? I assum= e this is more of an RFC at the moment? It would be best for them to happen in the same cycle. More comment below. > -----Original Message----- > From: Aidan Goddard > Sent: Thursday, November 5, 2020 6:26 AM > To: akhil.goyal@nxp.com > Cc: Chautru, Nicolas ; dev@dpdk.org; Aidan > Goddard > Subject: [PATCH v3] BBDEV: add LDPC op parameters and flags to support > CBGT >=20 > This commit adds support to BBDEV for LDPC Code Block Group Transmission > (CBGT) as defined in 3GPP TS 38.214. The following changes facilitate thi= s: > - add RTE_BBDEV_LDPC_[ENC/DEC]_CBGT feature flag > - add CBGT input parameters to LDPC encode transport block op structure > - add CBGT input and output parameters to LDPC decode transport block op > - add support for reading these parameters from test vector files > - add sanity tests for RTE_BBDEV_LDPC_[ENC/DEC]_CBGT flag in test vector > - update user guide with the flags and parameters >=20 > CBGT parameters are only required when the > RTE_BBDEV_LDPC_[ENC/DEC]_CBGT op flag is specified. Best to put the change for bbdev-test update in a separate commit from the = first commit limited to change to librte_bbdev and related doc. (in same serie) The change to bbdev-test are not directly required for the api change, only= to process a test vector format which is not provided yet. I assume you wi= ll provide one of such test vector. Also (minor) don't capitalize bbdev in the commit message. >=20 > Reported-by: Rob Maunder > Signed-off-by: Aidan Goddard > Acked-by: Dave Burley > --- > app/test-bbdev/test_bbdev_vector.c | 46 +++++++++++++++++++--- > app/test-bbdev/test_bbdev_vector.h | 3 ++ > doc/guides/prog_guide/bbdev.rst | 29 ++++++++++++++ > lib/librte_bbdev/rte_bbdev_op.h | 80 > +++++++++++++++++++++++++++++++++++++- > 4 files changed, 151 insertions(+), 7 deletions(-) >=20 > diff --git a/app/test-bbdev/test_bbdev_vector.c b/app/test- > bbdev/test_bbdev_vector.c > index 50d1da0..e5808b2 100644 > --- a/app/test-bbdev/test_bbdev_vector.c > +++ b/app/test-bbdev/test_bbdev_vector.c > @@ -200,6 +200,8 @@ > else if (!strcmp(token, >=20 > "RTE_BBDEV_LDPC_INTERNAL_HARQ_MEMORY_LOOPBACK")) > *op_flag_value =3D > RTE_BBDEV_LDPC_INTERNAL_HARQ_MEMORY_LOOPBACK; > + else if (!strcmp(token, "RTE_BBDEV_LDPC_DEC_CBGT")) > + *op_flag_value =3D RTE_BBDEV_LDPC_DEC_CBGT; > else { > printf("The given value is not a LDPC decoder flag\n"); > return -1; > @@ -248,8 +250,10 @@ > *op_flag_value =3D RTE_BBDEV_LDPC_ENC_INTERRUPTS; > else if (!strcmp(token, "RTE_BBDEV_LDPC_ENC_SCATTER_GATHER")) > *op_flag_value =3D RTE_BBDEV_LDPC_ENC_SCATTER_GATHER; > + else if (!strcmp(token, "RTE_BBDEV_LDPC_ENC_CBGT")) > + *op_flag_value =3D RTE_BBDEV_LDPC_ENC_CBGT; > else { > - printf("The given value is not a turbo encoder flag\n"); > + printf("The given value is not a LDPC encoder flag\n"); > return -1; > } >=20 > @@ -718,6 +722,14 @@ > vector->mask |=3D TEST_BBDEV_VF_CODE_BLOCK_MODE; > ldpc_enc->code_block_mode =3D (uint8_t) strtoul(token, &err, > 0); > ret =3D ((err =3D=3D NULL) || (*err !=3D '\0')) ? -1 : 0; > + } else if (!strcmp(key_token, "max_cbg")) { > + vector->mask |=3D TEST_BBDEV_VF_MAX_CBG_PER_TB; > + ldpc_enc->tb_params.max_cbg =3D (uint8_t) strtoul(token, > &err, 0); > + ret =3D ((err =3D=3D NULL) || (*err !=3D '\0')) ? -1 : 0; > + } else if (!strcmp(key_token, "cbgti")) { > + vector->mask |=3D TEST_BBDEV_VF_CBGTI; > + ldpc_enc->tb_params.cbgti =3D (uint8_t) strtoul(token, &err, 0); > + ret =3D ((err =3D=3D NULL) || (*err !=3D '\0')) ? -1 : 0; > } else if (!strcmp(key_token, "op_flags")) { > vector->mask |=3D TEST_BBDEV_VF_OP_FLAGS; > ret =3D parse_turbo_flags(token, &op_flags, vector->op_type); > @@ -828,6 +840,18 @@ > vector->mask |=3D TEST_BBDEV_VF_CODE_BLOCK_MODE; > ldpc_dec->code_block_mode =3D (uint8_t) strtoul(token, &err, > 0); > ret =3D ((err =3D=3D NULL) || (*err !=3D '\0')) ? -1 : 0; > + } else if (!strcmp(key_token, "max_cbg")) { > + vector->mask |=3D TEST_BBDEV_VF_MAX_CBG_PER_TB; > + ldpc_dec->tb_params.max_cbg =3D (uint8_t) strtoul(token, > &err, 0); > + ret =3D ((err =3D=3D NULL) || (*err !=3D '\0')) ? -1 : 0; > + } else if (!strcmp(key_token, "cbgti")) { > + vector->mask |=3D TEST_BBDEV_VF_CBGTI; > + ldpc_dec->tb_params.cbgti =3D (uint8_t) strtoul(token, &err, 0); > + ret =3D ((err =3D=3D NULL) || (*err !=3D '\0')) ? -1 : 0; > + } else if (!strcmp(key_token, "cbgfi")) { > + vector->mask |=3D TEST_BBDEV_VF_CBGFI; > + ldpc_dec->tb_params.cbgfi =3D (uint8_t) strtoul(token, &err, 0); > + ret =3D ((err =3D=3D NULL) || (*err !=3D '\0')) ? -1 : 0; > } else if (!strcmp(key_token, "op_flags")) { > vector->mask |=3D TEST_BBDEV_VF_OP_FLAGS; > ret =3D parse_turbo_flags(token, &op_flags, vector->op_type); > @@ -1162,6 +1186,12 @@ > if (!(mask & TEST_BBDEV_VF_R)) > printf( > "WARNING: r was not specified in vector file > and will be set to 0\n"); > + if (!(mask & TEST_BBDEV_VF_MAX_CBG_PER_TB) && > (ldpc_dec->op_flags & > + RTE_BBDEV_LDPC_DEC_CBGT)) { > + printf( > + "WARNING: max_cbg was not specified in > vector file and will be set to 1\n"); > + ldpc_dec->tb_params.max_cbg =3D 1; > + } > } else { > if (!(mask & TEST_BBDEV_VF_E)) > printf( > @@ -1298,12 +1328,18 @@ > if (!(mask & TEST_BBDEV_VF_CODE_BLOCK_MODE)) { > printf( > "WARNING: code_block_mode was not specified in > vector file and will be set to 1\n"); > - vector->turbo_enc.code_block_mode =3D 1; > + vector->ldpc_enc.code_block_mode =3D 1; > } > - if (vector->turbo_enc.code_block_mode =3D=3D 0) { > + if (vector->ldpc_enc.code_block_mode =3D=3D 0) { > + if (!(mask & TEST_BBDEV_VF_MAX_CBG_PER_TB) && (vector- > >ldpc_enc.op_flags & > + RTE_BBDEV_LDPC_ENC_CBGT)) { > + printf( > + "WARNING: max_cbg was not specified in > vector file and will be set to 1\n"); > + vector->ldpc_enc.tb_params.max_cbg =3D 1; > + } > } else { > - if (!(mask & TEST_BBDEV_VF_E) && (vector- > >turbo_enc.op_flags & > - RTE_BBDEV_TURBO_RATE_MATCH)) > + if (!(mask & TEST_BBDEV_VF_E) && (vector- > >ldpc_enc.op_flags & > + RTE_BBDEV_LDPC_RATE_MATCH)) > printf( > "WARNING: e was not specified in vector file > and will be set to 0\n"); > if (!(mask & TEST_BBDEV_VF_NCB)) > diff --git a/app/test-bbdev/test_bbdev_vector.h b/app/test- > bbdev/test_bbdev_vector.h > index 4e5dbf5..69f5b9c 100644 > --- a/app/test-bbdev/test_bbdev_vector.h > +++ b/app/test-bbdev/test_bbdev_vector.h > @@ -35,6 +35,9 @@ enum { > TEST_BBDEV_VF_CODE_BLOCK_MODE =3D (1ULL << 23), > TEST_BBDEV_VF_OP_FLAGS =3D (1ULL << 24), > TEST_BBDEV_VF_EXPECTED_STATUS =3D (1ULL << 25), > + TEST_BBDEV_VF_MAX_CBG_PER_TB =3D (1ULL << 26), > + TEST_BBDEV_VF_CBGTI =3D (1ULL << 27), > + TEST_BBDEV_VF_CBGFI =3D (1ULL << 28), > }; A part of the test commit, good to have a vector for reference (a relativel= y small one). >=20 > enum op_data_type { > diff --git a/doc/guides/prog_guide/bbdev.rst > b/doc/guides/prog_guide/bbdev.rst index 6b2bd54..0ff4039 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_CBGT | > +| Set if a device supports CB group transmission | > ++--------------------------------------------------------------------+ >=20 > The structure passed for each LDPC encode operation is given below, wit= h > the operation flags forming a bitmask in the ``op_flags`` field. > @@ -815,6 +818,10 @@ The LDPC encode parameters are set out in the table > below. > +----------------+------------+-----------------------------------------= --------------+ > | |eb |Eb, length of the RM output sequence in b= its, r >=3D cab | > +----------------+------------+-----------------------------------------= --------------+ > +| |max_cbg |maximum number of CB groups per TB: 1-8 = | > ++----------------+------------+-----------------------------------------= --------------+ > +| |cbgti |CB group transmission information bitfiel= d | > ++----------------+------------+-----------------------------------------= --------------+ >=20 > The mbuf input ``input`` is mandatory for all BBDEV PMDs and is the > incoming code block or transport block data. > @@ -869,6 +876,11 @@ Figure :numref:`figure_turbo_tb_encode` above > showing the Turbo encoding of CBs using BBDEV interface in TB-mode is al= so > valid for LDPC encode. >=20 > +In TB-mode, If the ``RTE_BBDEV_LDPC_ENC_CBGT`` flag is specified the > +``max_cbg`` and ``cbgti`` parameters are used for CB group > +transmission. If the ``RTE_BBDEV_LDPC_ENC_CBGT`` flag is not specified, > +these parameters are ignored. > + > BBDEV LDPC Decode Operation > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >=20 > @@ -942,6 +954,9 @@ given below. > |RTE_BBDEV_LDPC_INTERNAL_HARQ_MEMORY_LOOPBACK | > | Set if a device supports loopback access to HARQ internal memory | > +--------------------------------------------------------------------+ > +|RTE_BBDEV_LDPC_DEC_CBGT | > +| Set if a device supports CB group transmission | > ++--------------------------------------------------------------------+ >=20 > The structure passed for each LDPC decode operation is given below, wit= h > the operation flags forming a bitmask in the ``op_flags`` field. > @@ -1027,6 +1042,14 @@ The LDPC decode parameters are set out in the > table below. > +----------------+------------+-----------------------------------------= --------------+ > | |eb |Eb, length of the RM output sequence in b= its r >=3D cab | > +----------------+------------+-----------------------------------------= --------------+ > +| |max_cbg |maximum number of CB groups per TB: 1-8 = | > ++----------------+------------+-----------------------------------------= --------------+ > +| |cbgti |CB group transmission information bitfiel= d | > ++----------------+------------+-----------------------------------------= --------------+ > +| |cbgfi |CB group Flushing out Information (CBGFI)= | > ++----------------+------------+-----------------------------------------= --------------+ > +| |cbg_crc_err |CB group CRC failure bitfield (output) = | > ++----------------+------------+-----------------------------------------= --------------+ >=20 > The mbuf input ``input`` encoded CB data is mandatory for all BBDEV PMDs > and is the Virtual Circular Buffer data stream with null padding. > @@ -1084,6 +1107,12 @@ Figure :numref:`figure_turbo_tb_decode` above > showing the Turbo decoding of CBs using BBDEV interface in TB-mode is al= so > valid for LDPC decode. >=20 > +In TB-mode, If the ``RTE_BBDEV_LDPC_DEC_CBGT`` flag is specified the > +``max_cbg`` and ``cbgti`` parameters are used for CB group > +transmission. The ``cbg_crc_err`` output parameter is a bitfield used > +to indicate crc failures in the respective CB groups. If the > +``RTE_BBDEV_LDPC_DEC_CBGT`` flag is not specified, these parameters are > ignored. > + >=20 > Sample code > ----------- > diff --git a/lib/librte_bbdev/rte_bbdev_op.h > b/lib/librte_bbdev/rte_bbdev_op.h index f726d73..f3d00dc 100644 > --- a/lib/librte_bbdev/rte_bbdev_op.h > +++ b/lib/librte_bbdev/rte_bbdev_op.h > @@ -186,7 +186,9 @@ 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 =3D (1ULL << > 18) > + RTE_BBDEV_LDPC_INTERNAL_HARQ_MEMORY_FILLERS =3D (1ULL << > 18), > + /** Set if a device supports CB group transmission. */ > + RTE_BBDEV_LDPC_DEC_CBGT =3D (1ULL << 19) Since this is not really a different processing per se, more a different AP= I/mode option being proposed to indicate how to process each cbs (variant o= f existing cb/tb mode), I would suggest then something like RTE_BBDEV_LDPC_= DEC_CBGT_MODE Also to be explicit the assumption is that a device supporting that flag wo= uld also support standard TB mode and CB mode, is that your expectation? ie= . not mutually exclusive > }; >=20 > /** Flags for LDPC encoder operation and capability structure */ @@ -206= ,7 > +208,9 @@ enum rte_bbdev_op_ldpcenc_flag_bitmasks { > /** Set if a device supports scatter-gather functionality. */ > RTE_BBDEV_LDPC_ENC_SCATTER_GATHER =3D (1ULL << 6), > /** Set if a device supports concatenation of non byte aligned output > */ > - RTE_BBDEV_LDPC_ENC_CONCATENATION =3D (1ULL << 7) > + RTE_BBDEV_LDPC_ENC_CONCATENATION =3D (1ULL << 7), > + /** Set if a device supports CB group transmission. */ > + RTE_BBDEV_LDPC_ENC_CBGT =3D (1ULL << 8) > }; >=20 > /** Data input and output buffer for BBDEV operations */ @@ -334,6 > +338,56 @@ struct rte_bbdev_op_dec_ldpc_tb_params { > uint8_t r; > /** The number of CBs that use Ea before switching to Eb, [0:63] */ > uint8_t cab; > + /** If the RTE_BBDEV_LDPC_DEC_CBGT capability is not asserted, > then > + * the value of max_cbg is ignored. Otherwise, a max_cbg value of > + * 0 or 1 indicates that codeBlockGroupTransmission is disabled, > + * as defined in 3GPP TS 38.214. I would suggest to refer more specifically to the 3gpp section/subclause (g= eneral comment for each 3gpp reference). Here to you are refering max_cbg to be `maxCodeBlockGroupsPerTransportBlock= ` and not the `M` from 5.1.7.1? Good to be explicit and use the 3gpp term once to be explicit. Any reason not to use M instead of maxCodeBlockGroupsPerTransportBlock here= ? > + * > + * A max_cbg value of 2, 4, 6, or 8 sets the value of Are you assuming that 1 is not a legit value when that flag is enabled? Not= the case in the doc. > + * maxCodeBlockGroupsPerTransportBlock and indicates that > + * codeBlockGroupTransmission is enabled, as defined in 3GPP TS > 38.214. > + */ > + uint8_t max_cbg; > + /** If codeBlockGroupTransmission is disabled, then the value of cbgti > + * is ignored. Otherwise, cbgti represents the Code Block Group > + * Transmission Information (CBGTI), as defined in 3GPP TS 38.214. > + * In this case, the M =3D min(C, max_cbg) number of Most Significant > + * Bits (MSBs) of the uint8_t cbgti have an in-order one-to-one > mapping > + * with the M code block groups (CBGs) of the transport block, with > the > + * MSB mapped to CBG#0, as detailed in 3GPP TS 38.214. > + * > + * Here, C is the total number of code blocks in the full transport > block, > + * as defined in 3GPP TS 38.212. Good to be explicit for the case when N_TBS =3D 2 as this may or not cause = the api above to diverge from 3gpp terminology. This can be added in doc. Good to be explicit on the assumption on input/output/harq `mbuf` notably f= or a given bitmap pattern where some CBG are not transmitted (0101...). ie.= notably to confirm all data is concatenated back to back in same mbuf rega= rdless and whether harq buffers of CBG not transmitted are skipped. General comment is that the doc above has less information than the .h file= (hence reviewing thia file only) > + */ > + uint8_t cbgti; > + /** If codeBlockGroupTransmission is disabled, then the value of cbgfi > + * should be ignored. Otherwise, cbgfi represents the Code Block > Group > + * Flushing out Information (CBGFI), as defined in 3GPP TS 38.214. In > this > + * case, if the LSB of the uint8_t cbgfi is set to 0, this indicates th= at > + * the earlier received instances of the same CBGs being decoded may > be > + * corrupted and that the corresponding contents of the HARQ > memory should > + * be flushed and not combined with the present CBGs being > decoded. If the > + * LSB of the uint8_t cbgfi is set to 1, this indicates that the earlie= r > + * received instances of the same CBGs being decoded should be > combined with > + * the present CBGs being decoded. > + */ > + uint8_t cbgfi; > + > + /** If codeBlockGroupTransmission is disabled or if > + * RTE_BBDEV_LDPC_CRC_TYPE_24B_CHECK is not asserted, then the > value of > + * cbg_crc_err should be ignored. Otherwise, cbg_crc_err reports > whether > + * any CRC24B failures have been encountered in each of the code > block > + * groups (CBGs). In this case, the M =3D min(C, max_cbg) number of > Most > + * Significant Bits (MSBs) of the uint8_t cbg_crc_error have an in- > order > + * one-to-one mapping with the M CBGs of the transport block, with > the MSB > + * mapped to CBG#0, as detailed in 3GPP TS 38.214. An asserted bit > + * indicates that a CRC24B failure was encountered among the code > blocks > + * of the corresponding CBG. > + * > + * Here, C is the total number of code blocks in the full transport > block, > + * as defined in 3GPP TS 38.212. > + */ > + uint8_t cbg_crc_err; > }; >=20 > /** Operation structure for Turbo decode. > @@ -584,6 +638,28 @@ struct rte_bbdev_op_enc_ldpc_tb_params { > uint8_t r; > /** The number of CBs that use Ea before switching to Eb, [0:63] */ > uint8_t cab; > + /** If the RTE_BBDEV_LDPC_ENC_CBGT capability is not asserted, > then > + * the value of max_cbg is ignored. Otherwise, a max_cbg value of > + * 0 or 1 indicates that codeBlockGroupTransmission is disabled, > + * as defined in 3GPP TS 38.214. > + * > + * A max_cbg value of 2, 4, 6, or 8 sets the value of > + * maxCodeBlockGroupsPerTransportBlock and indicates that > + * codeBlockGroupTransmission is enabled, as defined in 3GPP TS > 38.214. > + */ > + uint8_t max_cbg; > + /** If codeBlockGroupTransmission is disabled, then the value of cbgti > + * is ignored. Otherwise, cbgti represents the Code Block Group > + * Transmission Information (CBGTI), as defined in 3GPP TS 38.214. > + * In this case, the M =3D min(C, max_cbg) number of Most Significant > + * Bits (MSBs) of the uint8_t cbgti have an in-order one-to-one > mapping > + * with the M code block groups (CBGs) of the transport block, with > the > + * MSB mapped to CBG#0, as detailed in 3GPP TS 38.214. > + * > + * Here, C is the total number of code blocks in the full transport > block, > + * as defined in 3GPP TS 38.212. > + */ > + uint8_t cbgti; Same comment as for uplink with regards to assumptions on mbuf input/output= with regards to skipped CBG would be good to be explicit. In case this is same as TB mode then this would already be supported by exi= sting TB mode mode (partial TB with number of CBs with size Ea or Eb). We can discuss more offline or on the mailing list. > }; >=20 > /** Operation structure for Turbo encode. > -- > 1.8.3.1