[dpdk-dev] NXP DPAA2: Symbol renaming issue: Request for Suggestions
shreyansh.jain at nxp.com
Wed Jan 25 14:00:37 CET 2017
On Wednesday 25 January 2017 06:07 PM, Neil Horman wrote:
> On Tue, Jan 24, 2017 at 02:39:56PM +0000, Shreyansh Jain wrote:
>> 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 )
>> | 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 |
>> +-----------+ +------------+ / +----------------+
>> If we consider the above layout, drivers/crypto/dpaa_sec (NXP's DPAA2 Crypto
>> PMD, already available on ML ), 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)
>> 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
>> - 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
>> - 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_*
>> - For example, allowing symbols to be exposed limited to drivers/* area
>> and not allowing them to be available across lib/* (not sure how, though!)
>> <This is where I need you help - is there some suggestion or comments which
>> 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.
>>  https://www.kernel.org/doc/readme/drivers-staging-fsl-mc-README.txt
>>  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
Thanks. Sounds interesting, though something I will need to
investigate. I will experiment on this.
More information about the dev