From mboxrd@z Thu Jan 1 00:00:00 1970 From: Shreyansh Jain Subject: Re: [PATCHv7 03/47] common/dpaa2: adding qbman driver Date: Tue, 28 Feb 2017 05:27:35 +0000 Message-ID: References: <1487684578-28656-1-git-send-email-shreyansh.jain@nxp.com> <8958b9ca-0a7d-3df0-3b62-4b9c610d301c@intel.com> <16fa9e1e-556e-a1b0-68ea-2feba58474d3@intel.com> <7397b7ef-a5c9-9d17-6919-714522f49082@nxp.com> <23fc7ab5-1d1b-183e-7997-6e078d49a499@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: "dev@dpdk.org" , "nhorman@tuxdriver.com" , Hemant Agrawal To: Ferruh Yigit Return-path: Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0051.outbound.protection.outlook.com [104.47.2.51]) by dpdk.org (Postfix) with ESMTP id CD3222C23 for ; Tue, 28 Feb 2017 06:28:03 +0100 (CET) In-Reply-To: <23fc7ab5-1d1b-183e-7997-6e078d49a499@intel.com> Content-Language: en-US List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" > -----Original Message----- > From: Ferruh Yigit [mailto:ferruh.yigit@intel.com] > Sent: Monday, February 27, 2017 9:06 PM > To: Shreyansh Jain > Cc: dev@dpdk.org; nhorman@tuxdriver.com; Hemant Agrawal > > Subject: Re: [PATCHv7 03/47] common/dpaa2: adding qbman driver >=20 > On 2/27/2017 10:01 AM, Shreyansh Jain wrote: > > Hello Ferruh, > > > > On Friday 24 February 2017 03:28 PM, Ferruh Yigit wrote: > > > > [snip] > > > >>> > >>> Now, we have these possibility: > >>> 1. Have a shared library with non rte_* symbols > >>> 2. We have shared library with rte_* symbols > >>> 3. We have non-net devices (crypto, eventdev, ..) depend on net for > >>> these hardware interfaces > >>> > >>> (2) is hitting performance significantly. > >>> (3) it not a clean solution, having driver/crypto depend on driver/ne= t. > >>> When new devices are there, more dependencies will occur. > >>> > >>> In crux, probably we need to have a discussion on (1) and how strongl= y > >>> we feel about that (specially in context of drivers). > >> > >> Insight of above information, I would be OK with (1). > > > > Great. Thank you for understanding. > > > >> > >> We can go with option (1) now, since these are not real APIs to user > >> application, it can be possible to change them if better solution foun= d. > >> > >> Do you think is it good idea to have different naming syntax for those > >> libraries to clarify they are for PMD internal usage? > >> > > > > Indeed. Current name is librte_common_dpaa2_*. > > Do you think librte_drvlib_dpaa2 or librte_drvlib_dpaa2_pmd is better? >=20 > common vs drvlib may not be different for who don't know about these > libraries, what about using "internal" or "private" kind of keyword? I am ok with librte_pvtlib_dpaa2_pmd or librte_pvtlib_dpaa2. Sounds fine? ('internal' is too long and its abbreviation 'int' doesn't make it easier to read. :D ) - Shreyansh