From: Ferruh Yigit <ferruh.yigit@intel.com>
To: Shreyansh Jain <shreyansh.jain@nxp.com>,
Thomas Monjalon <thomas.monjalon@6wind.com>,
"dev@dpdk.org" <dev@dpdk.org>
Cc: Hemant Agrawal <hemant.agrawal@nxp.com>
Subject: Re: [dpdk-dev] NXP DPAA2: Symbol renaming issue: Request for Suggestions
Date: Tue, 24 Jan 2017 16:24:37 +0000 [thread overview]
Message-ID: <b5657d18-45aa-f7e5-8004-39e24e0af8cd@intel.com> (raw)
In-Reply-To: <DB5PR0401MB2054D64345734B33221E332590750@DB5PR0401MB2054.eurprd04.prod.outlook.com>
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
>
next prev parent reply other threads:[~2017-01-24 16:24 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-24 14:39 Shreyansh Jain
2017-01-24 16:24 ` Ferruh Yigit [this message]
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=b5657d18-45aa-f7e5-8004-39e24e0af8cd@intel.com \
--to=ferruh.yigit@intel.com \
--cc=dev@dpdk.org \
--cc=hemant.agrawal@nxp.com \
--cc=shreyansh.jain@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).