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 D976BA00C3; Mon, 15 Aug 2022 19:55:03 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 9D9144014F; Mon, 15 Aug 2022 19:55:02 +0200 (CEST) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by mails.dpdk.org (Postfix) with ESMTP id 117F740146 for ; Mon, 15 Aug 2022 19:55:00 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1660586101; x=1692122101; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=kASLQEl9u4FEkYuwF3+13YU3T6HaX9gNAyX5uMaT23Y=; b=Ys/wzuWzy7Yd3BkKBYfETte2gGti76MxwXoXHfnCmJqHp/4KUbpW9e+V WVkjMKpVLj1gxjj+cBeA7Vv2gOpdrD5gjZQenxeYxHyXTsHX7wZvYp3t6 6fAHSRu1XtXgRLbjZWW2JkUiulRm/+LkSg0nlUbkwObS0XoaGhrx8vs8j Uj+8SF1MWAfrZwupIVo5vP26Q7UwZNcR8NOjnVanBGY3TGAI38Knp4z/k iqPPic+lbHk7YORrBFOlK4vBOd9TworOCmmw8LAG8upRDQV0MJnUyo5p5 cpo7lbOb4qW9wJFxDaITNixXeM8Jk2+Kwp9f6wIxkCBjErWicAnzpiyww Q==; X-IronPort-AV: E=McAfee;i="6400,9594,10440"; a="292021700" X-IronPort-AV: E=Sophos;i="5.93,238,1654585200"; d="scan'208";a="292021700" Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Aug 2022 10:54:59 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.93,238,1654585200"; d="scan'208";a="749013876" Received: from orsmsx601.amr.corp.intel.com ([10.22.229.14]) by fmsmga001.fm.intel.com with ESMTP; 15 Aug 2022 10:54:59 -0700 Received: from orsmsx607.amr.corp.intel.com (10.22.229.20) by ORSMSX601.amr.corp.intel.com (10.22.229.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.28; Mon, 15 Aug 2022 10:54:59 -0700 Received: from orsmsx612.amr.corp.intel.com (10.22.229.25) by ORSMSX607.amr.corp.intel.com (10.22.229.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.28; Mon, 15 Aug 2022 10:54:58 -0700 Received: from orsedg603.ED.cps.intel.com (10.7.248.4) by orsmsx612.amr.corp.intel.com (10.22.229.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.28 via Frontend Transport; Mon, 15 Aug 2022 10:54:55 -0700 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (104.47.56.174) by edgegateway.intel.com (134.134.137.100) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2375.28; Mon, 15 Aug 2022 10:54:55 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KN1Wcs2NJphb0UkEjowlVCews7OODoxYfdvuhOjWvTzhi4dcT4WvMzQ1Aw8SFyvhU80nHZ9W+tu9Bed8EucN2e/mkKGq3+Qrw/JRxgG086FFFO7xP6whc/DvbPNRTRNbgC8yA5GVdRmN0MbxC4t6nu+deD5UrtvSzsUOBwO45Yc5dlxrJVdFyn0OMGCgkpUbRbJ6TtnXtAEcb5bsrenDAjZmTE1ykTxfJum+2TJvckby8Uk+zlSdVjsi+gz6jmzeaNawhDOqDldfsIN0ffrYPr4V6XDZ4qRLWFfLMW3FdobJ8rnucyPcrUwi0pCKsvJwdKVqedhyuaV2+VI+m9K39A== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=K6KZFDyKlSbWJ4EGe+tPNpeZwSeGFR9BWiMcp6ei0Ho=; b=LHkmGJIlvTlYlUiHjqUQ50wuXVermMGL6pEvWjDkmOd54o7GbUmr1ATqju7LddC+duBvaaKsE4nfLNkzdLbqMmDvw7pginqgwAQ9dWgJAcnz4VpXu7GsMcAKIWd2/LGtQTEce24eq40ZunliQGD3TtDZu7IUTY7crmcxs1crl1Yqt5u/fmAdQf2A7aQhSB1o0rC1SH2JUdLanpIinGzfIekYuT8Fd7PZfWOtf2TQyKj0xo+zYcVbNhVbDH04hfblJ2+KY7AMFpM23LDLRJm3twQ9nIz+XuBcpmCzVK3va5BYo7ZP5bLk0cKBjPdHnDENoZOwgyQVDgSJDAgc0Wr/GA== 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 Received: from BY5PR11MB4451.namprd11.prod.outlook.com (2603:10b6:a03:1cb::30) by DM6PR11MB4689.namprd11.prod.outlook.com (2603:10b6:5:2a0::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5525.10; Mon, 15 Aug 2022 17:54:52 +0000 Received: from BY5PR11MB4451.namprd11.prod.outlook.com ([fe80::1836:7b0f:fcdc:8566]) by BY5PR11MB4451.namprd11.prod.outlook.com ([fe80::1836:7b0f:fcdc:8566%7]) with mapi id 15.20.5525.011; Mon, 15 Aug 2022 17:54:52 +0000 From: "Chautru, Nicolas" To: "dev@dpdk.org" , "thomas@monjalon.net" , "gakhil@marvell.com" , "hemant.agrawal@nxp.com" CC: "maxime.coquelin@redhat.com" , "trix@redhat.com" , "mdr@ashroe.eu" , "Richardson, Bruce" , "david.marchand@redhat.com" , "stephen@networkplumber.org" Subject: RE: [PATCH v5 0/7] bbdev changes for 22.11 Thread-Topic: [PATCH v5 0/7] bbdev changes for 22.11 Thread-Index: AQHYkZIZ0dSC3ClvHk+Zcc2RYXBnuK2wfKEw Date: Mon, 15 Aug 2022 17:54:52 +0000 Message-ID: References: <1655491040-183649-6-git-send-email-nicolas.chautru@intel.com> <1657150110-69957-1-git-send-email-nicolas.chautru@intel.com> In-Reply-To: <1657150110-69957-1-git-send-email-nicolas.chautru@intel.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.6.500.17 authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=intel.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 77862245-ff30-4a82-e17b-08da7ee74123 x-ms-traffictypediagnostic: DM6PR11MB4689:EE_ x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: YIhHUvMdBEk3e1Yq0lkSK5W4CSM6dXvkNgR5BM89uFGAbqfq97omYw+f/VN0qCvyUXvxhCnDVbA2Qc77EyQE3KAKbjv8Jh0CC8fKL+Ru4+pz5jKrR7Gypp6b+w28jrtB1Olid0kMSKJD7M1FG94xoJXhsoTkpGPM8yjcVhlwxEQlvFvpEExVxE7SlyoVfujpXWDKjwhffeGthI6ibskrlJg3jcGeOdIZQs9+34oTSND15fuB8+skcE8oegYLUD2rqWkkp3cBhUjwCvJIdrmYIhBvQFgeY6aFCKqumN3zVp+PkTCUhIQLtRYBK0b9UkZ0BVB+4d4hIc3yFDNedgrGW8kbjCbhxrTHfk6I/Qolrc4xZC2n2YcROzB+XscAHhgIhWXl6RkW+6hx1anz79xtq3z9AtXLh+n0Wh0VXXlnxMkjCeYe794Q58HYEnB4hsiUxIsHlmfYJPU6bUt71jBE3FRxLN38uJHxGgRCqVkZKRPVPvVC3KnfoiaEAfuRsU4ySEcnO8i3DtlZsiWRRXdEY6nZHzIm8VbBwgK6oBBDOH/EWXTna5pz1fFZzcqqnxHF1O59XNe53E7hraVdBqCJISBKTQ3ru7kjWSUQEWjCgMJRunePlRWGNfoa7uFvbH2cpBCE8B8wIiq0u4zIX+teDE2S3rLM05zleiY4fFTw8QqlkYwtku/cEIdd2N8ZS5hwEF83FI80lDTbueICjXtmbW1KvKF+AvmgaoS8su8yH6XlBvezUYnQcV+KQ9/dn16VpWXuhRsLnnQxDGbWRFPAIizYNTFORlwCPkV+1tQOgqK0/RWMyfadSntfKP/ARMIgjj0VUrwCT9IyI4kgXV6I3oAIrYRX22C07Ra2MfhuB9KMCGRSJk8u2ip92S1c/etJ 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:(13230016)(376002)(366004)(396003)(346002)(39860400002)(136003)(83380400001)(82960400001)(186003)(55016003)(71200400001)(478600001)(38100700002)(966005)(316002)(41300700001)(76116006)(66556008)(52536014)(5660300002)(38070700005)(54906003)(33656002)(9686003)(2906002)(122000001)(66446008)(7696005)(66946007)(8936002)(26005)(4326008)(66476007)(64756008)(110136005)(53546011)(8676002)(86362001)(6506007); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?rPf6TMzGI3nOzizeS2YmcXxkoRlX9vIgPQ3tCawuLIJq3mEw8d/WpPfg7lvq?= =?us-ascii?Q?5TjN/Kvj08KrEX8jd3bwyQci648R2Pzq9Mk5lsLH9Xtnw9jwRGYpr0Csxjf4?= =?us-ascii?Q?gIfeNoVMXrYpDeAu1zv1mZcoWfNZIYlkddYZ6GzUMkdul59T3DREyTmS6GU7?= =?us-ascii?Q?xffPIC8W2cgRnkoZTOLp+x31Phmherqz2UJxCyp0kEduziAR8gDd/ZKbGAbN?= =?us-ascii?Q?5Bop/Ku+u7yxjGQ/vEB1ZzkdLzwd+FUhNS7qIgfbZ3qqDuptXf3WMiv2/cat?= =?us-ascii?Q?FUY4dc58lTalEN+k2ki1lkHthn+zCUFKzmOntcGO7678Yw/Zob1NAiuXKGOA?= =?us-ascii?Q?BwlP3a8eh7mP3+Y3vG2bEQIVXYnkiqq22L5809u/YcqvIjH0RwyriaVjw0mT?= =?us-ascii?Q?jSxLWTA+xXSzqPQadaZU6ZvElFPgaMqEhFkIsZrl4RvWXwguIsP0tLtqjh1V?= =?us-ascii?Q?EcF/mAkUkQoNAg5bS7Foy+JRmo4myu2IVZFsgqyJOoS+m61zgJqcqAZ4A/i7?= =?us-ascii?Q?ACocK1hBX2JVds1UJ2PY+jsCvbXWp0EYX9WoGvtxfKmRGhZO7EsXIYTr+jN/?= =?us-ascii?Q?VqJ5o6Gns1tpnxEZjobSU6FBMfvN7zXbsgob1StZCissp43dmHGwYhj1N8+w?= =?us-ascii?Q?dkSf3BHNpy0bHRyytEtoCwFZdqJgZyk9ba8fTUeLeV9Ttj6Q8IaEpyHPV1Tp?= =?us-ascii?Q?NqTfGHjpeqF5V55F5hkFd9pyz+NX6Eku2Oz0tj+kGf17aUEPbbFQ/eOhAz5F?= =?us-ascii?Q?B36vk+d+pRHjZQMxxP3HVnO7+uX/0piMSQZEuRM1WNJLgMlWkSmB1JLBb57w?= =?us-ascii?Q?2YtEgroC3F4xL+cEOe87wYAjJyjA21fUHm1rmyPs1qHGTbPlZ8F+15DPxsIc?= =?us-ascii?Q?WKhRI5NnMJ5AaI/4gdYlQ0I0WB4+VXBnmHe/n0wlgEOh32+N5il5JI6NxIBI?= =?us-ascii?Q?iNZSYRHfBKC6osj59YhBpPBFeeFrjNQSgqDmWMo+bpP/6XuiC5Jfoakk3VJK?= =?us-ascii?Q?1fHhIOyEYfBvXWDq8XfQOgWENmyWSfhByyDulK2oRv59ZB4KLyTCXhm/gs8P?= =?us-ascii?Q?nLz7Lgmo2y0HnZwhErasR1b0jA9lh8CMvknmcUp5n2kVJoWIDOU2D2pTgAge?= =?us-ascii?Q?msf4gQfQ1KxkgL7GOZgcbhEFDjcbKAjdpbDHYoDwAahH2FmbuVTDdktdb6Fk?= =?us-ascii?Q?UbLZzlNRbXHMiJWYTy+8MXE9a4L7H9oR6Q3x20myNhJjH8E0m52b9M02WHeV?= =?us-ascii?Q?Wp5fjRNC2J2tKXtIlPaVAzVPjknDHkJSdNGoTZynl7S6RVtX/7bS4zHE8U2i?= =?us-ascii?Q?maY3thI+qezEqHi2DS2FWHykZ/qSxA99E5CmcvJaZYiI65R9YdM7myCD8gFY?= =?us-ascii?Q?lSROaN83EcOqGeh+m+kv/qFW7BrzLfkmiAjslIJO58Cr5xF/3tGO9PyYCuwV?= =?us-ascii?Q?RuNiU4p1bYE32PyHIJ/RbUDL5JMBM+Im9PEPJ3bTi7qPSLnXrnkGoJLZAety?= =?us-ascii?Q?g90k7WoxRnYGqReH/0RfcObztkSmtnKqrWArvQoOGhY2Aozb3G4K3OxrXEJr?= =?us-ascii?Q?gfsZq1EjSHstF4pSAoreQsD4c9+8NNlLEJ39YviW?= 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: 77862245-ff30-4a82-e17b-08da7ee74123 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Aug 2022 17:54:52.1449 (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: Xz1lNlxnvD/g3M/ER8/CEFJaI7IEPD2YScDaiNMtztab8B/wY54JaCruGVL1NhE9nlKzJxY9dR6LfWXxvzfdwXlWxD3SYajo0t2S+0Rf5rQ= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB4689 X-OriginatorOrg: intel.com 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 Hi Hemant,=20 Could you please provide a +1 for that serie please? This has been under re= view for a while but would like to get it merged soon if possible. I believ= e you had already reviewed and acked a previous version.=20 Much appreciated, thanks,=20 Nic > -----Original Message----- > From: Chautru, Nicolas > Sent: Wednesday, July 6, 2022 4:28 PM > To: dev@dpdk.org; thomas@monjalon.net; gakhil@marvell.com; > hemant.agrawal@nxp.com > Cc: maxime.coquelin@redhat.com; trix@redhat.com; mdr@ashroe.eu; > Richardson, Bruce ; > david.marchand@redhat.com; stephen@networkplumber.org; Chautru, > Nicolas > Subject: [PATCH v5 0/7] bbdev changes for 22.11 >=20 > v5: update base on review from Tom Rix. Number of typos reported and > resolved, removed the commit related to rw_lock for now, added a commit > for code clean up from review, resolved one rebase issue between 2 > commits, used size of array for some bound check implementation. Thanks. > v4: update to the last 2 commits to include function to print the queue s= tatus > and a fix to the rte_lock within the wrong structure > v3: update to device status info to also use padded size for the related = array. > Adding also 2 additionals commits to allow the API struc to expose more > information related to queues corner cases/warning as well as an optional > rw lock. > Hemant, Maxime, this is planned for DPDK 21.11 but would like review/ack > early is possible to get this applied earlier and due to time off this su= mmer. > Thanks > Nic >=20 > -- >=20 > Hi, >=20 > Agregating together in a single serie a number of bbdev api changes > previously submitted over the last few months and all targeted for 22.11 = (4 > different series detailed below). Related deprecation notice being pushed= in > 22.07 in parallel. > * bbdev: add device status info > * bbdev: add new operation for FFT processing > * bbdev: add device info on queue topology > * bbdev: allow operation type enum for growth >=20 > v2: Update to the RTE_BBDEV_COUNT removal based on feedback from > Thomas/Stephen : rejecting out of range op type and adjusting the new > name for the padded maximum value used for fixed size arrays. >=20 > --- >=20 > Previous cover letters agregated below: >=20 > * bbdev: add device status info > https://patches.dpdk.org/project/dpdk/list/?series=3D23367 >=20 > The updated structure will allow PMDs to expose through info_get what be > may the status of the underlying accelerator, notably in case an HW error > event having happened. >=20 > * bbdev: add new operation for FFT processing > https://patches.dpdk.org/project/dpdk/list/?series=3D22111 >=20 > This contribution adds a new operation type to the existing ones already > supported by the bbdev PMDs. > This set of operation is FFT-based processing for 5GNR baseband processin= g > acceleration. This operates in the same lookaside fashion as other existi= ng > bbdev operation with a dedicated set of capabilities and parameters (mark= ed > as experimental). >=20 > I plan to also include a new PMD supporting this operation (and most of t= he > related capabilities) in the next couple of months (either in 22.06 or 22= .09) as > well as extending the related bbdev-test. >=20 > * bbdev: add device info on queue topology > https://patches.dpdk.org/project/dpdk/list/?series=3D22076 >=20 > Addressing an historical concern that the device info struct only imperfe= ctly > captured what queues are available on the device (number of operation and > priority). This ended up being an iterative process for application to fi= nd each > queue could be configured. >=20 > ie. the gap was captured as technical debt previously in comments > /* This isn't ideal because it reports the maximum number of queues but > * does not provide info on how many can be uplink/downlink or different > * priorities > */ >=20 > This is now being exposed explictly based on the what the device actually > supports using the existing info_get api >=20 > * bbdev: allow operation type enum for growth > https://patches.dpdk.org/project/dpdk/list/?series=3D23509 >=20 > This is related to the general intent to remove using MAX value for enums= . > There is consensus that we should avoid this for a while notably for futu= re- > proofed ABI concerns > https://patches.dpdk.org/project/dpdk/patch/20200130142003.2645765-1- > ferruh.yigit@intel.com/. > But still there is arguably not yet an explicit best recommendation to ha= ndle > this especially when we actualy need to expose array whose index is such = an > enum. > As a specific example here I am refering to RTE_BBDEV_OP_TYPE_COUNT in > enum rte_bbdev_op_type which is being extended for new operation type > being support in bbdev (such as > https://patches.dpdk.org/project/dpdk/patch/1646956157-245769-2-git- > send-email-nicolas.chautru@intel.com/ adding new FFT operation) >=20 > There is also the intent to be able to expose information for each operat= ion > type through the bbdev api such as dynamically configured queues > information per such operation type > https://patches.dpdk.org/project/dpdk/patch/1646785355-168133-2-git- > send-email-nicolas.chautru@intel.com/ >=20 > Basically we are considering best way to accomodate for this, notably bas= ed > on discussions with Ray Kinsella and Bruce Richardson, to handle such a c= ase > moving forward: specifically for the example with > RTE_BBDEV_OP_TYPE_COUNT and also more generally. >=20 > One possible option is captured in that patchset and is basically based o= n the > simple principle to allow for growth and prevent ABI breakage. Ie. the la= st > value of the enum is set with a higher value than required so that to all= ow > insertion of new enum outside of the major ABI versions. > In that case the RTE_BBDEV_OP_TYPE_COUNT is still present and can be > exposed and used while still allowing for addition thanks to the implicit > padding-like room. As an alternate variant, instead of using that last en= um > value, that extended size could be exposed as an #define outside of the > enum but would be fundamentally the same (public). >=20 > Another option would be to avoid array alltogether and use each time this= a > new dedicated API function (operation type enum being an input argument > instead of an index to an array in an existing structure so that to get a= ccess > to structure related to a given operation type enum) but that is arguably= not > well scalable within DPDK to use such a scheme for each enums and keep an > uncluttered and clean API. In that very example that would be very odd > indeed not to get this simply from info_get(). >=20 > Some pros and cons, arguably the simple option in that patchset is a vali= d > compromise option and a step in the right direction but we would like to > know your view wrt best recommendation, or any other thought. >=20 >=20 >=20 > Nicolas Chautru (7): > bbdev: allow operation type enum for growth > bbdev: add device status info > bbdev: add device info on queue topology > drivers/baseband: update PMDs to expose queue per operation > bbdev: add new operation for FFT processing > bbdev: add queue related warning and status information > bbdev: remove unnecessary if-check >=20 > app/test-bbdev/test_bbdev.c | 2 +- > app/test-bbdev/test_bbdev_perf.c | 6 +- > doc/guides/prog_guide/bbdev.rst | 130 +++++++++++++++= ++ > drivers/baseband/acc100/rte_acc100_pmd.c | 30 ++-- > drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c | 9 ++ > drivers/baseband/fpga_lte_fec/fpga_lte_fec.c | 9 ++ > drivers/baseband/la12xx/bbdev_la12xx.c | 10 +- > drivers/baseband/null/bbdev_null.c | 1 + > drivers/baseband/turbo_sw/bbdev_turbo_software.c | 12 ++ > examples/bbdev_app/main.c | 2 +- > lib/bbdev/rte_bbdev.c | 57 +++++++- > lib/bbdev/rte_bbdev.h | 149 +++++++++++++++= ++++- > lib/bbdev/rte_bbdev_op.h | 156 +++++++++++++++= +++++- > lib/bbdev/version.map | 11 ++ > 14 files changed, 555 insertions(+), 29 deletions(-) >=20 > -- > 1.8.3.1