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 D5FA8A034C; Wed, 31 Aug 2022 21:26:13 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 805E940684; Wed, 31 Aug 2022 21:26:13 +0200 (CEST) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mails.dpdk.org (Postfix) with ESMTP id 05B4B40395 for ; Wed, 31 Aug 2022 21:26:11 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1661973971; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=TXmzGwcwuCIWj3jAIMja/Ibe4YaWlBqTrM7k/4TrHno=; b=N4NvxhzlVFFQyEvz4O6BuT32phMraeQfuX4H3ldrskv7YqmiYfGAct4hbOqx0g+YlveODS jJuEG5W/Ld6G8xrqe1/2HlcrTUzhtCAtdPmZgCyi+UCaBktNepiV/nrMHRsnuMM/m8MX4e V6CokZivXWY19+igXnQlqDsTsTsBmVE= Received: from mail-qv1-f69.google.com (mail-qv1-f69.google.com [209.85.219.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-660-Tgxb0bpIN92lK8D_hA5Rtw-1; Wed, 31 Aug 2022 15:26:09 -0400 X-MC-Unique: Tgxb0bpIN92lK8D_hA5Rtw-1 Received: by mail-qv1-f69.google.com with SMTP id mr4-20020a056214348400b00498fa61c57bso7163118qvb.0 for ; Wed, 31 Aug 2022 12:26:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-language:content-transfer-encoding:in-reply-to:mime-version :user-agent:date:message-id:from:references:cc:to:subject :x-gm-message-state:from:to:cc; bh=TXmzGwcwuCIWj3jAIMja/Ibe4YaWlBqTrM7k/4TrHno=; b=Ki58ujNNrv5n2gaTDKfl9uScpHmMuuDeAP8mNWP5WbbX/CBDd9WZcEBNrz4XAj3Vh2 quk/iVmtDvnUd5YUKOLz6v0Hhgijvkn18pjKLSsNAAwa0QaKaPDHMPOG964lDqDojqlW RFR6/A9FbqMBAEwvdP12kxu3BQ8E5mcglPJnVLTRU9oPhFDhYM5vyabvOcw4OaCxfU3o Na8zkP/ItTSradjTAL+vdj6S95hP1LZ/RIVp91msIARZOmPd1ys4FL8bqi6KuNLP/VWc Y5VCtHjCoqucb0yBZWDXwldGWg2ZmvoIk7sOuOeab9mgjXLlYYLR8tWQ5EiqkBipeTxR PMLg== X-Gm-Message-State: ACgBeo055PDbWac6Xd0o6AH4aR/QsUkYI9/MoE5NCJJYYHy47+Ncqvxq uXqhsl8n79Y5k6+C6qWsJLbtoz2vMFpg9de5GEF2Er4jmIrfVJnBy7ziFY3oRvuACgp9sUr5y0c B2rw= X-Received: by 2002:ac8:5cd2:0:b0:343:557e:98a9 with SMTP id s18-20020ac85cd2000000b00343557e98a9mr20342216qta.658.1661973969152; Wed, 31 Aug 2022 12:26:09 -0700 (PDT) X-Google-Smtp-Source: AA6agR6GYwVAemxM/aH+2Fai1KqHgkQP9Q5LI5wrehSrrLKFpzJqeWSJtUMMVSidkOviDECUaYEiBQ== X-Received: by 2002:ac8:5cd2:0:b0:343:557e:98a9 with SMTP id s18-20020ac85cd2000000b00343557e98a9mr20342181qta.658.1661973968613; Wed, 31 Aug 2022 12:26:08 -0700 (PDT) Received: from localhost.localdomain (024-205-208-113.res.spectrum.com. [24.205.208.113]) by smtp.gmail.com with ESMTPSA id ge17-20020a05622a5c9100b003430589dd34sm9113252qtb.57.2022.08.31.12.26.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 31 Aug 2022 12:26:07 -0700 (PDT) Subject: Re: [PATCH v1 00/10] baseband/acc200 To: "Chautru, Nicolas" , Maxime Coquelin , "dev@dpdk.org" , "thomas@monjalon.net" , "gakhil@marvell.com" , "hemant.agrawal@nxp.com" , "Vargas, Hernan" Cc: "mdr@ashroe.eu" , "Richardson, Bruce" , "david.marchand@redhat.com" , "stephen@networkplumber.org" References: <1657238503-143836-1-git-send-email-nicolas.chautru@intel.com> <9087aa5a-6ba8-5df2-8a68-63926843ff7e@redhat.com> <5144a909-7e19-bcda-7bae-89b42fff100c@redhat.com> From: Tom Rix Message-ID: <85c41e33-ae4b-2b58-ccea-f951eb2bfd69@redhat.com> Date: Wed, 31 Aug 2022 12:26:04 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US 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 On 8/30/22 12:45 PM, 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 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. > 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! Nic, I used a similarity checker to compare acc100 and acc200 https://dickgrune.com/Programs/similarity_tester/ l=simum.log if [ -f $l ]; then     rm $l fi sim_c -s -R -o$l -R -p -P -a . There results are ./acc200/acc200_pf_enum.h consists for 100 % of ./acc100/acc100_pf_enum.h material ./acc100/acc100_pf_enum.h consists for 98 % of ./acc200/acc200_pf_enum.h material ./acc100/rte_acc100_pmd.h consists for 98 % of ./acc200/acc200_pmd.h material ./acc200/acc200_vf_enum.h consists for 95 % of ./acc100/acc100_pf_enum.h material ./acc200/acc200_pmd.h consists for 92 % of ./acc100/rte_acc100_pmd.h material ./acc200/rte_acc200_cfg.h consists for 92 % of ./acc100/rte_acc100_cfg.h material ./acc100/rte_acc100_pmd.c consists for 87 % of ./acc200/rte_acc200_pmd.c material ./acc100/acc100_vf_enum.h consists for 80 % of ./acc200/acc200_pf_enum.h material ./acc200/rte_acc200_pmd.c consists for 78 % of ./acc100/rte_acc100_pmd.c material ./acc100/rte_acc100_cfg.h consists for 75 % of ./acc200/rte_acc200_cfg.h material Spot checking the first *pf_enum.h at 100%, these are the devices' registers, they are the same. I raised this similarity issue with 100 vs 101. Having multiple copies is difficult to support and should be avoided. For the end user, they should have to use only one driver. Tom > > Thanks > Nic > > >> Maxime >> >>> Thanks, >>> Maxime