DPDK patches and discussions
 help / color / mirror / Atom feed
From: Thomas Monjalon <thomas@monjalon.net>
To: Bruce Richardson <bruce.richardson@intel.com>,
	Maxime Coquelin <maxime.coquelin@redhat.com>,
	Akhil Goyal <gakhil@marvell.com>,
	"Chautru, Nicolas" <nicolas.chautru@intel.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
	"hemant.agrawal@nxp.com" <hemant.agrawal@nxp.com>,
	"Vargas, Hernan" <hernan.vargas@intel.com>,
	Tom Rix <trix@redhat.com>, "mdr@ashroe.eu" <mdr@ashroe.eu>,
	"david.marchand@redhat.com" <david.marchand@redhat.com>,
	"stephen@networkplumber.org" <stephen@networkplumber.org>
Subject: Re: [EXT] Re: [PATCH v1 00/10] baseband/acc200
Date: Wed, 14 Sep 2022 16:23:19 +0200	[thread overview]
Message-ID: <2150057.1BCLMh4Saa@thomas> (raw)
In-Reply-To: <CO6PR18MB4484992564DF26F56431CEE8D8469@CO6PR18MB4484.namprd18.prod.outlook.com>

14/09/2022 15:44, Akhil Goyal:
> > > On 9/14/22 12:35, Thomas Monjalon wrote:
> > > > 06/09/2022 14:51, Tom Rix:
> > > > > On 9/1/22 1:34 PM, Chautru, Nicolas wrote:
> > > > > > From: Tom Rix <trix@redhat.com>
> > > > > > > On 8/31/22 6:26 PM, Chautru, Nicolas wrote:
> > > > > > > > From: Tom Rix <trix@redhat.com>
> > > > > > > > > On 8/31/22 3:37 PM, Chautru, Nicolas wrote:
> > > > > > > > > > > > > > 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://urldefense.proofpoint.com/v2/url?u=https-
> > 3A__dickgrune.com_Programs_similarity-
> > 5Ftester_&d=DwIBAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=DnL7Si2wl_PRwpZ9TW
> > ey3eu68gBzn7DkPwuqhd6WNyo&m=m846AfMSeaddoC0hcxp1mHU4LV3jRUpw
> > P-Ie_41buNb9nACOR5La8n8LEFBCnn4t&s=9dgMzk9UMFLA-
> > b1EJbi4lK3GG6mNMgOXZRyDZqe00TU&e=
> > > > > > > > > > >
> > > > > > > > > > > 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, ...)
> > > > >
> > > > > Some suggestions on refactoring,
> > > > >
> > > > > For the registers, have a common file.
> > > > >
> > > > > For the shared functionality, ex/ ldpc encoder, break these out to
> > > > > its own shared file.
> > > > >
> > > > > The public interface, see my earlier comments on the documentation,
> > > > > should be have the same interfaces and the few differences
> > > > > highlighted.
> > > >
> > > > +1 to have common files, and all in a single directory
> > > > drivers/baseband/acc100/
> > >
> > > Jus to be sure we are aligned, do you mean to have both drivers in the
> > > same directory, which will share some common files? That's the way I
> > > would go.
> > >
> > 
> > I think the expectation is that the two drivers will diverge in future, so
> > having separate directories should be ok, even with common files placed in
> > one directory are shared with another. With meson include paths its pretty
> > trivial to manage if it's just header files, and even if there are common C
> > files, there is always the option of using drivers/common if we want to
> > split them out. As I understand it, right now it's only headers inluding
> > functions which can be static inline, so simple sharing via include paths
> > should work fine.
> > 
> It can be ok to have 2 separate directories, but 
> - is it not possible to have them in same directory say 'acc'  for all affiliated devices.
> Similar to other vendors' devices (cnxk, i40e, mlx).
> - Can both the devices - acc100 and acc200 coexist? If not, same directory is good enough.
> - there can be multiple files or directories in 'acc' which can be named appropriately to
> denote the actual device(acc100/200).
> 
> Having cross dependency across different drivers of same type looks a kind of hacking the meson.
> This was a reason we moved to have a drivers/common/ for some of the drivers.
> Also including "../acc100/abc.h" does not look appropriate to me.
> 
> IMO, we should not add unnecessary directories when the code is common and can be managed in a single one.
> 
> However, technically it is also ok to have 2 separate directories. But, agreeing on this will set a
> precedence for future next generation devices from the same vendors. It may be a topic of discussion in techboard.

Let me be frank, I don't trust Intel saying the hardware will be too much different in future.
For mlx5, we manage to handle very different devices (like DPU and changing processors)
in a single driver.
So I agree with Maxime and Akhil that a single driver in a single directory should be enough.
Having different registers in different devices is not enough to split.

The worst case would be to have a common directory acc/
but it may be a bit disappointing.




  reply	other threads:[~2022-09-14 14:23 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
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 [this message]
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=2150057.1BCLMh4Saa@thomas \
    --to=thomas@monjalon.net \
    --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=nicolas.chautru@intel.com \
    --cc=stephen@networkplumber.org \
    --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).