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
Best
Neil
Regards,
Hemant
