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, 21 Feb 2017 19:15:42 +0530 Message-ID: <9a1992c3-d977-4c3f-21cc-7b4bb5a68270@nxp.com> References: <1487684578-28656-1-git-send-email-shreyansh.jain@nxp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Cc: , To: Return-path: Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0062.outbound.protection.outlook.com [104.47.37.62]) by dpdk.org (Postfix) with ESMTP id 0C611952 for ; Tue, 21 Feb 2017 14:40:57 +0100 (CET) In-Reply-To: <1487684578-28656-1-git-send-email-shreyansh.jain@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" (Modified subject to: "Re: [PATCHv7 03/47] common/dpaa2: adding qbman driver") On Tuesday 21 February 2017 07:12 PM, Shreyansh Jain wrote: > Thanks for the suggestions about rte_* renaming in DPAA2 PMD. > I create a draft patch for a single symbol change. (applies over v7 > of DPAA2 PMD) > > Can you tell me if this is the direction you were suggesting? > > I see two issues in this approach which are somewhat problematic for > me to change all the symbols: > 1) We saw a drop of over 5% when I replaced only 3 symbols (one > of the most used ones, just for sampling). This also means that > when more of such symbols are replaced, it would bring further > drop. This was case when I used the Shared library approach. > (*) I am not well versed with gcc symbol aliasing to comment for > why such a drop would happen. But multiple test cycles confirm > this. > 2) I have to include a new header in almost all the source files for PMD/ > Pool/Bus etc. This is besides the STATIC_SYMBOL macros across the > code. Essentially, any internal repo patch cannot be directly > transposed to DPDK repo. Increased effort for each internal-> > external release > > Overall, I would like you to consider if this effort for changing names > for exposed symbols is really useful or not. > > There is another approach - that of not using a drivers/common library. > This again is problematic for us - NXP DPAA2 being a hardware, the lib > and state for Crypto and Net hardware is tied together - so, having > multiple instances of library breaks either of Crypto or Net PMD. > > Any other suggestions? > > - > Shreyansh Apologies for the modified subject in the previous email. While sending out the patch, I didn't pay attention to the 'patch head line'. - Shreyansh