From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id 4AEAB2E81 for ; Mon, 27 Feb 2017 16:35:45 +0100 (CET) Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Feb 2017 07:35:44 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.35,215,1484035200"; d="scan'208";a="230213801" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.252.5.206]) ([10.252.5.206]) by fmsmga004.fm.intel.com with ESMTP; 27 Feb 2017 07:35:42 -0800 To: Shreyansh Jain 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> Cc: dev@dpdk.org, nhorman@tuxdriver.com, "hemant.agrawal@nxp.com" From: Ferruh Yigit Message-ID: <23fc7ab5-1d1b-183e-7997-6e078d49a499@intel.com> Date: Mon, 27 Feb 2017 15:35:41 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <7397b7ef-a5c9-9d17-6919-714522f49082@nxp.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCHv7 03/47] common/dpaa2: adding qbman driver X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 15:35:45 -0000 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/net. >>> When new devices are there, more dependencies will occur. >>> >>> In crux, probably we need to have a discussion on (1) and how strongly >>> 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 found. >> >> 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? common vs drvlib may not be different for who don't know about these libraries, what about using "internal" or "private" kind of keyword?