From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ferruh Yigit Subject: Re: [PATCHv6 02/33] drivers/common/dpaa2: adding qbman driver Date: Mon, 23 Jan 2017 17:30:44 +0000 Message-ID: <61976e79-6ea8-0b9c-0792-c9cdc4dbc14a@intel.com> References: <1484832240-2048-1-git-send-email-hemant.agrawal@nxp.com> <1485172803-17288-1-git-send-email-hemant.agrawal@nxp.com> <1485172803-17288-3-git-send-email-hemant.agrawal@nxp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: thomas.monjalon@6wind.com, bruce.richardson@intel.com, shreyansh.jain@nxp.com, john.mcnamara@intel.com, jerin.jacob@caviumnetworks.com, Geoff Thorpe , Roy Pledge To: Hemant Agrawal , dev@dpdk.org Return-path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id 36D9D108F for ; Mon, 23 Jan 2017 18:30:47 +0100 (CET) In-Reply-To: <1485172803-17288-3-git-send-email-hemant.agrawal@nxp.com> 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 1/23/2017 11:59 AM, Hemant Agrawal wrote: > QBMAN, is a hardware block which interfaces with the other > accelerating hardware blocks (For e.g., WRIOP) on NXP's DPAA2 > SoC for queue, buffer and packet scheduling. > > This patch introduces a userspace driver for interfacing with > the QBMAN hw block. > > The qbman-portal component provides APIs to do the low level > hardware bit twiddling for operations such as: > -initializing Qman software portals > -building and sending portal commands > -portal interrupt configuration and processing > > This same/similar code is used in kernel and compat file is used > to make it working in user space. > > Signed-off-by: Geoff Thorpe > Signed-off-by: Roy Pledge > Signed-off-by: Hemant Agrawal > --- <...> > --- a/config/common_base > +++ b/config/common_base > @@ -287,7 +287,6 @@ CONFIG_RTE_LIBRTE_THUNDERX_NICVF_DEBUG_TX=n > CONFIG_RTE_LIBRTE_THUNDERX_NICVF_DEBUG_DRIVER=n > CONFIG_RTE_LIBRTE_THUNDERX_NICVF_DEBUG_MBOX=n > > -# Minor typo .. > # Compile burst-oriented VIRTIO PMD driver > # > CONFIG_RTE_LIBRTE_VIRTIO_PMD=y <...> > --- /dev/null > +++ b/drivers/common/dpaa2/qbman/rte_common_dpaa2_qbman_version.map > @@ -0,0 +1,27 @@ > +DPDK_17.02 { > + global: > + > + qbman_check_command_complete; > + qbman_eq_desc_clear; > + qbman_eq_desc_set_fq; > + qbman_eq_desc_set_no_orp; > + qbman_eq_desc_set_qd; > + qbman_eq_desc_set_response; > + qbman_get_version; > + qbman_pull_desc_clear; > + qbman_pull_desc_set_fq; > + qbman_pull_desc_set_numframes; > + qbman_pull_desc_set_storage; > + qbman_release_desc_clear; > + qbman_release_desc_set_bpid; > + qbman_result_DQ_fd; > + qbman_result_DQ_flags; > + qbman_result_has_new_result; > + qbman_swp_acquire; > + qbman_swp_init; > + qbman_swp_pull; > + qbman_swp_release; > + qbman_swp_send_multiple; Overall, dpdk library exported APIs not having DPDK prefix (rte_) is a concern, which already pointed by Thomas. I guess only user of this library will be other dpaa2 code, so these are not really APIs. Not sure how to proceed. I think I have seen "_rte" prefix used in some APIs to say that is internal API, does it make sense to use that API here? > + > + local: *; > +}; >