All of lore.kernel.org
 help / color / mirror / Atom feed
From: Shreyansh Jain <shreyansh.jain@nxp.com>
To: Thomas Monjalon <thomas.monjalon@6wind.com>,
	Ferruh Yigit <ferruh.yigit@intel.com>,
	"dev@dpdk.org" <dev@dpdk.org>
Cc: Hemant Agrawal <hemant.agrawal@nxp.com>
Subject: NXP DPAA2: Symbol renaming issue: Request for Suggestions
Date: Tue, 24 Jan 2017 14:39:56 +0000	[thread overview]
Message-ID: <DB5PR0401MB2054D64345734B33221E332590750@DB5PR0401MB2054.eurprd04.prod.outlook.com> (raw)

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

             reply	other threads:[~2017-01-24 14:40 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-24 14:39 Shreyansh Jain [this message]
2017-01-24 16:24 ` NXP DPAA2: Symbol renaming issue: Request for Suggestions Ferruh Yigit
2017-01-25 11:35   ` Shreyansh Jain
2017-01-24 16:51 ` Thomas Monjalon
2017-01-25 12:37 ` Neil Horman
2017-01-25 13:00   ` Shreyansh Jain

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DB5PR0401MB2054D64345734B33221E332590750@DB5PR0401MB2054.eurprd04.prod.outlook.com \
    --to=shreyansh.jain@nxp.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=hemant.agrawal@nxp.com \
    --cc=thomas.monjalon@6wind.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.