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

[Ferruh Yigit]

On 1/24/2017 2:39 PM, 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:

What do you think about following:

Create wrappers for DPDK with namespace, and export those for DPDK.
And in the user side, create macros to convert them back.

sample: [1]

Although this may work, I am not sure this really worth the effort, if
there is no intended consumer of these API other than dpaa2 code.


[1]
======

API .c (no modification):
int func_foo() {};
------

wrapper.c (new file):
int rte_foo() {	return func_foo(); }
------

*version.map:
	...
	rte_foo;
	...
------

user dpdk_macro.h (new file):
#define func_foo rte_foo
...
------

user.c (no modification except include):
#include "dpdk_macro.h"

func_foo();

======

	


> 
> 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
>