[dpdk-dev] [PATCH v4 00/41] Introduce NXP DPAA Bus, Mempool and PMD

[Shreyansh Jain]

Hello Thomas,

> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas at monjalon.net]
> Sent: Friday, September 22, 2017 6:43 PM
> To: Shreyansh Jain <shreyansh.jain at nxp.com>
> Cc: dev at dpdk.org; ferruh.yigit at intel.com; Hemant Agrawal
> <hemant.agrawal at nxp.com>
> Subject: Re: [PATCH v4 00/41] Introduce NXP DPAA Bus, Mempool and PMD
> 
> 22/09/2017 15:06, Shreyansh Jain:
> > On Friday 22 September 2017 03:40 AM, Thomas Monjalon wrote:
> > > 09/09/2017 13:20, Shreyansh Jain:
> > >> DPAA, or Datapath Acceleration Architecture [R2], is a set of hardware
> > >> components designed for high-speed network packet processing. This
> > >> architecture provides the infrastructure to support simplified sharing
> of
> > >> networking interfaces and accelerators by multiple CPU cores, and the
> > >> accelerators themselves.
> > >>
> > >> This patchset introduces the following:
> > >> 1. DPAA Bus (drivers/bus/dpaa)
> > >>   The core of DPAA bus is implemented using 3 main hardware blocks:
> QMan,
> > >>   or Queue Manager; BMan, or Buffer Manager and FMan, or Frame Manager.
> > >>   The patches introduce necessary layers to expose the DPAA hardware
> > >>   blocks for interfacing with RTE framework.
> > >
> > > I guess these are the same blocks as for DPAA2?
> > > They are in drivers/bus/fslmc/
> > > Why introducing yet another bus driver?
> > > The fslmc one was supposed to cover any Freescale (NXP (Qualcomm)) SoC.
> >
> > Forgot to reply to this in previous email:
> >
> > No, fslmc is not compatible with DPAA. They are completely different
> > architectures.
> > I am not sure why you have the notion "fslmc one was supposed to cover
> > any Freescale (NXP (Qualcomm)) SoC". That is not correct - FSLMC was
> > always for supporting DPAA2 which is based on VFIO. DPAA is more closer
> > to a platform layout.
> >
> > And I don't think we should have single "bus/fslmc" just so that it can
> > encompass all NXP SoC. I am assuming you didn't mean this :P.
> 
> At the beginning of fslmc work, I had understood that every NXP SoC were
> connecting components with the same principle which we could call the
> "Freescale bus".
> Then you came with this bus named bus/fslmc, not bus/dpaa2.
> Now I am confused. What is the exact scope of fslmc? Is it just DPAA2?

My memory is poor. I will have to look through the old emails what happened - but I recall there was a discussion in initial phases about the naming. "fslmc" came out as a name that is what is the real name of the DPAA2 bus. There was initial a confusion if name of bus in Linux Kernel should match or not - but, we realized that bus is *not* device and device name is "dpaa2".

As for whether fslmc would cover multiple SoC - that is still true. There are multiple SoCs within the DPAA2 umbrella. LS20XX, LS108X series and some more - all of which use the FSLMC bus (DPAA2 architecture, on FSLMC bus, having 'dpaa2' devices).

There is another architecture, an old one, which are still popular. This is platform type bus which is aptly named 'dpaa' - and here the confusion of bus name and device doesn't appear. (DPAA bus, using DPAA architecture, exposing 'dpaa' devices).

Exact scope of FSLMC is just DPAA2 architecture based SoCs. There are many here with new coming up.
Exact scope of DPAA bus is just DPAA architecture based SoCs. There are many here.

Does this clear your doubt to some extent?