From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) by dpdk.org (Postfix) with ESMTP id 32DAB1B885 for ; Wed, 17 Apr 2019 19:47:00 +0200 (CEST) Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x3HHgidD012387; Wed, 17 Apr 2019 10:46:40 -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=Yk1zZrjDqvNK/sLWqkXhLi009B8djYUzzpGj2Ll9yD8=; b=QnsGr/wKQd6UR2f09s372F0xk7/fYTtITTKxO/Zihxwj5tJW3JaIrtXaGcodenb2HYxY gvPIIyB334KFRkmQSrSaT8yrHBujta3876Rz6i0SOJSpgD7nK+2V0JGM7Rum12oF9TqB O4IfI2IKEht5/aOY9YBOar+0RVOhIil1+dTFSsNc5ObfuY3ilP9CZwzDcsWYGPTXFpYT Z2iJyfeywuBkkGBmjtCodfunD2nOdWYJAmtpRNvyneJ/2QabaptjyQtXgxnFEoIU5jEO NOLb8iWt1lN2GO5ArODIeMg9rMykcKqKrraNBcLbuVdo14Z1P3yjwJZekqONZ6XPGqPE 7g== Received: from sc-exch02.marvell.com ([199.233.58.182]) by mx0b-0016f401.pphosted.com with ESMTP id 2rwyuf225t-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 17 Apr 2019 10:46:38 -0700 Received: from SC-EXCH01.marvell.com (10.93.176.81) by SC-EXCH02.marvell.com (10.93.176.82) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Wed, 17 Apr 2019 10:46:36 -0700 Received: from NAM01-BY2-obe.outbound.protection.outlook.com (104.47.34.53) by SC-EXCH01.marvell.com (10.93.176.81) with Microsoft SMTP Server (TLS) id 15.0.1367.3 via Frontend Transport; Wed, 17 Apr 2019 10:46:36 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marvell.onmicrosoft.com; s=selector1-marvell-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Yk1zZrjDqvNK/sLWqkXhLi009B8djYUzzpGj2Ll9yD8=; b=Av6nW6HtCABUx46RLL2//u9cTaWSW2GXpSxP6+BChReYn+gPmtUE67MkeFtsU+Hj8bW7PS1f0qbOJRYbiFl01xZfLZjANi7xn7G2A3aOMUKMJ6A6pS/QlT6mIO5p9GiyK94HqxCfmhT35Ki+r0Lq8e3QcKE24VnE3qaKQKNyqb0= Received: from BYAPR18MB2424.namprd18.prod.outlook.com (20.179.91.149) by BYAPR18MB2471.namprd18.prod.outlook.com (20.179.92.85) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1813.11; Wed, 17 Apr 2019 17:46:34 +0000 Received: from BYAPR18MB2424.namprd18.prod.outlook.com ([fe80::6dd3:c056:b23b:ab4e]) by BYAPR18MB2424.namprd18.prod.outlook.com ([fe80::6dd3:c056:b23b:ab4e%7]) with mapi id 15.20.1813.011; Wed, 17 Apr 2019 17:46:34 +0000 From: Jerin Jacob Kollanukkaran To: Bruce Richardson , Honnappa Nagarahalli CC: "dev@dpdk.org" , Stephen Hemminger , "Ananyev, Konstantin" , "thomas@monjalon.net" , Ray Kinsella , nd Thread-Topic: [dpdk-dev] ABI and inline functions Thread-Index: AdT03C2s3ZB+VIuxS0mLCJ+6mgHcvgAHH6YAABKU0YA= Date: Wed, 17 Apr 2019 17:46:34 +0000 Message-ID: References: <20190417083637.GB1890@bricha3-MOBL.ger.corp.intel.com> In-Reply-To: <20190417083637.GB1890@bricha3-MOBL.ger.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [116.68.105.181] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 27e124d3-90f2-47b4-fd66-08d6c35ca254 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600141)(711020)(4605104)(4534185)(7168020)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:BYAPR18MB2471; x-ms-traffictypediagnostic: BYAPR18MB2471: x-microsoft-antispam-prvs: x-forefront-prvs: 0010D93EFE x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(396003)(376002)(366004)(346002)(39860400002)(199004)(189003)(13464003)(52314003)(476003)(6436002)(486006)(11346002)(81166006)(74316002)(26005)(229853002)(4326008)(14444005)(186003)(71200400001)(14454004)(71190400001)(256004)(53546011)(25786009)(446003)(8936002)(102836004)(66066001)(7736002)(81156014)(76176011)(106356001)(105586002)(2906002)(305945005)(3846002)(5660300002)(55236004)(8676002)(6506007)(97736004)(6116002)(86362001)(53936002)(55016002)(478600001)(99286004)(7696005)(33656002)(52536014)(316002)(68736007)(6246003)(110136005)(54906003)(9686003); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR18MB2471; 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: uVFPAYzutjcaFOV1BJDGrJ1y1Mc4Auxu+lZrVEG3s4CYyaaCjKz7ehRkqIrEedbJUiC2AnSZs7XI517AqcbW1yX6oLo3Zl/pOVwMr7rIsfQ1sQ3JiJihUqL618JzVnwcFcY8nDCJMRGOYSH79F1D/Zr1PtIOgcXBBfIMOCtwgS3c4OtaXHUBS4VwwtC0b5lwa7YpfHVsKHgljT9Sf/rg0cHHCuUqr6jb4SNAp41bFyMD4kEBrojeqavSF5NVcnWTXofJTH0ZfBH986w17ZF+uQAm1JBswNU+FeYfRgS6KjnlW6fCGHufQw9arJBIiq1EiTePlLvatZ3dZAMxGLeOFd60u4dCnNkuEStaO1cHuAFdTexTGhhxT/G0fCVxin5jZOUPlaPN9mec83FwFsVR3NxxJjRrgCMKV6fvk22gq4k= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 27e124d3-90f2-47b4-fd66-08d6c35ca254 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Apr 2019 17:46:34.5468 (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-Transport-CrossTenantHeadersStamped: BYAPR18MB2471 X-OriginatorOrg: marvell.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-04-17_07:, , signatures=0 Subject: Re: [dpdk-dev] ABI and inline functions 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: Wed, 17 Apr 2019 17:47:00 -0000 > -----Original Message----- > From: dev On Behalf Of Bruce Richardson > Sent: Wednesday, April 17, 2019 2:07 PM > To: Honnappa Nagarahalli > Cc: dev@dpdk.org; Stephen Hemminger ; > Ananyev, Konstantin ; thomas@monjalon.net; > Ray Kinsella ; nd > Subject: Re: [dpdk-dev] ABI and inline functions >=20 > > 2) Every function that is not in the direct datapath (fastpath?) > > should not be inline. Exceptions or things like rx/tx burst, ring > > enqueue/dequeue, and packet alloc/free - Stephen >=20 > Agree with this. Anything not data path should not be inline. The next qu= estion > then is for data path items how to determine whether they need to be inli= ne or > not. In general my rule-of-thumb: > * anything dealing with bursts of packets should not be inline # I think, we need consider the how fat is the function too, If it is light weight, probably we need to make it inline # Except the forward case, In real world use case, it is not trivial make l= arge=20 burst of packet to process it even though function prototype burst. We may need to consider that # For the given function if some argument is used with inline other functio= n, probably no point in making that function alone inline as the structure=20 is exposed in some other function. > * anything what works with single packet at a time should be inline >=20 > > In this context, does it make sense to say that we will maintain API > > compatibility rather than saying ABI compatibility? This will also > > send the right message to the end users. > > > I would value ABI compatibility much higher than API compatibility. If so= meone > is recompiling the application anyway, making a couple of small changes (= large > rework is obviously a different issue) to the code should not be a massiv= e issue, I > hope. On the other hand, ABI compatibility is needed to allow seamless up= date > from one version to another, and it's that ABI compatiblity that allows d= istro's to > pick up our latest and greatest versions. IMO, We have two primary use case for DPDK 1) NFV kind of use case where the application needs to run on multiple pla= tform without recompiling it. 2) Fixed appliance use case where embed SoC like Intel Denverton or ARM64 i= ntegrated Controller used. For fixed appliance use case, end user care more of perfor= mance than ABI compatibility as it easy to recompile the end user application vs = the cost of hitting performance impact. IMO, DPDK needs to cater to both category. My 2c. >=20 > Personally, I'd be happy enough to allow API changes at any point without > deprecation notice, so long as function versioning is used to ensure ABI > compatibility is kept. >=20 > My 2c. > /Bruce From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id B7644A00E6 for ; Wed, 17 Apr 2019 19:47:02 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 0091D1B88C; Wed, 17 Apr 2019 19:47:01 +0200 (CEST) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) by dpdk.org (Postfix) with ESMTP id 32DAB1B885 for ; Wed, 17 Apr 2019 19:47:00 +0200 (CEST) Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x3HHgidD012387; Wed, 17 Apr 2019 10:46:40 -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=Yk1zZrjDqvNK/sLWqkXhLi009B8djYUzzpGj2Ll9yD8=; b=QnsGr/wKQd6UR2f09s372F0xk7/fYTtITTKxO/Zihxwj5tJW3JaIrtXaGcodenb2HYxY gvPIIyB334KFRkmQSrSaT8yrHBujta3876Rz6i0SOJSpgD7nK+2V0JGM7Rum12oF9TqB O4IfI2IKEht5/aOY9YBOar+0RVOhIil1+dTFSsNc5ObfuY3ilP9CZwzDcsWYGPTXFpYT Z2iJyfeywuBkkGBmjtCodfunD2nOdWYJAmtpRNvyneJ/2QabaptjyQtXgxnFEoIU5jEO NOLb8iWt1lN2GO5ArODIeMg9rMykcKqKrraNBcLbuVdo14Z1P3yjwJZekqONZ6XPGqPE 7g== Received: from sc-exch02.marvell.com ([199.233.58.182]) by mx0b-0016f401.pphosted.com with ESMTP id 2rwyuf225t-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 17 Apr 2019 10:46:38 -0700 Received: from SC-EXCH01.marvell.com (10.93.176.81) by SC-EXCH02.marvell.com (10.93.176.82) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Wed, 17 Apr 2019 10:46:36 -0700 Received: from NAM01-BY2-obe.outbound.protection.outlook.com (104.47.34.53) by SC-EXCH01.marvell.com (10.93.176.81) with Microsoft SMTP Server (TLS) id 15.0.1367.3 via Frontend Transport; Wed, 17 Apr 2019 10:46:36 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marvell.onmicrosoft.com; s=selector1-marvell-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Yk1zZrjDqvNK/sLWqkXhLi009B8djYUzzpGj2Ll9yD8=; b=Av6nW6HtCABUx46RLL2//u9cTaWSW2GXpSxP6+BChReYn+gPmtUE67MkeFtsU+Hj8bW7PS1f0qbOJRYbiFl01xZfLZjANi7xn7G2A3aOMUKMJ6A6pS/QlT6mIO5p9GiyK94HqxCfmhT35Ki+r0Lq8e3QcKE24VnE3qaKQKNyqb0= Received: from BYAPR18MB2424.namprd18.prod.outlook.com (20.179.91.149) by BYAPR18MB2471.namprd18.prod.outlook.com (20.179.92.85) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1813.11; Wed, 17 Apr 2019 17:46:34 +0000 Received: from BYAPR18MB2424.namprd18.prod.outlook.com ([fe80::6dd3:c056:b23b:ab4e]) by BYAPR18MB2424.namprd18.prod.outlook.com ([fe80::6dd3:c056:b23b:ab4e%7]) with mapi id 15.20.1813.011; Wed, 17 Apr 2019 17:46:34 +0000 From: Jerin Jacob Kollanukkaran To: Bruce Richardson , Honnappa Nagarahalli CC: "dev@dpdk.org" , Stephen Hemminger , "Ananyev, Konstantin" , "thomas@monjalon.net" , Ray Kinsella , nd Thread-Topic: [dpdk-dev] ABI and inline functions Thread-Index: AdT03C2s3ZB+VIuxS0mLCJ+6mgHcvgAHH6YAABKU0YA= Date: Wed, 17 Apr 2019 17:46:34 +0000 Message-ID: References: <20190417083637.GB1890@bricha3-MOBL.ger.corp.intel.com> In-Reply-To: <20190417083637.GB1890@bricha3-MOBL.ger.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [116.68.105.181] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 27e124d3-90f2-47b4-fd66-08d6c35ca254 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600141)(711020)(4605104)(4534185)(7168020)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:BYAPR18MB2471; x-ms-traffictypediagnostic: BYAPR18MB2471: x-microsoft-antispam-prvs: x-forefront-prvs: 0010D93EFE x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(396003)(376002)(366004)(346002)(39860400002)(199004)(189003)(13464003)(52314003)(476003)(6436002)(486006)(11346002)(81166006)(74316002)(26005)(229853002)(4326008)(14444005)(186003)(71200400001)(14454004)(71190400001)(256004)(53546011)(25786009)(446003)(8936002)(102836004)(66066001)(7736002)(81156014)(76176011)(106356001)(105586002)(2906002)(305945005)(3846002)(5660300002)(55236004)(8676002)(6506007)(97736004)(6116002)(86362001)(53936002)(55016002)(478600001)(99286004)(7696005)(33656002)(52536014)(316002)(68736007)(6246003)(110136005)(54906003)(9686003); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR18MB2471; 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: uVFPAYzutjcaFOV1BJDGrJ1y1Mc4Auxu+lZrVEG3s4CYyaaCjKz7ehRkqIrEedbJUiC2AnSZs7XI517AqcbW1yX6oLo3Zl/pOVwMr7rIsfQ1sQ3JiJihUqL618JzVnwcFcY8nDCJMRGOYSH79F1D/Zr1PtIOgcXBBfIMOCtwgS3c4OtaXHUBS4VwwtC0b5lwa7YpfHVsKHgljT9Sf/rg0cHHCuUqr6jb4SNAp41bFyMD4kEBrojeqavSF5NVcnWTXofJTH0ZfBH986w17ZF+uQAm1JBswNU+FeYfRgS6KjnlW6fCGHufQw9arJBIiq1EiTePlLvatZ3dZAMxGLeOFd60u4dCnNkuEStaO1cHuAFdTexTGhhxT/G0fCVxin5jZOUPlaPN9mec83FwFsVR3NxxJjRrgCMKV6fvk22gq4k= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 27e124d3-90f2-47b4-fd66-08d6c35ca254 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Apr 2019 17:46:34.5468 (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-Transport-CrossTenantHeadersStamped: BYAPR18MB2471 X-OriginatorOrg: marvell.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-04-17_07:, , signatures=0 Subject: Re: [dpdk-dev] ABI and inline functions 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Message-ID: <20190417174634.PTqPErUNQBUuevV7vC_A22zRg-ykGe6-Y07_sii613I@z> > -----Original Message----- > From: dev On Behalf Of Bruce Richardson > Sent: Wednesday, April 17, 2019 2:07 PM > To: Honnappa Nagarahalli > Cc: dev@dpdk.org; Stephen Hemminger ; > Ananyev, Konstantin ; thomas@monjalon.net; > Ray Kinsella ; nd > Subject: Re: [dpdk-dev] ABI and inline functions >=20 > > 2) Every function that is not in the direct datapath (fastpath?) > > should not be inline. Exceptions or things like rx/tx burst, ring > > enqueue/dequeue, and packet alloc/free - Stephen >=20 > Agree with this. Anything not data path should not be inline. The next qu= estion > then is for data path items how to determine whether they need to be inli= ne or > not. In general my rule-of-thumb: > * anything dealing with bursts of packets should not be inline # I think, we need consider the how fat is the function too, If it is light weight, probably we need to make it inline # Except the forward case, In real world use case, it is not trivial make l= arge=20 burst of packet to process it even though function prototype burst. We may need to consider that # For the given function if some argument is used with inline other functio= n, probably no point in making that function alone inline as the structure=20 is exposed in some other function. > * anything what works with single packet at a time should be inline >=20 > > In this context, does it make sense to say that we will maintain API > > compatibility rather than saying ABI compatibility? This will also > > send the right message to the end users. > > > I would value ABI compatibility much higher than API compatibility. If so= meone > is recompiling the application anyway, making a couple of small changes (= large > rework is obviously a different issue) to the code should not be a massiv= e issue, I > hope. On the other hand, ABI compatibility is needed to allow seamless up= date > from one version to another, and it's that ABI compatiblity that allows d= istro's to > pick up our latest and greatest versions. IMO, We have two primary use case for DPDK 1) NFV kind of use case where the application needs to run on multiple pla= tform without recompiling it. 2) Fixed appliance use case where embed SoC like Intel Denverton or ARM64 i= ntegrated Controller used. For fixed appliance use case, end user care more of perfor= mance than ABI compatibility as it easy to recompile the end user application vs = the cost of hitting performance impact. IMO, DPDK needs to cater to both category. My 2c. >=20 > Personally, I'd be happy enough to allow API changes at any point without > deprecation notice, so long as function versioning is used to ensure ABI > compatibility is kept. >=20 > My 2c. > /Bruce