Message ID | 1657150110-69957-1-git-send-email-nicolas.chautru@intel.com (mailing list archive) |
---|---|
Headers |
Return-Path: <dev-bounces@dpdk.org> X-Original-To: patchwork@inbox.dpdk.org Delivered-To: patchwork@inbox.dpdk.org Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 6A422A0540; Thu, 7 Jul 2022 01:42:45 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 02E1940A7B; Thu, 7 Jul 2022 01:42:45 +0200 (CEST) Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by mails.dpdk.org (Postfix) with ESMTP id 75B0440691 for <dev@dpdk.org>; Thu, 7 Jul 2022 01:42:43 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1657150963; x=1688686963; h=from:to:cc:subject:date:message-id:in-reply-to: references; bh=WknHZnnAz3jw+FD3N8H1Y3m9Up1MokYc6N2hsm8jBU0=; b=gDsaDkj/BG0tNuETwTTbKjQaXdgJ4rOayK4OaodP/7DbOdvBlCEdkNIc cToeSuCUngNJb5wk9G60NpE/G++DccNn90OsyjLJY8HCP42GQa4crnOev 4+x3t5ZMSudZ2QdZkvHmO9YNavmv8yU9YMVRu6jE9VxnqYrg2mmT7xwxO irtIPc3WHU+AWKiijol34wl3J2rEJY7a/tZQqPsTjK+uO4WejD7G4L6O3 fqqQ2opZMtuPW5ulc517K04gfnHedOdvMau5SgwtYb/G3dkNRWhMmMwzk gDoKUh7GmTbV9D4NZ7WH3LKri3eTf36XHKXkubDPISae25irvZXyOQ/eS g==; X-IronPort-AV: E=McAfee;i="6400,9594,10400"; a="370210629" X-IronPort-AV: E=Sophos;i="5.92,251,1650956400"; d="scan'208";a="370210629" Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Jul 2022 16:42:42 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.92,251,1650956400"; d="scan'208";a="770221906" Received: from skx-5gnr-sc12-4.sc.intel.com ([172.25.69.210]) by orsmga005.jf.intel.com with ESMTP; 06 Jul 2022 16:42:41 -0700 From: Nicolas Chautru <nicolas.chautru@intel.com> 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, bruce.richardson@intel.com, david.marchand@redhat.com, stephen@networkplumber.org, Nicolas Chautru <nicolas.chautru@intel.com> Subject: [PATCH v5 0/7] bbdev changes for 22.11 Date: Wed, 6 Jul 2022 16:28:23 -0700 Message-Id: <1657150110-69957-1-git-send-email-nicolas.chautru@intel.com> X-Mailer: git-send-email 1.8.3.1 In-Reply-To: <1655491040-183649-6-git-send-email-nicolas.chautru@intel.com> References: <1655491040-183649-6-git-send-email-nicolas.chautru@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 |
Series |
bbdev changes for 22.11
|
|
Message
Nicolas Chautru
July 6, 2022, 11:28 p.m. UTC
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 status 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 summer. Thanks Nic
Comments
Hi Hemant, Could you please provide a +1 for that serie please? This has been under review for a while but would like to get it merged soon if possible. I believe you had already reviewed and acked a previous version. Much appreciated, thanks, 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 > > 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 status > 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 summer. > Thanks > Nic > > -- > > Hi, > > 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 > > 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. > > --- > > Previous cover letters agregated below: > > * bbdev: add device status info > https://patches.dpdk.org/project/dpdk/list/?series=23367 > > 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. > > * bbdev: add new operation for FFT processing > https://patches.dpdk.org/project/dpdk/list/?series=22111 > > 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 processing > acceleration. This operates in the same lookaside fashion as other existing > bbdev operation with a dedicated set of capabilities and parameters (marked > as experimental). > > I plan to also include a new PMD supporting this operation (and most of the > related capabilities) in the next couple of months (either in 22.06 or 22.09) as > well as extending the related bbdev-test. > > * bbdev: add device info on queue topology > https://patches.dpdk.org/project/dpdk/list/?series=22076 > > Addressing an historical concern that the device info struct only imperfectly > captured what queues are available on the device (number of operation and > priority). This ended up being an iterative process for application to find each > queue could be configured. > > 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 > */ > > This is now being exposed explictly based on the what the device actually > supports using the existing info_get api > > * bbdev: allow operation type enum for growth > https://patches.dpdk.org/project/dpdk/list/?series=23509 > > 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 future- > 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 handle > 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) > > There is also the intent to be able to expose information for each operation > 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/ > > Basically we are considering best way to accomodate for this, notably based > on discussions with Ray Kinsella and Bruce Richardson, to handle such a case > moving forward: specifically for the example with > RTE_BBDEV_OP_TYPE_COUNT and also more generally. > > One possible option is captured in that patchset and is basically based on the > simple principle to allow for growth and prevent ABI breakage. Ie. the last > value of the enum is set with a higher value than required so that to allow > 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 enum > value, that extended size could be exposed as an #define outside of the > enum but would be fundamentally the same (public). > > 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 access > 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(). > > Some pros and cons, arguably the simple option in that patchset is a valid > compromise option and a step in the right direction but we would like to > know your view wrt best recommendation, or any other thought. > > > > 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 > > 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(-) > > -- > 1.8.3.1