From: "Chautru, Nicolas" <nicolas.chautru@intel.com>
To: Tom Rix <trix@redhat.com>,
Maxime Coquelin <maxime.coquelin@redhat.com>,
"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>,
"Vargas, Hernan" <hernan.vargas@intel.com>
Cc: "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 v1 00/10] baseband/acc200
Date: Thu, 1 Sep 2022 20:34:06 +0000 [thread overview]
Message-ID: <BY5PR11MB44519BEBAC7F35144B98110DF87B9@BY5PR11MB4451.namprd11.prod.outlook.com> (raw)
In-Reply-To: <f7ce6b84-8c76-4159-89a5-e3f8479b5d99@redhat.com>
Hi Tom,
> -----Original Message-----
> From: Tom Rix <trix@redhat.com>
> Sent: Thursday, September 1, 2022 6:49 AM
> To: Chautru, Nicolas <nicolas.chautru@intel.com>; Maxime Coquelin
> <maxime.coquelin@redhat.com>; dev@dpdk.org; thomas@monjalon.net;
> gakhil@marvell.com; hemant.agrawal@nxp.com; Vargas, Hernan
> <hernan.vargas@intel.com>
> Cc: mdr@ashroe.eu; Richardson, Bruce <bruce.richardson@intel.com>;
> david.marchand@redhat.com; stephen@networkplumber.org
> Subject: Re: [PATCH v1 00/10] baseband/acc200
>
>
> On 8/31/22 6:26 PM, Chautru, Nicolas wrote:
> > Hi Tom,
> >
> >> -----Original Message-----
> >> From: Tom Rix <trix@redhat.com>
> >> Sent: Wednesday, August 31, 2022 5:28 PM
> >> To: Chautru, Nicolas <nicolas.chautru@intel.com>; Maxime Coquelin
> >> <maxime.coquelin@redhat.com>; dev@dpdk.org;
> thomas@monjalon.net;
> >> gakhil@marvell.com; hemant.agrawal@nxp.com; Vargas, Hernan
> >> <hernan.vargas@intel.com>
> >> Cc: mdr@ashroe.eu; Richardson, Bruce <bruce.richardson@intel.com>;
> >> david.marchand@redhat.com; stephen@networkplumber.org
> >> Subject: Re: [PATCH v1 00/10] baseband/acc200
> >>
> >>
> >> On 8/31/22 3:37 PM, Chautru, Nicolas wrote:
> >>> Hi Thomas, Tom,
> >>>
> >>>> -----Original Message-----
> >>>> From: Tom Rix <trix@redhat.com>
> >>>> Sent: Wednesday, August 31, 2022 12:26 PM
> >>>> To: Chautru, Nicolas <nicolas.chautru@intel.com>; Maxime Coquelin
> >>>> <maxime.coquelin@redhat.com>; dev@dpdk.org;
> thomas@monjalon.net;
> >>>> gakhil@marvell.com; hemant.agrawal@nxp.com; Vargas, Hernan
> >>>> <hernan.vargas@intel.com>
> >>>> Cc: mdr@ashroe.eu; Richardson, Bruce <bruce.richardson@intel.com>;
> >>>> david.marchand@redhat.com; stephen@networkplumber.org
> >>>> Subject: Re: [PATCH v1 00/10] baseband/acc200
> >>>>
> >>>>
> >>>> On 8/30/22 12:45 PM, Chautru, Nicolas wrote:
> >>>>> Hi Maxime,
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: Maxime Coquelin <maxime.coquelin@redhat.com>
> >>>>>> Sent: Tuesday, August 30, 2022 12:45 AM
> >>>>>> To: Chautru, Nicolas <nicolas.chautru@intel.com>; dev@dpdk.org;
> >>>>>> thomas@monjalon.net; gakhil@marvell.com;
> hemant.agrawal@nxp.com;
> >>>>>> trix@redhat.com; Vargas, Hernan <hernan.vargas@intel.com>
> >>>>>> Cc: mdr@ashroe.eu; Richardson, Bruce
> >>>>>> <bruce.richardson@intel.com>; 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.
> >>>>
> >>> There are really different IP and do not have the same interface
> >>> (PCIe/DDR vs
> >> integrated) and there is big serie of changes which are specific to
> >> ACC100 coming in parallel. Any workaround, optimization would be
> different.
> >>> I agree that for the coming serie of integrated accelerator we will
> >>> use a
> >> unified driver approach but for that very case that would be quite
> >> messy to artificially put them within the same PMD.
> >>
> >> How is the IP different when 100% of the registers are the same ?
> >>
> > These are 2 different HW aspects. The base toplevel configuration registers
> are kept similar on purpose but the underlying IP are totally different design
> and implementation.
> > Even the registers have differences but not visible here, the actual RDL file
> would define more specifically these registers bitfields and implementation
> including which ones are not implemented (but that is proprietary
> information), and at bbdev level the interface is not some much register
> based than processing based on data from DMA.
> > Basically even if there was a common driver, all these would be duplicated
> and they are indeed different IP (including different vendors)..
> > But I agree with the general intent and to have a common driver for the
> integrated driver serie (ACC200, ACC300...) now that we are moving away
> from PCIe/DDR lookaside acceleration and eASIC/FPGA implementation
> (ACC100/AC101).
>
> Looking a little deeper, at how the driver is lays out some of its bitfields and
> private data by reviewing the
>
> ./acc200/acc200_pmd.h consists for 92 % of ./acc100/rte_acc100_pmd.h
>
> There are some minor changes to existing reserved bitfields.
> A new structure for fft.
> The acc200_device, the private data for the driver, is an exact copy of
> acc100_device.
>
> acc200_pmd.h is the superset and could be used with little changes as a
> common acc_pmd.h.
> acc200 is doing everything the acc100 did in a very similar if not exact way,
> adding the fft feature.
>
> Can you point to some portion of this patchset that is so unique that it could
> not be abstracted to an if-check or function and so requiring this separate,
> nearly identical driver ?
>
You used a similarity checker really, there are actually way more relevent differences than what you imply here.
With regards to the 2 pf_enum.h file, there are many registers that have same or similar names but have now different values being mapped hence you just cannot use one for the other.
Saying that "./acc200/acc200_pmd.h consists for 92 % of ./acc100/rte_acc100_pmd.h" is just not correct and really irrelevant.
Just do a diff side by side please and check, that should be extremely obvious, that metrics tells more about the similarity checker limitation than anything else.
Even when using a common driver for ACC200/300 they will have distinct register enum files being auto-generated and coming from distinct RDL.
Again just do a diff of these 2 files. I believe you will agree that is not relevant for these files to try to artificially merged these together.
With regards to the pmd.h, some structure/defines are indeed common and could be moved to a common file (for instance turboencoder and LDPC encoder which are more vanilla and unlikely to change for future product unlike the decoders which have different feature set and behaviour; or some 3GPP constant that can be defined once).
We can definitely change these to put together shared structures/defines, but not intending to try to artificially put things together with spaghetti code.
We would like to keep 3 parallel versions of these PMD for 3 different product lines which are indeed fundamentally different designs (including different workaround required as can be seen on the parallel ACC100 serie under review).
- one version for FPGA implementation (support for N3000, N6000, ...)
- one version for eASIC lookaside card implementation (ACC100, ACC101, ...)
- one version for the integrated Xeon accelerators (ACC200, ACC300, ...)
Let me know if unclear
Nic
> Tom
>
>
>
> >> Tom
> >>
> >>>
next prev parent reply other threads:[~2022-09-01 20:34 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-08 0:01 Nicolas Chautru
2022-07-08 0:01 ` [PATCH v1 01/10] baseband/acc200: introduce PMD for ACC200 Nicolas Chautru
2022-09-12 1:08 ` [PATCH v2 00/11] baseband/acc200 Nic Chautru
2022-09-12 1:08 ` [PATCH v2 01/11] baseband/acc100: refactory to segregate common code Nic Chautru
2022-09-12 15:19 ` Bruce Richardson
2022-09-12 1:08 ` [PATCH v2 02/11] baseband/acc200: introduce PMD for ACC200 Nic Chautru
2022-09-12 15:41 ` Bruce Richardson
2022-09-12 1:08 ` [PATCH v2 03/11] baseband/acc200: add HW register definitions Nic Chautru
2022-09-12 1:08 ` [PATCH v2 04/11] baseband/acc200: add info get function Nic Chautru
2022-09-12 1:08 ` [PATCH v2 05/11] baseband/acc200: add queue configuration Nic Chautru
2022-09-12 1:08 ` [PATCH v2 06/11] baseband/acc200: add LDPC processing functions Nic Chautru
2022-09-12 1:08 ` [PATCH v2 07/11] baseband/acc200: add LTE " Nic Chautru
2022-09-12 1:08 ` [PATCH v2 08/11] baseband/acc200: add support for FFT operations Nic Chautru
2022-09-12 1:08 ` [PATCH v2 09/11] baseband/acc200: support interrupt Nic Chautru
2022-09-12 1:08 ` [PATCH v2 10/11] baseband/acc200: add device status and vf2pf comms Nic Chautru
2022-09-12 1:08 ` [PATCH v2 11/11] baseband/acc200: add PF configure companion function Nic Chautru
2022-07-08 0:01 ` [PATCH v1 02/10] baseband/acc200: add HW register definitions Nicolas Chautru
2022-07-08 0:01 ` [PATCH v1 03/10] baseband/acc200: add info get function Nicolas Chautru
2022-07-08 0:01 ` [PATCH v1 04/10] baseband/acc200: add queue configuration Nicolas Chautru
2022-07-08 0:01 ` [PATCH v1 05/10] baseband/acc200: add LDPC processing functions Nicolas Chautru
2022-07-08 0:01 ` [PATCH v1 06/10] baseband/acc200: add LTE " Nicolas Chautru
2022-07-08 0:01 ` [PATCH v1 07/10] baseband/acc200: add support for FFT operations Nicolas Chautru
2022-07-08 0:01 ` [PATCH v1 08/10] baseband/acc200: support interrupt Nicolas Chautru
2022-07-08 0:01 ` [PATCH v1 09/10] baseband/acc200: add device status and vf2pf comms Nicolas Chautru
2022-07-08 0:01 ` [PATCH v1 10/10] baseband/acc200: add PF configure companion function Nicolas Chautru
2022-07-12 13:48 ` [PATCH v1 00/10] baseband/acc200 Maxime Coquelin
2022-07-14 18:49 ` Vargas, Hernan
2022-07-17 13:08 ` Tom Rix
2022-07-22 18:29 ` Vargas, Hernan
2022-07-22 20:19 ` Tom Rix
2022-08-15 17:52 ` Chautru, Nicolas
2022-08-30 7:44 ` Maxime Coquelin
2022-08-30 19:45 ` Chautru, Nicolas
2022-08-31 16:43 ` Maxime Coquelin
2022-08-31 19:20 ` Thomas Monjalon
2022-08-31 19:26 ` Tom Rix
2022-08-31 22:37 ` Chautru, Nicolas
2022-09-01 0:28 ` Tom Rix
2022-09-01 1:26 ` Chautru, Nicolas
2022-09-01 13:49 ` Tom Rix
2022-09-01 20:34 ` Chautru, Nicolas [this message]
2022-09-06 12:51 ` Tom Rix
2022-09-14 10:35 ` Thomas Monjalon
2022-09-14 11:50 ` Maxime Coquelin
2022-09-14 13:19 ` Bruce Richardson
2022-09-14 13:27 ` Maxime Coquelin
2022-09-14 13:44 ` [EXT] " Akhil Goyal
2022-09-14 14:23 ` Thomas Monjalon
2022-09-14 19:57 ` Chautru, Nicolas
2022-09-14 20:08 ` Maxime Coquelin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=BY5PR11MB44519BEBAC7F35144B98110DF87B9@BY5PR11MB4451.namprd11.prod.outlook.com \
--to=nicolas.chautru@intel.com \
--cc=bruce.richardson@intel.com \
--cc=david.marchand@redhat.com \
--cc=dev@dpdk.org \
--cc=gakhil@marvell.com \
--cc=hemant.agrawal@nxp.com \
--cc=hernan.vargas@intel.com \
--cc=maxime.coquelin@redhat.com \
--cc=mdr@ashroe.eu \
--cc=stephen@networkplumber.org \
--cc=thomas@monjalon.net \
--cc=trix@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).