From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from dpdk.org (dpdk.org [92.243.14.124])
by dpdk.space (Postfix) with ESMTP id 244AAA0096
for <public@inbox.dpdk.org>; Thu, 6 Jun 2019 11:45:02 +0200 (CEST)
Received: from [92.243.14.124] (localhost [127.0.0.1])
by dpdk.org (Postfix) with ESMTP id BD8C31B95A;
Thu, 6 Jun 2019 11:45:00 +0200 (CEST)
Received: from mx0b-0016f401.pphosted.com (mx0a-0016f401.pphosted.com
[67.231.148.174]) by dpdk.org (Postfix) with ESMTP id 833741B959
for <dev@dpdk.org>; Thu, 6 Jun 2019 11:44:59 +0200 (CEST)
Received: from pps.filterd (m0045849.ppops.net [127.0.0.1])
by mx0a-0016f401.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id
x569ivAb010202; Thu, 6 Jun 2019 02:44:58 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marvell.com;
h=from : to : cc :
subject : date : message-id : references : in-reply-to : content-type :
content-transfer-encoding : mime-version; s=pfpt0818;
bh=tsYCd9OtEOLxh9a7Dzfz1UdsjZOsUA8vWPxRVROkGsE=;
b=yLFYis5j4IrG3KhT196Va+u2g39ulHvbP4inLBdaUi53U6zyzlBAysk34BMOa5MAznPx
onc+JISEcbq52bl4SbIETBtctwmshUjIKShBtDycA0xdS6o4aO5V5T0GMmPgtFntNMMg
fN4zBE8zJjqylHMMjZh4KBpq41q8EwfF2SnyzA0E2U/c+0qvT8qA6WycsIrGet6oxjFx
MvgLe/Gm8SLOSRUbZHMNM1Br0cJ6SucndBWCjPzWYHIckEYyswIIoIZuVVbp8dffuySD
SKTfm4eBFmTaCA3RdhTBF2en/cmlJVeYdbCq3bQK0gANNFvSyvsyDmxzRRVDYcZ/pymU 0Q==
Received: from sc-exch03.marvell.com ([199.233.58.183])
by mx0a-0016f401.pphosted.com with ESMTP id 2sxwgnrpgd-1
(version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT);
Thu, 06 Jun 2019 02:44:58 -0700
Received: from SC-EXCH02.marvell.com (10.93.176.82) by SC-EXCH03.marvell.com
(10.93.176.83) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Thu, 6 Jun
2019 02:44:57 -0700
Received: from NAM03-DM3-obe.outbound.protection.outlook.com (104.47.41.52) by
SC-EXCH02.marvell.com (10.93.176.82) with Microsoft SMTP Server
(TLS) id
15.0.1367.3 via Frontend Transport; Thu, 6 Jun 2019 02:44:57 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=marvell.onmicrosoft.com; s=selector2-marvell-onmicrosoft-com;
h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
bh=tsYCd9OtEOLxh9a7Dzfz1UdsjZOsUA8vWPxRVROkGsE=;
b=Hrh3ZBsQN761wJ8gPRxxhPralswVp6j6cq5WtsKOU634iJMni3cKTMdvsBsfa4no/b3KeS82HMzaU3tbbZHAuo/SbgRBJ/i11bAQAx7GawpwwlTacMXZyIrOjPtjGFQMUnuQXqR06odfHYyPF1MsMwuL8c14mJIwxTt/fZBG89k=
Received: from BYAPR18MB2424.namprd18.prod.outlook.com (20.179.91.149) by
BYAPR18MB2949.namprd18.prod.outlook.com (20.179.59.153) with Microsoft SMTP
Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
15.20.1965.12; Thu, 6 Jun 2019 09:44:52 +0000
Received: from BYAPR18MB2424.namprd18.prod.outlook.com
([fe80::1ce4:557d:eeb8:843c]) by BYAPR18MB2424.namprd18.prod.outlook.com
([fe80::1ce4:557d:eeb8:843c%7]) with mapi id 15.20.1965.011; Thu, 6 Jun 2019
09:44:52 +0000
From: Jerin Jacob Kollanukkaran <jerinj@marvell.com>
To: Neil Horman <nhorman@tuxdriver.com>, Bruce Richardson
<bruce.richardson@intel.com>
CC: "dev@dpdk.org" <dev@dpdk.org>, Thomas Monjalon <thomas@monjalon.net>
Thread-Topic: [EXT] [RFC PATCH 0/2] introduce __rte_internal tag
Thread-Index: AQHVEynnIvy0R3R0lkaWrQuIVgPnUKaNTWtQgAAIeYCAABfgAIABAvyA
Date: Thu, 6 Jun 2019 09:44:52 +0000
Message-ID: <BYAPR18MB24240EF19CFA1ADFE6B52AD1C8170@BYAPR18MB2424.namprd18.prod.outlook.com>
References: <20190525184346.27932-1-nhorman@tuxdriver.com>
<BYAPR18MB24240660A3CDEB3E0B0347AAC8160@BYAPR18MB2424.namprd18.prod.outlook.com>
<20190605164541.GH1550@bricha3-MOBL.ger.corp.intel.com>
<20190605181108.GC554@hmswarspite.think-freely.org>
In-Reply-To: <20190605181108.GC554@hmswarspite.think-freely.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [14.140.231.66]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: b5cea67b-5ec2-443c-68c3-08d6ea63a02f
x-microsoft-antispam: BCL:0; PCL:0;
RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(7168020)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020);
SRVR:BYAPR18MB2949;
x-ms-traffictypediagnostic: BYAPR18MB2949:
x-microsoft-antispam-prvs: <BYAPR18MB2949AEF8272296470C701C35C8170@BYAPR18MB2949.namprd18.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8882;
x-forefront-prvs: 00603B7EEF
x-forefront-antispam-report: SFV:NSPM;
SFS:(10009020)(136003)(396003)(366004)(346002)(376002)(39860400002)(13464003)(174874002)(199004)(189003)(4326008)(73956011)(316002)(64756008)(66446008)(66476007)(66556008)(66946007)(76116006)(3846002)(6116002)(7736002)(14454004)(25786009)(305945005)(53936002)(8936002)(478600001)(8676002)(81156014)(6246003)(81166006)(74316002)(102836004)(86362001)(99286004)(76176011)(7696005)(55016002)(55236004)(68736007)(229853002)(66066001)(53546011)(6506007)(110136005)(6436002)(11346002)(446003)(33656002)(476003)(54906003)(52536014)(5660300002)(186003)(14444005)(256004)(2906002)(71200400001)(71190400001)(26005)(9686003)(486006)(561944003);
DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR18MB2949;
H:BYAPR18MB2424.namprd18.prod.outlook.com; FPR:; SPF:None; LANG:en;
PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: marvell.com does not designate
permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: 8WooXZvjLP/UBne2NUD+9BnkUdrBgcshjrjmL3smuKKyaU30CEP50DmuWzQCFD0m6f3dI9ikbKeKzOLfq7y0qSSeaicz0xqEbChdhq6zYQ0muFPMuzrcL/IdVCLfAjLHNE+5rCJyOvG5bx84a9GVaaxOQjU4Udrrwk2+AoZKi1L6rCY6/sYOT1bft7ZmQ+0yXnWCreWPaVM5hj8HDW3QQAKLDBzXHvkjZ+YfXMtTyt22BDRs/+ZTs1cFADLUjIkAYWDINbvbUamTEL+1ILruCeRylCbXa+rox0V378zwMjPzuSc8oSjhMaqQxnTp0ZEhaZ6mpwlmCjCKheAGtL8T8Tdkgwi3+DDsZfnjbfqsso6RqhlsdhmVLdpFPq9H1qiqA5RrXfA8q05MLo8A7Ghz0wYYx7Oo9AmZJcjEvDWbMDo=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: b5cea67b-5ec2-443c-68c3-08d6ea63a02f
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jun 2019 09:44:52.7718 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 70e1fb47-1155-421d-87fc-2e58f638b6e0
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: jerinj@marvell.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR18MB2949
X-OriginatorOrg: marvell.com
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, ,
definitions=2019-06-06_08:, , signatures=0
Subject: Re: [dpdk-dev] [EXT] [RFC PATCH 0/2] introduce __rte_internal tag
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>
> -----Original Message-----
> From: Neil Horman <nhorman@tuxdriver.com>
> Sent: Wednesday, June 5, 2019 11:41 PM
> To: Bruce Richardson <bruce.richardson@intel.com>
> Cc: Jerin Jacob Kollanukkaran <jerinj@marvell.com>; dev@dpdk.org; Thomas
> Monjalon <thomas@monjalon.net>
> Subject: Re: [EXT] [RFC PATCH 0/2] introduce __rte_internal tag
>=20
> On Wed, Jun 05, 2019 at 05:45:41PM +0100, Bruce Richardson wrote:
> > On Wed, Jun 05, 2019 at 04:24:09PM +0000, Jerin Jacob Kollanukkaran
> wrote:
> > > > -----Original Message-----
> > > > From: Neil Horman <nhorman@tuxdriver.com>
> > > > Sent: Sunday, May 26, 2019 12:14 AM
> > > > To: dev@dpdk.org
> > > > Cc: Neil Horman <nhorman@tuxdriver.com>; Jerin Jacob Kollanukkaran
> > > > <jerinj@marvell.com>; Bruce Richardson
> > > > <bruce.richardson@intel.com>; Thomas Monjalon
> > > > <thomas@monjalon.net>
> > > > Subject: [EXT] [RFC PATCH 0/2] introduce __rte_internal tag
> > > >
> > > > Hey-
> > > > Based on our recent conversations regarding the use of symbols
> > > > only meant for internal dpdk consumption (between dpdk libraries),
> > > > this is an idea that I've come up with that I'd like to get some
> > > > feedback on
> > > >
> > > > Summary:
> > > > 1) We have symbols in the DPDK that are meant to be used between
> > > > DPDK libraries, but not by applications linking to them
> > > > 2) We would like to document those symbols in the code, so as to
> > > > note them clearly as for being meant for internal use only
> > > > 3) Linker symbol visibility is a very coarse grained tool, and so
> > > > there is no good way in a single library to mark items as being
> > > > meant for use only by other DPDK libraries, at least not without
> > > > some extensive runtime checking
> > > >
> > > >
> > > > Proposal:
> > > > I'm proposing that we introduce the __rte_internal tag. From a
> > > > coding standpoint it works a great deal like the
> > > > __rte_experimental tag in that it expempts the tagged symbol from
> > > > ABI constraints (as the only users should be represented in the
> > > > DPDK build environment). Additionally, the __rte_internal macro
> > > > resolves differently based on the definition of the
> > > > BUILDING_RTE_SDK flag (working under the assumption that said flag
> > > > should only ever be set if we are actually building DPDK libraries
> > > > which will make use of internal calls). If the BUILDING_RTE_SDK
> > > > flag is set __rte_internal resolves to __attribute__((section
> > > > "text.internal)), placing it in a special text section which is
> > > > then used to validate that the the symbol appears in the INTERNAL
> > > > section of the corresponding library version map). If
> > > > BUILDING_RTE_SDK is not set, then __rte_internal resolves to
> __attribute__((error("..."))), which causes any caller of the tagged func=
tion
> to throw an error at compile time, indicating that the symbol is not avai=
lable
> for external use.
> > > >
> > > > This isn't a perfect solution, as applications can still hack
> > > > around it of course,
> > >
> > > I think, one way to, avoid, hack around could be to,
> > >
> > > 1) at config stage, create a random number for the build
> > > 2) introduce RTE_CALL_INTERNAL macro for calling internal function,
> > > compare the generated random number for allowing the calls to make
> > > within the library. i.e leverage the fact that external library
> > > would never know the random number generated for the DPDK build
> and internal driver code does.
> > >
> > Do we really need to care about this. If have some determined enough
> > to hack around our limitations, then they surely know that they have
> > an unsupported configuration. We just need to protect against
> > inadvertent use of internals, IMHO.
> >
> I agree, I too had thought about doing some sort of internal runtime chec=
king
> to match internal only symbols, such that they were only accessable by
> internally approved users, but it started to feel like a great deal of ov=
erhead.
> Its a good idea for a general mechanism I think, but I believe the value =
here is
> more to internally document which apis we want to mark as being for
> internal use only, and create a lightweight roadblock at build time to ca=
tch
> users inadvertently using them. Determined users will get around anythin=
g,
> and theres not much we can do to stop them.
I agree too. IMHO, Simply having following items would be enough
1) Avoid exposing the internal function prototype through public header fil=
es
2) Add @internal to API documentation
3) Just decide the name space for internal API for tooling(i.e not start wi=
th rte_ or so)
Using objdump scheme to detect internal functions requires the the library =
to build prior to run the checkpatch.
>=20
> If we really wanted to go down that road, we could use a mechainsm
> simmilar to the EXPORT_SYMBOL / EXPORT_SYMBOL_GPL infrastructure that
> the kernel uses, but that would required building our own custom linker
> script, which seems like overkill here.
>=20
> Best
> Neil
>=20
> > /Bruce
> >