From mboxrd@z Thu Jan  1 00:00:00 1970
From: Shreyansh Jain <shreyansh.jain@nxp.com>
Subject: Re: [PATCHv7 03/47] common/dpaa2: adding qbman driver
Date: Mon, 27 Feb 2017 15:31:40 +0530
Message-ID: <7397b7ef-a5c9-9d17-6919-714522f49082@nxp.com>
References: <cfd37cad-2460-6eb2-c86b-6eff2f44096f@nxp.com>
 <1487684578-28656-1-git-send-email-shreyansh.jain@nxp.com>
 <8958b9ca-0a7d-3df0-3b62-4b9c610d301c@intel.com>
 <a221b290-3d63-bf33-f020-074896c17795@nxp.com>
 <16fa9e1e-556e-a1b0-68ea-2feba58474d3@intel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="windows-1252"; format=flowed
Content-Transfer-Encoding: 7bit
Cc: <dev@dpdk.org>, <nhorman@tuxdriver.com>, "hemant.agrawal@nxp.com"
 <hemant.agrawal@nxp.com>
To: Ferruh Yigit <ferruh.yigit@intel.com>
Return-path: <dev-bounces@dpdk.org>
Received: from NAM03-DM3-obe.outbound.protection.outlook.com
 (mail-dm3nam03on0072.outbound.protection.outlook.com [104.47.41.72])
 by dpdk.org (Postfix) with ESMTP id 1781C2E81
 for <dev@dpdk.org>; Mon, 27 Feb 2017 10:56:57 +0100 (CET)
In-Reply-To: <16fa9e1e-556e-a1b0-68ea-2feba58474d3@intel.com>
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

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?