From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id 48E1BF956 for ; Tue, 24 Jan 2017 17:24:40 +0100 (CET) Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga103.jf.intel.com with ESMTP; 24 Jan 2017 08:24:39 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,278,1477983600"; d="scan'208";a="926114141" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.237.220.38]) ([10.237.220.38]) by orsmga003.jf.intel.com with ESMTP; 24 Jan 2017 08:24:38 -0800 To: Shreyansh Jain , Thomas Monjalon , "dev@dpdk.org" References: Cc: Hemant Agrawal From: Ferruh Yigit Message-ID: Date: Tue, 24 Jan 2017 16:24:37 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] NXP DPAA2: Symbol renaming issue: Request for Suggestions X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2017 16:24:40 -0000 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!) > > 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 >