[dpdk-dev] NXP DPAA2: Symbol renaming issue: Request for Suggestions

[Shreyansh Jain]

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!)
>>
>>    <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.
>>
>> [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
>
>