From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
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 <dev@dpdk.org>; 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" <nicolas.chautru@intel.com>
To: "dev@dpdk.org" <dev@dpdk.org>, "thomas@monjalon.net"
 <thomas@monjalon.net>, "gakhil@marvell.com" <gakhil@marvell.com>,
 "hemant.agrawal@nxp.com" <hemant.agrawal@nxp.com>
CC: "maxime.coquelin@redhat.com" <maxime.coquelin@redhat.com>,
 "trix@redhat.com" <trix@redhat.com>, "mdr@ashroe.eu" <mdr@ashroe.eu>,
 "Richardson, Bruce" <bruce.richardson@intel.com>, "david.marchand@redhat.com"
 <david.marchand@redhat.com>, "stephen@networkplumber.org"
 <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: <BY5PR11MB44516D5D773277B7C732A13EF8689@BY5PR11MB4451.namprd11.prod.outlook.com>
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 <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=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 <nicolas.chautru@intel.com>
> 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 <bruce.richardson@intel.com>;
> david.marchand@redhat.com; stephen@networkplumber.org; Chautru,
> Nicolas <nicolas.chautru@intel.com>
> 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