From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bruce Richardson Subject: Re: [PATCHv7 00/47] NXP DPAA2 PMD Date: Fri, 17 Feb 2017 12:13:58 +0000 Message-ID: <20170217121358.GA135568@bricha3-MOBL3.ger.corp.intel.com> References: <1485172803-17288-1-git-send-email-hemant.agrawal@nxp.com> <1487205586-6785-1-git-send-email-hemant.agrawal@nxp.com> <20170216132249.GA18056@hmswarspite.think-freely.org> <20170216132751.GA100024@bricha3-MOBL3.ger.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Cc: Neil Horman , Hemant Agrawal , dev@dpdk.org, thomas.monjalon@6wind.com, shreyansh.jain@nxp.com, john.mcnamara@intel.com, jerin.jacob@caviumnetworks.com To: Ferruh Yigit Return-path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id D62923B5 for ; Fri, 17 Feb 2017 13:14:03 +0100 (CET) Content-Disposition: inline In-Reply-To: List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Fri, Feb 17, 2017 at 11:34:43AM +0000, Ferruh Yigit wrote: > On 2/16/2017 1:27 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. > > Hi Bruce, Hemant, Neil, Thomas, > > I did able to compile the driver without the SDK. It looks like that SDK > is a runtime dependency. > > What is the DPDK requirement here? > If it is not breaking the build, this PMD provides it. > If it builds without an SDK dependency I'd be happy enough to see this merged into DPDK. Since I can't run it without the correct hardware, I don't see needing the correct runtime software being a difficulty too. So long as we can compile this, we can check for breakages in it due to refactoring in other parts of DPDK, like we do for other drivers. As with those other drivers, it's up to the maintainers/vendors to do the functional checking for additional issues. Nobody is likely to have the hardware to functionality test all drivers in DPDK anyway. Regards, /Bruce