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 04E46A034C; Wed, 31 Aug 2022 21:20:15 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 9FECB40684; Wed, 31 Aug 2022 21:20:15 +0200 (CEST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by mails.dpdk.org (Postfix) with ESMTP id 43D2E40395 for ; Wed, 31 Aug 2022 21:20:14 +0200 (CEST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id C8F325C00C2; Wed, 31 Aug 2022 15:20:13 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Wed, 31 Aug 2022 15:20:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm1; t=1661973613; x= 1662060013; bh=GMmo905n0OL1oQ3u+IK+4/Matn0UCYJ23+i5FIEEZeY=; b=I 7WyB6XTIeXvqqXEpEgi85RtRJB265jPTGvYB7drgBESynn/Y1n+lFZWLMxA0Jn3z 3vAraYn6+rXPBFBlKZ28aQWDdpxGRhZ5Uz+w0GSaz6TezTD0myOI/+RgCPaE2lO2 v1+X5+cJ1PieXnov0hdNjxlBCvB7OPCyPNDwd+MVIHgoTw9cmZqbPb2BAKaz2kCy gLaxfXak61ZNcgBuES3slgLN32/8h7tQQf7XzKB/7fdLmrRBNd3XbgcfxZVrJE4c PLZ9iIcyQtI79RQXtcCvmblndf7dt/9ApT/7mkpB4V4FDHt9HTKlVkxvY+kF898s cIUCZcx/9nX1n87yrhZ6w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1661973613; x= 1662060013; bh=GMmo905n0OL1oQ3u+IK+4/Matn0UCYJ23+i5FIEEZeY=; b=D XHpP9VoGneZOf1kpKEG/JHTKgQejO7G1JE4nEed+Pq84IXAe1kenkJ69gedn06W7 WNB10/j9nYg4yxzyfJ1sgpUXb3Y5Ij8tA84sb7WVjlOu7rh0GEPODyV92IOvSNdJ pt6NRo7I9Mi0oFmagDr8O1gG1vJK++SGS56IsyNKfPvh9lt2wjUbhWAwIrfSGOot MX7dUhQ98tUmJUV3xzKCNqOSDdkOjXFP4OlzNJwIJGli0Ni1IrrqwUN8I0TZ0M/c aJcGHGENEA3QGKJuiPGdoBusrZF7liJwB1ZwtaBjuCoRcrPuqWTMz2S4O/GPSawx LqI70HpR54tWaqT1VtsGA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrvdekiedguddtlecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefhvfevufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhho mhgrshcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqne cuggftrfgrthhtvghrnhepjeejffffgfffkeefffelgfekleetjeffleeludeghfehleff teehveduffdugfdvnecuffhomhgrihhnpeguphgukhdrohhrghenucevlhhushhtvghruf hiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhhomhgrshesmhhonhhjrghl ohhnrdhnvght X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 31 Aug 2022 15:20:11 -0400 (EDT) From: Thomas Monjalon To: "Chautru, Nicolas" , "dev@dpdk.org" , "gakhil@marvell.com" , "hemant.agrawal@nxp.com" , "trix@redhat.com" , "Vargas, Hernan" , Maxime Coquelin Cc: "mdr@ashroe.eu" , "Richardson, Bruce" , "david.marchand@redhat.com" , "stephen@networkplumber.org" Subject: Re: [PATCH v1 00/10] baseband/acc200 Date: Wed, 31 Aug 2022 21:20:10 +0200 Message-ID: <14454477.O6BkTfRZtg@thomas> In-Reply-To: References: <1657238503-143836-1-git-send-email-nicolas.chautru@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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 31/08/2022 18:43, Maxime Coquelin: > Hello Nicolas, > > On 8/30/22 21:45, Chautru, Nicolas wrote: > > Hi Maxime, > > > >> -----Original Message----- > >> From: Maxime Coquelin > >> Sent: Tuesday, August 30, 2022 12:45 AM > >> To: Chautru, Nicolas ; dev@dpdk.org; > >> thomas@monjalon.net; gakhil@marvell.com; hemant.agrawal@nxp.com; > >> trix@redhat.com; Vargas, Hernan > >> Cc: mdr@ashroe.eu; Richardson, Bruce ; > >> david.marchand@redhat.com; stephen@networkplumber.org > >> Subject: Re: [PATCH v1 00/10] baseband/acc200 > >> > >> Hi Nicolas, > >> > >> On 7/12/22 15:48, Maxime Coquelin wrote: > >>> Hi Nicolas, Hernan, > >>> > >>> (Adding Hernan in the recipients list) > >>> > >>> On 7/8/22 02:01, Nicolas Chautru wrote: > >>>> This is targeting 22.11 and includes the PMD for the integrated > >>>> accelerator on Intel Xeon SPR-EEC. > >>>> There is a dependency on that parallel serie still in-flight which > >>>> extends the bbdev api > >>>> https://patches.dpdk.org/project/dpdk/list/?series=23894 > >>>> > >>>> I will be offline for a few weeks for the summer break but Hernan > >>>> will cover for me during that time if required. > >>>> > >>>> Thanks > >>>> Nic > >>>> > >>>> Nicolas Chautru (10): > >>>> baseband/acc200: introduce PMD for ACC200 > >>>> baseband/acc200: add HW register definitions > >>>> baseband/acc200: add info get function > >>>> baseband/acc200: add queue configuration > >>>> baseband/acc200: add LDPC processing functions > >>>> baseband/acc200: add LTE processing functions > >>>> baseband/acc200: add support for FFT operations > >>>> baseband/acc200: support interrupt > >>>> baseband/acc200: add device status and vf2pf comms > >>>> baseband/acc200: add PF configure companion function > >>>> > >>>> MAINTAINERS | 3 + > >>>> app/test-bbdev/meson.build | 3 + > >>>> app/test-bbdev/test_bbdev_perf.c | 76 + > >>>> doc/guides/bbdevs/acc200.rst | 244 ++ > >>>> doc/guides/bbdevs/index.rst | 1 + > >>>> drivers/baseband/acc200/acc200_pf_enum.h | 468 +++ > >>>> drivers/baseband/acc200/acc200_pmd.h | 690 ++++ > >>>> drivers/baseband/acc200/acc200_vf_enum.h | 89 + > >>>> drivers/baseband/acc200/meson.build | 8 + > >>>> drivers/baseband/acc200/rte_acc200_cfg.h | 115 + > >>>> drivers/baseband/acc200/rte_acc200_pmd.c | 5403 > >>>> ++++++++++++++++++++++++++++++ > >>>> drivers/baseband/acc200/version.map | 10 + > >>>> drivers/baseband/meson.build | 1 + > >>>> 13 files changed, 7111 insertions(+) > >>>> create mode 100644 doc/guides/bbdevs/acc200.rst > >>>> create mode 100644 drivers/baseband/acc200/acc200_pf_enum.h > >>>> create mode 100644 drivers/baseband/acc200/acc200_pmd.h > >>>> create mode 100644 drivers/baseband/acc200/acc200_vf_enum.h > >>>> create mode 100644 drivers/baseband/acc200/meson.build > >>>> create mode 100644 drivers/baseband/acc200/rte_acc200_cfg.h > >>>> create mode 100644 drivers/baseband/acc200/rte_acc200_pmd.c > >>>> create mode 100644 drivers/baseband/acc200/version.map > >>>> > >>> > >>> Comparing ACC200 & ACC100 header files, I understand ACC200 is an > >>> evolution of the ACC10x family. The FEC bits are really close, ACC200 > >>> main addition seems to be FFT acceleration which could be handled in > >>> ACC10x driver based on device ID. > >>> > >>> I think both drivers have to be merged in order to avoid code > >>> duplication. That's how other families of devices (e.g. i40e) are > >>> handled. > >> > >> I haven't seen your reply on this point. > >> Do you confirm you are working on a single driver for ACC family in order to > >> avoid code duplication? > >> > > > > The implementation is based on distinct ACC100 and ACC200 drivers. The 2 devices are fundamentally different generation, processes and IP. > > MountBryce is an eASIC device over PCIe while ACC200 is an integrated accelerator on Xeon CPU. > > The underlying technology does not matter much. For example we use same > Virtio driver for SW emulated devices and fully HW offloaded ones. > > I have spent some time today comparing the drivers and what I can see is > the ACC200 driver is a copy-paste of the ACC100, modulo FFT addition and > other small changes that I think could be handled dynamically based on > capabilities flags and device ID. > > > The actual implementation are not the same, underlying IP are all distinct even if many of the descriptor format have similarities. > > The actual capabilities of the acceleration are different and/or new. > > New capabilities should be backed by device capabilities flags. > > > The workaround and silicon errata are also different causing different limitation and implementation in the driver (see the serie with ongoing changes for ACC100 in parallel). > > This is fundamentally distinct from ACC101 which was a derivative product from ACC100 and where it made sense to share implementation between ACC100 and ACC101. > > So in a nutshell these 2 devices and drivers are 2 different beasts and the intention is to keep them intentionally separate as in the serie. > > Let me know if unclear, thanks! > > Thanks for the information. > I still think it should be a single driver, I would appreciate a second > opinion. Thomas, Bruce, Stephen, do you have time to have a look? If most code is similar, it should be the same driver.