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 F3A66A04C7; Tue, 15 Sep 2020 03:45:16 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id B01E41BE8E; Tue, 15 Sep 2020 03:45:15 +0200 (CEST) Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by dpdk.org (Postfix) with ESMTP id EB7B9DE0 for ; Tue, 15 Sep 2020 03:45:12 +0200 (CEST) IronPort-SDR: UJ0IEBbTe/oyiH+yypUduFIBuQL5rMLpBfwiEqedMg8cmPtB93Tstq3NaNgiLMQi/nPRsYyv4D rpHflmt9aCXg== X-IronPort-AV: E=McAfee;i="6000,8403,9744"; a="220742457" X-IronPort-AV: E=Sophos;i="5.76,427,1592895600"; d="scan'208";a="220742457" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga006.jf.intel.com ([10.7.209.51]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Sep 2020 18:45:11 -0700 IronPort-SDR: ygJvUqavJi+BLzszjHugai76jFeZ+byck+dJt9mH+yWhbdejiiqH2i7rvaX2/rGLmE7VnyK3Sb bSuEZhA41T+g== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.76,427,1592895600"; d="scan'208";a="306388057" Received: from orsmsx604.amr.corp.intel.com ([10.22.229.17]) by orsmga006.jf.intel.com with ESMTP; 14 Sep 2020 18:45:11 -0700 Received: from orsmsx604.amr.corp.intel.com (10.22.229.17) by ORSMSX604.amr.corp.intel.com (10.22.229.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Mon, 14 Sep 2020 18:45:10 -0700 Received: from orsmsx151.amr.corp.intel.com (10.22.226.38) by orsmsx604.amr.corp.intel.com (10.22.229.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.1713.5 via Frontend Transport; Mon, 14 Sep 2020 18:45:10 -0700 Received: from ORSEDG602.ED.cps.intel.com (10.7.248.7) by ORSMSX151.amr.corp.intel.com (10.22.226.38) with Microsoft SMTP Server (TLS) id 14.3.439.0; Mon, 14 Sep 2020 18:45:10 -0700 Received: from NAM04-BN3-obe.outbound.protection.outlook.com (104.47.46.59) by edgegateway.intel.com (134.134.137.103) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1713.5; Mon, 14 Sep 2020 18:45:09 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CjtK11nvl/fZRzGUDWNdZsG3ixLbOqmUKhqN1eiw4wCPn3xJKWHVFova+txEGwYJfRwqKRYdAZKAEBvqSpmVwdO7okPlkj106KcKpwFGuq1QYKfsIh21s0MrLyvrOLBa/NGAlW0zfMVZqfH04SmqZTlC08wy4iEgYUcMYYB2NQw2dAW3X5MIEUw5Px5Nuu4bTDvBSVJZXaI6UBl9HNE0WdisT+CVYW+HK7JLPz9M4f21jVBdFK+hQWOF6SX+9yMMufe3XUmXmaxXOJ2VkYUzMS+CNfDIXjjh+92Q1lCsfY/uyVBT3SAtiUQJz6LeHrSiasmOpHjACqibjKZFMDHJKQ== 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=jRcTrhNuAh+X8qX9wo8qXchI1LzY556pOAB+ZkcVAXo=; b=OV9ZnniYsQmZx0vHci7qGkFX9lvE1TQWhSUNeqSb/IfQIaw6U/MtEGAIpQck85glW2X43AzJL9YadCx9v/R59josNFG8upyN4PMUE2EM5ygFJLP2rKdvvAWwfQBfWQXohQwIShVvApNr/hkzuPKdCJ61M5SjvDKCEO9TvwBxwTkNjCEd9wlICvsyDefIYBDJ1JHBKp8kiv9UU3FgoAJjL+a04vHGm6TzKaELo+qx9in6zRmy+ljRBNCKWqTLlTcEiD9ahca/NqX/yAEhM8Zi3uL9tLZ8lpNk7Gu5NODGhqAXlaG1fwchNhp5sxErndLcKxfXGopAcNJNzmoMGU4Nwg== 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=jRcTrhNuAh+X8qX9wo8qXchI1LzY556pOAB+ZkcVAXo=; b=uw2l3oEKyARjhRYwxpQDLa5M4LI7zbbVnpR3CzDzdrZ/k86s787mAs6TSI9t6kuYrojbpmd+c7u+juFPv8hTamRJkbP9BkuwkCUZl5CuODUSDRv+ZRCdCydYbFMXkYxWlRa6ACakACgtSLn477BwQtDPDHOpxZp3h+GeaMU+EO0= Received: from BY5PR11MB4451.namprd11.prod.outlook.com (2603:10b6:a03:1cb::30) by BY5PR11MB4322.namprd11.prod.outlook.com (2603:10b6:a03:1ce::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3370.16; Tue, 15 Sep 2020 01:45:03 +0000 Received: from BY5PR11MB4451.namprd11.prod.outlook.com ([fe80::4162:97e1:7d04:a508]) by BY5PR11MB4451.namprd11.prod.outlook.com ([fe80::4162:97e1:7d04:a508%7]) with mapi id 15.20.3370.019; Tue, 15 Sep 2020 01:45:03 +0000 From: "Chautru, Nicolas" To: "Ananyev, Konstantin" , "Xu, Rosen" , "dev@dpdk.org" CC: "Richardson, Bruce" , "akhil.goyal@nxp.com" Thread-Topic: [dpdk-dev] [PATCH v3 05/11] baseband/acc100: add LDPC processing functions Thread-Index: AQHWgdH1nrzpwpcDM0KVd9XQf2vxI6lXWrzQgBGkfmA= Date: Tue, 15 Sep 2020 01:45:02 +0000 Message-ID: References: <1597796731-57841-1-git-send-email-nicolas.chautru@intel.com> <1597796731-57841-6-git-send-email-nicolas.chautru@intel.com> In-Reply-To: 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: intel.com; dkim=none (message not signed) header.d=none;intel.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: f8d1fcec-c36e-458e-0cee-08d85918f6f2 x-ms-traffictypediagnostic: BY5PR11MB4322: x-ld-processed: 46c98d88-e344-4ed4-8496-4ed7712e255d,ExtAddr x-ms-exchange-transport-forked: True 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: 9Ql631gaNN82RRabMUhIxNgQIywIfraMh0GC7l4Lu4kbf9zj9w/MbBbtO3vOxep47onSU1oTqQT3SI6PaLm4mtuNJH3PB+BdRiH9IOSKOOyfGynY6qSVaLf5hcW75gNqOykgI3UL6nF+TNaIFUyn/1HURz3l/F9RYPBto4CnegywkrJGUejEb1VmHkxShqMPED4l0cgngHjN/+aQK5o9sNQ2bQugl4dwNRl5zUC7LDt4YKuXbcwp3zrTnCTpEXhymH32TnqNXsdt/QG/WcBhTZIqS6240LIVOPlrccwS8A2azzbYQvlyPjbv89tmFnN2Fn8+RcHE/h6uWdbB5qPsxc9igJdSCpJy8BoJnmWxxYguOdUc/NceCiXhZEEd5lMX 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)(346002)(366004)(376002)(136003)(396003)(39860400002)(54906003)(110136005)(478600001)(5660300002)(71200400001)(86362001)(66946007)(83380400001)(66476007)(66556008)(64756008)(33656002)(52536014)(66446008)(76116006)(7696005)(316002)(53546011)(6506007)(2906002)(26005)(186003)(55016002)(4326008)(9686003)(8936002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: E8vhgmenaUGf2tAEN3/N5bzc1pJsIg7g2aD/upRnGSAJe4BLVrJVR3iU/RZKqGuqVLEnCibgwn2H9rolThU5z1HmgiadBDl5Eqvb3j4rdx4+ddMwOou9gXZoq+XQXPvzdG9Tw5u/w1OCa9PzMgc4MC5w38TDBLEGxzRDyjlrJgX0sGIev6+Ri4H8OPEJiCmeFpGFHR68kzImhdQR2kyfZnuvVDw2lCzMZhfU1c2RNpaTerv5snerVhsGS3lLtb9pFAtQ4PTphYwlMh13Ks5FZI/PjPmfxz/cRQRoHMg9izqdcNqLkulq8cr8M83Qcf8EnQOuWkwYE9tTzfdMNLqq0R6okMPWjDEZu/rOIVfsIeDQi0h54VlPZD910k8HVCkvU9eB0gy4Upf8/AZ8vSp6lf0XDZ+k6Dp5/QDNIEq22cgattQOX6aS+zAxqwjiSKLqkE2mPeMrrKrCJ4BiFcjF7Euv053ma5YYvUxM1W5nJU1ZP4MjyiEhgQNE4/dQ6ruC/4W3HQKImStePqPuvSaRuJMomcupBYaQHfCuKFitps2piR+GbzkkHLtcjVBi19O7O4CAUhQ4xahUQT1VCHWV9CdsrCtN4J0+fI9slVozBqA6sOH2zruJZOXaQYQl3UaxV4POJWDQGauoH8K3ZKOsOg== 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: f8d1fcec-c36e-458e-0cee-08d85918f6f2 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Sep 2020 01:45:02.8361 (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: /r78HK4OINV2cFiMVzhMjJQl4VjKk+VKrRDELh/wp9aID17YXtaohPFJTovn03xuRR0Q7Qaw+8frXHXLAAoho2ktYO2HTcQZnCuG+fUA+2k= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR11MB4322 X-OriginatorOrg: intel.com Subject: Re: [dpdk-dev] [PATCH v3 05/11] baseband/acc100: add LDPC processing functions 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 Konstantin, Rosen,=20 Replying to my own email.=20 Can you confirm that the previous explanation below makes sense and can you= ack this patch? Thanks and regards,=20 Nic > From: Chautru, Nicolas >=20 > > From: Ananyev, Konstantin > > > > > > > > > -----Original Message----- > > > From: dev On Behalf Of Xu, Rosen > > > Sent: Thursday, September 3, 2020 3:34 AM > > > To: Chautru, Nicolas ; dev@dpdk.org; > > > akhil.goyal@nxp.com > > > Cc: Richardson, Bruce > > > Subject: Re: [dpdk-dev] [PATCH v3 05/11] baseband/acc100: add LDPC > > > processing functions > > > > > > Hi, > > > > > > > -----Original Message----- > > > > From: Chautru, Nicolas > > > > Sent: Sunday, August 30, 2020 2:01 > > > > To: Xu, Rosen ; dev@dpdk.org; > > > > akhil.goyal@nxp.com > > > > Cc: Richardson, Bruce > > > > Subject: RE: [dpdk-dev] [PATCH v3 05/11] baseband/acc100: add LDPC > > > > processing functions > > > > > > > > Hi Rosen, > > > > > > > > > From: Xu, Rosen > > > > > > > > > > Hi, > > > > > > > > > > > -----Original Message----- > > > > > > From: dev On Behalf Of Nicolas Chautru > > > > > > Sent: Wednesday, August 19, 2020 8:25 > > > > > > To: dev@dpdk.org; akhil.goyal@nxp.com > > > > > > Cc: Richardson, Bruce ; Chautru, > > > > > > Nicolas > > > > > > Subject: [dpdk-dev] [PATCH v3 05/11] baseband/acc100: add LDPC > > > > > > processing functions > > > > > > > > > > > > Adding LDPC decode and encode processing operations > > > > > > > > > > > > Signed-off-by: Nicolas Chautru > > > > > > --- > > > > > > drivers/baseband/acc100/rte_acc100_pmd.c | 1625 > > > > > > +++++++++++++++++++++++++++++- > > > > > > drivers/baseband/acc100/rte_acc100_pmd.h | 3 + > > > > > > 2 files changed, 1626 insertions(+), 2 deletions(-) > > > > > > > > > > > > diff --git a/drivers/baseband/acc100/rte_acc100_pmd.c > > > > > > b/drivers/baseband/acc100/rte_acc100_pmd.c > > > > > > index 7a21c57..5f32813 100644 > > > > > > --- a/drivers/baseband/acc100/rte_acc100_pmd.c > > > > > > +++ b/drivers/baseband/acc100/rte_acc100_pmd.c > > > > > > @@ -15,6 +15,9 @@ > > > > > > #include > > > > > > #include > > > > > > #include > > > > > > +#ifdef RTE_BBDEV_OFFLOAD_COST #include #endif > > > > > > > > > > > > #include > > > > > > #include > > > > > > @@ -449,7 +452,6 @@ > > > > > > return 0; > > > > > > } > > > > > > > > > > > > - > > > > > > /** > > > > > > * Report a ACC100 queue index which is free > > > > > > * Return 0 to 16k for a valid queue_idx or -1 when no queue > > > > > > is available @@ -634,6 +636,46 @@ > > > > > > struct acc100_device *d =3D dev->data->dev_private; > > > > > > > > > > > > static const struct rte_bbdev_op_cap bbdev_capabilities[] =3D > > > > > > { > > > > > > + { > > > > > > + .type =3D RTE_BBDEV_OP_LDPC_ENC, > > > > > > + .cap.ldpc_enc =3D { > > > > > > + .capability_flags =3D > > > > > > + > > RTE_BBDEV_LDPC_RATE_MATCH | > > > > > > + > > RTE_BBDEV_LDPC_CRC_24B_ATTACH > > > > > > | > > > > > > + > > > > > > RTE_BBDEV_LDPC_INTERLEAVER_BYPASS, > > > > > > + .num_buffers_src =3D > > > > > > + > > > > > > RTE_BBDEV_LDPC_MAX_CODE_BLOCKS, > > > > > > + .num_buffers_dst =3D > > > > > > + > > > > > > RTE_BBDEV_LDPC_MAX_CODE_BLOCKS, > > > > > > + } > > > > > > + }, > > > > > > + { > > > > > > + .type =3D RTE_BBDEV_OP_LDPC_DEC, > > > > > > + .cap.ldpc_dec =3D { > > > > > > + .capability_flags =3D > > > > > > + > > RTE_BBDEV_LDPC_CRC_TYPE_24B_CHECK | > > > > > > + > > RTE_BBDEV_LDPC_CRC_TYPE_24B_DROP | > > > > > > + > > > > > > RTE_BBDEV_LDPC_HQ_COMBINE_IN_ENABLE | > > > > > > + > > > > > > RTE_BBDEV_LDPC_HQ_COMBINE_OUT_ENABLE | > > > > > > +#ifdef ACC100_EXT_MEM > > > > > > + > > > > > > RTE_BBDEV_LDPC_INTERNAL_HARQ_MEMORY_IN_ENABLE | > > > > > > + > > > > > > RTE_BBDEV_LDPC_INTERNAL_HARQ_MEMORY_OUT_ENABLE > | > > > > > > +#endif > > > > > > + > > > > > > RTE_BBDEV_LDPC_ITERATION_STOP_ENABLE | > > > > > > + > > RTE_BBDEV_LDPC_DEINTERLEAVER_BYPASS > > > > > > | > > > > > > + RTE_BBDEV_LDPC_DECODE_BYPASS | > > > > > > + > > RTE_BBDEV_LDPC_DEC_SCATTER_GATHER | > > > > > > + > > > > > > RTE_BBDEV_LDPC_HARQ_6BIT_COMPRESSION | > > > > > > + > > RTE_BBDEV_LDPC_LLR_COMPRESSION, > > > > > > + .llr_size =3D 8, > > > > > > + .llr_decimals =3D 1, > > > > > > + .num_buffers_src =3D > > > > > > + > > > > > > RTE_BBDEV_LDPC_MAX_CODE_BLOCKS, > > > > > > + .num_buffers_hard_out =3D > > > > > > + > > > > > > RTE_BBDEV_LDPC_MAX_CODE_BLOCKS, > > > > > > + .num_buffers_soft_out =3D 0, > > > > > > + } > > > > > > + }, > > > > > > RTE_BBDEV_END_OF_CAPABILITIES_LIST() > > > > > > }; > > > > > > > > > > > > @@ -669,9 +711,14 @@ > > > > > > dev_info->cpu_flag_reqs =3D NULL; > > > > > > dev_info->min_alignment =3D 64; > > > > > > dev_info->capabilities =3D bbdev_capabilities; > > > > > > +#ifdef ACC100_EXT_MEM > > > > > > dev_info->harq_buffer_size =3D d->ddr_size; > > > > > > +#else > > > > > > + dev_info->harq_buffer_size =3D 0; #endif > > > > > > } > > > > > > > > > > > > + > > > > > > static const struct rte_bbdev_ops acc100_bbdev_ops =3D { > > > > > > .setup_queues =3D acc100_setup_queues, > > > > > > .close =3D acc100_dev_close, > > > > > > @@ -696,6 +743,1577 @@ > > > > > > {.device_id =3D 0}, > > > > > > }; > > > > > > > > > > > > +/* Read flag value 0/1 from bitmap */ static inline bool > > > > > > +check_bit(uint32_t bitmap, uint32_t bitmask) { > > > > > > + return bitmap & bitmask; > > > > > > +} > > > > > > + > > > > > > +static inline char * > > > > > > +mbuf_append(struct rte_mbuf *m_head, struct rte_mbuf *m, > > > > > > +uint16_t > > > > > > +len) { > > > > > > + if (unlikely(len > rte_pktmbuf_tailroom(m))) > > > > > > + return NULL; > > > > > > + > > > > > > + char *tail =3D (char *)m->buf_addr + m->data_off + m- > > >data_len; > > > > > > + m->data_len =3D (uint16_t)(m->data_len + len); > > > > > > + m_head->pkt_len =3D (m_head->pkt_len + len); > > > > > > + return tail; > > > > > > +} > > > > > > > > > > Is it reasonable to direct add data_len of rte_mbuf? > > > > > > > > > > > > > Do you suggest to add directly without checking there is enough > > > > room in the mbuf? We cannot rely on the application providing mbuf > > > > with enough tailroom. > > > > > > What I mentioned is this changes about mbuf should move to librte_mbu= f. > > > And it's better to align Olivier Matz. > > > > There is already rte_pktmbuf_append() inside rte_mbuf.h. > > Wouldn't it suit? > > >=20 > Hi Ananyev, Rosen, > I agree that this can be confusing at first look and notably compared to = packet > processing. > Note first that this same existing syntaxwhich is already used in all bb= dev PMDs > when manipulating outbound mbufs in the context of base band signal > processing (not really a packet as for NIC or other devices). > Nothing new in that very PMD as this follows existing logic already in DP= DK > bbdev PMDs. >=20 > This function basically differs from the typical rte_pktmbuf_append() as = this is > not appending data in the last mbuf but is used to potentially update > sequentially data for any mbufs in the middle from preallocated data henc= e it > takes 2 arguments for both the head and the current mbuf segment in the l= ist. > There may be a more elegant way to do this down the line notably once the= re is > a proposal to handle gracefully large mbufs (another usecase we have to h= andle > in a slightly custom way). But I believe that is orthogonal to that very = PMD serie > which keeps on reling on using existing logic. >=20 >=20 >=20 >=20 > > > > > > > In case you ask about the 2 mbufs, this is because this function > > > > is used to also support segmented memory made of multiple mbufs > segments. > > > > Note that this function is also used in other existing bbdev PMDs. > > > > In case you believe there is a better way to do this, we can > > > > certainly discuss and change these in several PMDs through another = serie. > > > > > > > > Thanks for all the reviews and useful comments. > > > > Nic