From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50076.outbound.protection.outlook.com [40.107.5.76]) by dpdk.org (Postfix) with ESMTP id 37ED94CE4 for ; Tue, 24 Jan 2017 15:40:58 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nxp.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=tJmu9A1MHbhMJwWMoBePWSZ5sQ3yXD31gSdijT91Yi8=; b=bEzEiEtijrq5w1xLL6fDOs9lTkkPHkcAhJ0wWxet5qbJ2o5aSaQwG4RQ2A7xmj9LI+rsMj20h9OlL1QGK5+vIPRaG0hQzpOK5gnyjna80bmO6ePiBFLObkIeJ9yZ9amAA7LbR3u3IAzGXNG+yaHmjt5j0s/49vRhmWOuZyth3cM= Received: from DB5PR0401MB2054.eurprd04.prod.outlook.com (10.166.11.137) by HE1PR04MB1612.eurprd04.prod.outlook.com (10.164.48.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.860.13; Tue, 24 Jan 2017 14:40:56 +0000 Received: from DB5PR0401MB2054.eurprd04.prod.outlook.com ([10.166.11.137]) by DB5PR0401MB2054.eurprd04.prod.outlook.com ([10.166.11.137]) with mapi id 15.01.0860.021; Tue, 24 Jan 2017 14:40:54 +0000 From: Shreyansh Jain To: Thomas Monjalon , Ferruh Yigit , "dev@dpdk.org" CC: Hemant Agrawal Thread-Topic: NXP DPAA2: Symbol renaming issue: Request for Suggestions Thread-Index: AdJ2TsuuIsp8GfX7T9idGjosrxd1jg== Date: Tue, 24 Jan 2017 14:39:56 +0000 Deferred-Delivery: Tue, 24 Jan 2017 14:39:29 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=shreyansh.jain@nxp.com; x-originating-ip: [192.88.169.1] x-microsoft-exchange-diagnostics: 1; HE1PR04MB1612; 7:iKhMpGkf5n6Xcj2Jl4RmxvAWM6f88B8IC9lzZAkLYdoFQo6bo4GxOECmQZc4QUclB+0LAJRIjVfVn4eK/KrIMDDR7AN/jgzi0vPBcpa3CkqFEb3QHCs8AfFs8OenWuIPY2El6G/7V17sCT6KnRYRTPoCHQEqoXV4/O1kKxwjCV4EgCLlq0hW2SFexaEVjUmlhSmSB3iGtKsszZgF/FxKr4gd5L3S3TnUnxwm5IIJWeVAPsZ1OoCrUcwU8AgGx7yQCeWBls5IHGUDfEWCfogAQHdYZO0+cDDqVtZa6TWKkcqglMKnF+QnBgvi1cVBMA3SxYIq/sWIlOKs0GfBXFGv+WCoP80dH1iH6qzg4Edx6inME8+f6+D50X9ZUlSkbo2R5acgRVFp65c6kkw3dFS0zY9XpKP9DYPSVO162jCKvkbXtk5XdO7PI7+11P+a8WlYTPDLGKLO7bhrMru1V2WWUg== x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(39410400002)(39850400002)(39860400002)(39840400002)(199003)(189002)(99286003)(55016002)(122556002)(53936002)(2501003)(86362001)(106356001)(6306002)(9686003)(6436002)(25786008)(77096006)(38730400001)(50986999)(101416001)(33656002)(105586002)(6506006)(15395725005)(54356999)(92566002)(74316002)(189998001)(7736002)(8936002)(8676002)(81166006)(3280700002)(66066001)(2906002)(3660700001)(5660300001)(7696004)(2900100001)(102836003)(3846002)(6116002)(81156014)(97736004)(305945005)(68736007)(4326007)(5001770100001)(533714002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR04MB1612; H:DB5PR0401MB2054.eurprd04.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; x-ms-office365-filtering-correlation-id: e528e2e7-ce24-4bcf-19dd-08d44467008e x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:HE1PR04MB1612; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(227817650892897); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123564025)(20161123560025)(20161123562025)(20161123555025)(6072148)(6047074); SRVR:HE1PR04MB1612; BCL:0; PCL:0; RULEID:; SRVR:HE1PR04MB1612; x-forefront-prvs: 0197AFBD92 received-spf: None (protection.outlook.com: nxp.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nxp.com X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jan 2017 14:40:54.5603 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR04MB1612 Subject: [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 14:40:58 -0000 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]) =20 =20 +-------------------------------+ =20 | Application | =20 +----.--------------------.-----+ =20 | | =20 +----'------+ +-----'-----+ =20 drivers/---->| DPIO | | DPIO |<---drivers/bus/fslmc bus/fslmc +----.------+ +------.----+ =20 | | =20 +----/-||--------------||--/----+ =20 | Queue/Buffer Manager |<--- drivers/common/dpaa2= =20 +----\-||--------------||--\----+ qbman | | =20 +----'------+ +------'----+ =20 drivers/ --->| DPNI | | DPSEC |<---drivers/cyrpto net/dpaa2 +----|------+ +-----|-----+ dpaa2_sec | | =20 +----|------+ +------|-----+ +----------------+ | PHY H/W | | SEC H/W | .> FSL MC BUS | +-----------+ +------------+ / +----------------+ drivers/bus/fslmc =20 =20 If we consider the above layout, drivers/crypto/dpaa_sec (NXP's DPAA2 Crypt= o 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 Manage= r 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 porta= ls 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 thes= e=20 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.=20 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 tha= t 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, t= his too has a technical limitation for us as some data structures are share= d 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, thou= gh!) =20 =20 My argument for this: - With new bus infra in place, there would be more drivers being contribu= ted. 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) whi= ch 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