From mboxrd@z Thu Jan 1 00:00:00 1970 From: Shreyansh Jain Subject: Re: NXP DPAA2: Symbol renaming issue: Request for Suggestions Date: Wed, 25 Jan 2017 18:30:37 +0530 Message-ID: <233c9eda-d01d-ec33-fb58-c73271bdb3e0@nxp.com> References: <20170125123730.GB4611@hmswarspite.think-freely.org> Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Cc: Thomas Monjalon , Ferruh Yigit , "dev@dpdk.org" , Hemant Agrawal To: Neil Horman Return-path: Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0041.outbound.protection.outlook.com [104.47.42.41]) by dpdk.org (Postfix) with ESMTP id 49973108F for ; Wed, 25 Jan 2017 13:56:04 +0100 (CET) In-Reply-To: <20170125123730.GB4611@hmswarspite.think-freely.org> 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 Wednesday 25 January 2017 06:07 PM, Neil Horman wrote: > On Tue, Jan 24, 2017 at 02:39:56PM +0000, Shreyansh Jain wrote: >> Hello, >> >> We are facing a peculiar problem with respect to symbol namespace in DPDK. I >> think Ferruh and Thomas would have fair idea about it as they have already >> reviewed and commented on it. I was hoping to get some input to take it >> forward from here. >> >> Brief Intro to DPAA2 Architecture: >> >> This is brief about NXP's DPAA2 PMD to start with: >> (A lot more information is available at [1]) >> >> >> >> +-------------------------------+ >> | Application | >> +----.--------------------.-----+ >> | | >> +----'------+ +-----'-----+ >> drivers/---->| DPIO | | DPIO |<---drivers/bus/fslmc >> bus/fslmc +----.------+ +------.----+ >> | | >> +----/-||--------------||--/----+ >> | Queue/Buffer Manager |<--- drivers/common/dpaa2 >> +----\-||--------------||--\----+ qbman >> | | >> +----'------+ +------'----+ >> drivers/ --->| DPNI | | DPSEC |<---drivers/cyrpto >> net/dpaa2 +----|------+ +-----|-----+ dpaa2_sec >> | | >> +----|------+ +------|-----+ +----------------+ >> | PHY H/W | | SEC H/W | .> FSL MC BUS | >> +-----------+ +------------+ / +----------------+ >> drivers/bus/fslmc >> >> >> If we consider the above layout, drivers/crypto/dpaa_sec (NXP's DPAA2 Crypto >> PMD, already available on ML [2]), and drivers/net/dpaa2 (NXP's DPAA2 PMD) are >> using a common code (drivers/common/dpaa2/qbman). >> >> QBMAN (drivers/common/dpaa2/qbman) is essentially a Queue and Buffer Manager >> set of APIs which allow DPIO (Data Path IO interfaces) to communicate with the >> Hardware through queues (and buffers). >> >> At the scan time, FSLMC bus is scanned and all devices (Phy or Sec) are >> identified and added to a list. For each such device, appropriate I/O portals >> are opened which are essentially gateway between user-space and DP* devices >> using the hardware queues/buffers (qbman) >> >> Problem: >> >> You might have noticed that we have exposed a lot of symbols from >> drivers/common and drivers/bus for drivers/net and drivers/crypto. All these >> symbols are not rte_* as what has been suggested for exported symbols. >> >> Review comments have been received for renaming these to make them rte_* or >> _rte_* prefixed. >> >> Just as a side note, these symbols are being exposed _internally_ within >> drivers/* area. >> >> There are (3) possible solutions we have: >> >> 1/ Rename all the symbols: >> - This is a difficult option for us. Renaming means breaking our linkage >> with existing code (Linux Kernel upstream candidate as well as internal >> repository). >> - Changing it means maintaining this change set internally/independently >> which is not a feasible long term solution. >> >> 2/ Merge all the libraries together: >> - In the initial RFC days, there were review comments which suggested that >> we should break the PMD into common libraries and place it in drivers/* >> parallel folders. >> - This is precisely the reason we are facing the situation. >> - Another possibility is to start duplicating the code for common. But, this >> too has a technical limitation for us as some data structures are shared >> across net and crypto and it is not possible to have multiple instances of >> those. >> - One more offshoot option could have been to keep the library external >> of the DPDK framework (external location and linked on demand basis, >> manually). We don't prefer this as this will make it difficult for any user >> to use DPAA2 easily. >> >> 3/ Finding a way to keep symbols internal to drivers/* independent of rte_* >> prefix: >> - For example, allowing symbols to be exposed limited to drivers/* area >> and not allowing them to be available across lib/* (not sure how, though!) >> >> > can help us arrive to a solution?> >> >> My argument for this: >> - With new bus infra in place, there would be more drivers being contributed. >> It also means that there would be PMDs having their own code and symbol >> models. It would be difficult to ask all of them to mandatorily adhere >> to a naming scheme. >> This argument bodes well for lib/* because that is core (libraries) which >> should be controlled for uniformity and performance. >> >> [1] https://www.kernel.org/doc/readme/drivers-staging-fsl-mc-README.txt >> [2] http://dpdk.org/ml/archives/dev/2017-January/054251.html >> >> > > So, Option 3 seems pretty easy, just use symbol aliasing. Make all your > exported symbols static, and use the MAP_SATIC_SYMBOL macro (or use your own > inline asm if you want), to create rte_ aliases for them all, add the rte_* > variants to your version map and it should all work out. You get to keep your > naming in tact, you can create some macro ifdeffery to make your names static or > not depending on your build environment (upstream linux kernel vs. dpdk, vs > something else), and just use the aliases when it suit you (like for dpdk naming > conventions) Thanks. Sounds interesting, though something I will need to investigate. I will experiment on this. > > Neil > >