[dpdk-dev] [PATCHv7 00/47] NXP DPAA2 PMD

[Neil Horman]

On Mon, Feb 20, 2017 at 11:01:23AM +0530, Hemant Agrawal wrote:
> On 2/19/2017 8:14 PM, Neil Horman wrote:
> > On Fri, Feb 17, 2017 at 05:59:45PM +0530, Hemant Agrawal wrote:
> > > On 2/16/2017 6:57 PM, Bruce Richardson wrote:
> > > > On Thu, Feb 16, 2017 at 08:22:49AM -0500, Neil Horman wrote:
> > > > > On Thu, Feb 16, 2017 at 06:08:59AM +0530, Hemant Agrawal wrote:
> > > > > > The patch series adds NXP’s QorIQ-Layerscape DPAA2 Architecture based
> > > > > > fsl-mc bus driver and network SoC PMD.  This version of the driver
> > > > > > supports NXP LS208xA, LS204xA and LS108x families Network SoCs.
> > > > > > 
> > > > > > DPAA2, or Data Path Acceleration Architecture, is a hardware architecture
> > > > > > designed for high-speed network packet processing. It uses a bus name
> > > > > > ‘fsl-mc’, part of Linux Kernel Staging tree [1], for resource management.
> > > > > > 
> > > > > > A brief description of architecture is given below; detailed description
> > > > > > is part of the documentation in the patches itself.
> > > > > > 
> > > > > > DPAA2 contains hardware component called the Management Complex (or MC).
> > > > > > It manages the DPAA2 hardware resources.  The MC provides an object-based
> > > > > > abstraction for software drivers to use the DPAA2 hardware.
> > > > > > 
> > > > > > Some of the key objects are:
> > > > > >     - DPNI, which refers to the network interface object.
> > > > > >     - DPBP, which refers to HW based memory pool object
> > > > > >     - DPIO, refers to processing context for accessing QBMAN
> > > > > > 
> > > > > > Besides the MC, DPAA2 also includes a Hardware based Queue and Buffer Manager
> > > > > > called QBMAN. Prime responsibility of QBMAN is to allow lockless access to
> > > > > > software/user-space to the queues and buffers implemented in the hardware.
> > > > > > 
> > > > > > The patch series could be logically structured into following sub-areas:
> > > > > > 1. Make file changes for crc in armv8 core machine type and driver dependency
> > > > > > 2. Common dpaa2 hw accelerator drivers for QBMAN.
> > > > > > 3. Indroducing fsl-mc bus as rte_bus, it's componenets.
> > > > > > 4. Introducing dpaa2 pmd driver
> > > > > > 5. Introducing dpaa2 mempool
> > > > > > 6. Support for DPAA2 Ethernet Device (ethdev)
> > > > > > 7. Additional functionality in DPAA2 ethdev.
> > > > > > 
> > > > > > The following design decisions are made during development:
> > > > > > 
> > > > > > 1. DPAA2 implements a new bus called "fsl-mc" and some common accelerator drivers.
> > > > > >    These drivers will be shared with dpaa2 based crypto drivers.
> > > > > > 
> > > > > > 2. DPAA2 implements the HW mempool offload with DPBP object.
> > > > > >  - The new pool is being configured using compile time option and pool name
> > > > > >    as "dpaa2".
> > > > > > 
> > > > > > 3. It maintains per lcore DPIO objects and affine the DPIO instance to the
> > > > > >    processing threads accessing the QBMAN HW.
> > > > > > 
> > > > > > Prerequisites:
> > > > > >  - For running the PMD, NXP's SoC (board) and SDK (software/BSP) is required.
> > > > > >    Information about obtaining relevant software is available in the docs
> > > > > >    as part of the patch.
> > > > > 
> > > > > NAK.  The SDK requires registration to obtain, and appears to be non-open
> > > > > source.  This driver is unmaintainable given that.
> > > > > 
> > > > Hi Hemant,
> > > > 
> > > > can you perhaps clarify things here. What is the requirement to:
> > > > * build the driver/DPDK for the platform
> > > > * run applications using DPDK on the platform
> > > > 
> > > > Also what is the license/availability for those requirements.
> > > > 
> > > > /Bruce
> > > 
> > > 
> > > Hi Neil, Bruce,
> > > 	I thought SDK is a simpler choice to get the required components in one
> > > place. However there is no such restriction to get the components only from
> > > the NXP SDK.
> > > We will update the documentation with the same.
> > > 
> > > Following is a list of open source components required:
> > > 
> > > 1. ARM 64 tool chain.
> > > e.g. *aarch64* Linaro Toolchain:
> > > https://releases.linaro.org/components/toolchain/binaries/4.9-2017.01/aarch64-linux-gnu/
> > > 
> > > 2. Linux Kernel
> > > 
> > > http://git.freescale.com/git/cgit.cgi/ppc/sdk/linux.git/log/?h=sdk-v2.0.x
> > > or,
> > > https://github.com/qoriq-open-source/linux
> > > Please note that the particular linux kernel, I have used for my testing is
> > > 4.1.8 (part of our SDK 2.0-17.01),  I will publish the tree at github
> > > shortly.
> > > 
> > > 3. Rootfile system : any aarch64 supported e.g.
> > > Ubuntu 15.10 (Wily) or 16.04 LTS (Xenial) userland
> > > http://cdimage.ubuntu.com/ubuntu-base/releases/16.04/release/ubuntu-base-16.04.1-base-arm64.tar.gz
> > > 
> > 
> > > Initial kernel is best built in a Yocto build environment, then deployed to
> > > target with a disk based Ubuntu userland.
> > > However, both kernel and DPDK release can be natively built on the target
> > > platform, using Ubuntu devtools.
> > > 
> > 
> > 
> > Ok, so lets clarify this a bit with a question:  Understanding that you
> > indicated you can build  this pmd with host tools, are there any runtime
> > dependencies on the SDK?  That is to say, can you build an run this pmd without
> > ever having to agree to the SDK usage policy?  If so, then if you remove the
> > language suggesting such from your documentation patch, I rescind my nak.
> > 
> Hi Neil,
> 	yes!  there is absolutely no need to use the SDK and agreeing to SDK usages
> policy.  All the components are available in open source and the PMD can run
> using them.
> 
> As suggested, I will change my documentation patch.
> 
> Thanks for your comments.
> 
> Regards,
> Hemant
> 
Then I have no problem with the driver, if you update the documentation
accordingly, I'll ack it.
Neil

> 
> > Best
> > Neil
> > 
> > > Regards,
> > > Hemant
> > > 
> > > 
> > > 
> > > 
> > 
> 
> 
>