From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id DF798A0613 for ; Tue, 30 Jul 2019 18:24:45 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id A3A5B1BF17; Tue, 30 Jul 2019 18:24:45 +0200 (CEST) Received: from mx0b-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) by dpdk.org (Postfix) with ESMTP id A84071BF08 for ; Tue, 30 Jul 2019 18:24:43 +0200 (CEST) Received: from pps.filterd (m0045849.ppops.net [127.0.0.1]) by mx0a-0016f401.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id x6UGK6Ed024751; Tue, 30 Jul 2019 09:24:42 -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=1XQItEjMmgxwvJ5HMQor3v+yUQDDGuUKHg4Re34TR2I=; b=dwlPJg1SKgrDSmIentGU6fLJIN/wdTBsqAqeBuOpyDszhBG+KIZ6AxpH6MrxdKsBybFo JOZ3cLGF2C/PuTEYN4Q4/yXaCNiA4USsiNp5v2cXEsIAC8KSSkmS30yWv7PSR4VWCQOo gG+ly8P0Qcae1qiKI4l6a+ajFyvC64vqYIpKpzUYb0kDNspny8MqN5otV5DrD2hBtGnq 6GSD6TNmlHz3vd6df1jiEICOzgPo6SP5vFdnDH4H/pEhdhXrQujQTi/2ieQHAUr4anSg ZlG0mXttRqpXMb+/74HYOb2+5Cr4rIr8zv2ICSoUVWZ6nEHCU7/qoXuMclhkH1xzDFkz Hg== Received: from sc-exch02.marvell.com ([199.233.58.182]) by mx0a-0016f401.pphosted.com with ESMTP id 2u0kyq5p08-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 30 Jul 2019 09:24:42 -0700 Received: from SC-EXCH02.marvell.com (10.93.176.82) by SC-EXCH02.marvell.com (10.93.176.82) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Tue, 30 Jul 2019 09:24:41 -0700 Received: from NAM05-BY2-obe.outbound.protection.outlook.com (104.47.50.51) by SC-EXCH02.marvell.com (10.93.176.82) with Microsoft SMTP Server (TLS) id 15.0.1367.3 via Frontend Transport; Tue, 30 Jul 2019 09:24:41 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=eiR7Uk+6zFdkH2U0i2y6ibYLcO902gnmc3ifkM4CHrlClpMBkLiUFGNcN4gHuHADsPVUls0c0JLU4pWTQ+h52DF3y+itIZjSOaGN5PwLUY1zyRwqWW1mwFGV/Hko1i12qZFj98a9IftWCkqwUTAaJuLv9CvTOK1aM4UyX7p6XgyHTBzA5OkxByOQ8aBogWF0khHbSA9d8BF+y5wTaA1wq+tYzc1WEbSsk0PKZ+oe7F1Me9Esg244mPGraDb4PXRKfXK9N8lynCvk5hbh5UWejT/cRYmZcoD5dN4zjFK7wU+LOXlJlqJliveUC+y6Vk6FPfMil8nsJP5r3ow19Rzwhg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1XQItEjMmgxwvJ5HMQor3v+yUQDDGuUKHg4Re34TR2I=; b=Xk1DLz76t/geotFuI2FtbTkbWC90oJ1xs9wOrQE1fqbDXIiUXKsVMtq4Szp5NAsJAE3PjE+T46Nv1p1jrgKdDKnNOy0cnFY67IZIKBh963y4qhczSgjr3rCR4Emayb3tvI9QY1NF+5tiU+Xj6BuUx6hQ70XgZqAAFC4Varr5cUL0ZBHaxFoxSwAxRbMoNVztRqwYAjtv7j/4OrzF72BjQ/SHCRJOETCFyvD/DPFs5G2M3slZZJRiQM/RZgiFKhOKB9SxTK8w7XI0upBra4Ad4unbZUfX3E3kO/wUVdsaOMETIjs27o+2/mX9nxCa3jHL+0Xgo+3AISeZ2u39oTdzTg== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=marvell.com;dmarc=pass action=none header.from=marvell.com;dkim=pass header.d=marvell.com;arc=none 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=1XQItEjMmgxwvJ5HMQor3v+yUQDDGuUKHg4Re34TR2I=; b=rtn/Wl2JuLnLEE9p8ez1Wm7rkM6UQ6NnpYYqfXsyL5Sp7yxAtifzCxKBXqFIIyJdc1CoAzBfjzoxf1KUldTLY5RrGH2SITyeqoY/FcvhHD8Raclk4UAIYGBh7BubKhqyTnxyRNkzdwwUIu78DVKaG7AyOAICNIxSceGFQPrxm1o= Received: from BYAPR18MB2424.namprd18.prod.outlook.com (20.179.91.149) by BYAPR18MB3015.namprd18.prod.outlook.com (20.179.94.161) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2115.13; Tue, 30 Jul 2019 16:24:40 +0000 Received: from BYAPR18MB2424.namprd18.prod.outlook.com ([fe80::2d42:12b6:aa2e:2862]) by BYAPR18MB2424.namprd18.prod.outlook.com ([fe80::2d42:12b6:aa2e:2862%4]) with mapi id 15.20.2115.005; Tue, 30 Jul 2019 16:24:40 +0000 From: Jerin Jacob Kollanukkaran To: Bruce Richardson CC: Marcin Zapolski , "dev@dpdk.org" Thread-Topic: [EXT] Re: [dpdk-dev] [RFC 19.11 1/2] ethdev: make DPDK core functions non-inline Thread-Index: AQHVRvDNBkbPu4OavUWYNtmYVyq53KbjVXZw Date: Tue, 30 Jul 2019 16:24:40 +0000 Message-ID: References: <20190730160553.GC1689@bricha3-MOBL.ger.corp.intel.com> In-Reply-To: <20190730160553.GC1689@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: [106.200.247.60] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 10ac2a0d-1925-4a45-e760-08d7150a6c55 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BYAPR18MB3015; x-ms-traffictypediagnostic: BYAPR18MB3015: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0114FF88F6 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(136003)(396003)(39860400002)(376002)(346002)(189003)(199004)(43544003)(13464003)(7736002)(102836004)(186003)(2906002)(5660300002)(99286004)(25786009)(54906003)(66066001)(4326008)(8676002)(55016002)(9686003)(316002)(6506007)(52536014)(81156014)(6116002)(7696005)(14444005)(26005)(53546011)(11346002)(486006)(76176011)(256004)(478600001)(3846002)(81166006)(305945005)(74316002)(6916009)(68736007)(33656002)(71190400001)(64756008)(8936002)(71200400001)(66946007)(66446008)(76116006)(229853002)(14454004)(476003)(446003)(53936002)(6246003)(6436002)(66476007)(66556008)(86362001); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR18MB3015; H:BYAPR18MB2424.namprd18.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A: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: P/9X4Zv15Mqp48KzUlMmQmOSczZFgohnCicGkMG2eZH26SFphR6lzeHSrv2TUG/76a2m2qUcKAsOXy40dyelWIz56Od/LabT48+TFyfMr6nljohdzCpR/lJY7fAl9yxoESwDPXF9NJnp0kL95tCGwiBjZU0dcmUMQtCn94eJPYF9lxAUoJUNtn4bK2qlR6wjJhjIWPwEr+dQsx6OLpTSPGCpZGU2m/nYo/voHTfkuPzKKEB1Tsa1e9gee7VBXyJ/mtlLAgISGVMXzbAhHsXy4507e39gPBjnjUHsCuc5M2iX7lKI+U3zeCsLSkuRqEhUX63Jy4ndmexCcYVbXcOevaPglEu1TExjXxYeDd0Hi7KIlvjUcYq+egWjmm/jBVbp4Pj0KccpAzmOq6bt3Tc2n3Y14uQc2CkhShkvO0+aYb4= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 10ac2a0d-1925-4a45-e760-08d7150a6c55 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jul 2019 16:24:40.5641 (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: BYAPR18MB3015 X-OriginatorOrg: marvell.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:5.22.84,1.0.8 definitions=2019-07-30_07:2019-07-29,2019-07-30 signatures=0 Subject: Re: [dpdk-dev] [EXT] Re: [RFC 19.11 1/2] ethdev: make DPDK core functions non-inline 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" > -----Original Message----- > From: Bruce Richardson > Sent: Tuesday, July 30, 2019 9:36 PM > To: Jerin Jacob Kollanukkaran > Cc: Marcin Zapolski ; dev@dpdk.org > Subject: [EXT] Re: [dpdk-dev] [RFC 19.11 1/2] ethdev: make DPDK core func= tions > non-inline >=20 > On Tue, Jul 30, 2019 at 03:45:38PM +0000, Jerin Jacob Kollanukkaran wrote= : > > > -----Original Message----- > > > From: Bruce Richardson > > > Sent: Tuesday, July 30, 2019 9:02 PM > > > To: Jerin Jacob Kollanukkaran > > > Cc: Marcin Zapolski ; dev@dpdk.org > > > Subject: [EXT] Re: [dpdk-dev] [RFC 19.11 1/2] ethdev: make DPDK core > > > functions non-inline > > > > > > -------------------------------------------------------------------- > > > -- On Tue, Jul 30, 2019 at 03:01:00PM +0000, Jerin Jacob > > > Kollanukkaran wrote: > > > > > -----Original Message----- From: dev On > > > > > Behalf Of Marcin Zapolski Sent: Tuesday, July 30, 2019 6:20 PM To= : > > > > > dev@dpdk.org Cc: Marcin Zapolski > > > > > Subject: [dpdk-dev] [RFC 19.11 1/2] ethdev: make DPDK core > > > > > functions > > > > > non- inline > > > > > > > > > > Make rte_eth_rx_burst, rte_eth_tx_burst and other static inline > > > > > ethdev functions not inline. They are referencing DPDK internal > > > > > structures and inlining forces those structures to be exposed to > > > > > user > > > applications. > > > > > > > > > > In internal testing with i40e NICs a performance drop of about > > > > > 2% was observed with testpmd. > > > > > > > > I tested on two class of arm64 machines(Highend and lowend) one > > > > has 1.4% drop And other one has 3.6% drop. > > > > > > > This is with testpmd only right? I'd just point out that we need to > > > remember that these numbers need to be scaled down appropriately for > > > a realworld app where IO is only a (hopefully small) proportion of > > > the packet processing budget. For example, I would expect the ~2% > > > drop we saw in testpmd to correspond to <0.5% drop in something like = OVS. > > > > I see it as bit different view, Cycles saved infrastructure layer, > > cycles gained in application. So IMO it vary between end user > > application need what kind of machine it runs. > > > Sure. My thinking more is that to get ABI compatibility involves some tra= deoffs > and spending one more cycle per-packet when an app workload is typically > hundreds of cycles, I believe, is a small cost worth paying. I agree. But, We need take only the cost, If it is really costs.I don't thi= nk, we don't need two level of indirection. >=20 > > > > > > > I second to not expose internal data structure to avoid ABI break. > > > > > > > > IMO, This patch has performance issue due to it is fixing it in > > > > simple way. > > > > > > > > It is not worth two have function call overhead to call the driver > > > > function. Some thoughts below to reduce the performance impact > > > > without exposing internal structures. > > > > > > > The big concern I have with what you propose is that would involve > > > changing each and every ethdev driver in DPDK! I'd prefer to make > > > sure that the impact of this change is actually felt in real-world > > > apps before we start looking to make such updates across the DPDK > codebase. > > > > I see those changes are NO BRAINER from driver POV. Once we add in one > > driver, individual PMD Maintainer can update easily. I think, we can do= it once > for all. >=20 > Ok, if it's doable in one go then sure. The issue is that if even one dri= ver is not > updated we can't switch over, all have to effectively be done simultaneou= sly. [It I agree. But I think, we can give enough time for driver to migrate. If it does not migrate in time. We can take necessary action to fix it. If it is a no brainer changes then all drivers will do it. We cannot pay co= st Because one driver is not maintaining. I can commit to take care of ALL Mar= vell PMDs. > would also make backporting fixes trickier, but I wouldn't be concerned a= bout > that particularly.] >=20 > Have you tried out making the changes to a driver or two, to see how larg= e the > delta is? [And to verify it doesn't affect performance] I hope, The RFC author will take first stab, I can help in reviewing it. >=20 > > I am sure, you must aware of How hard is make 2% improvement in > > driver. I can spend time in This NO brainer to get 2% improvement back.= I > prefer later. > > > The other alternative I see is to leave the inline functions there, just = disabled by > default, and put in a build-time option for reduced ABI compatibility. Th= at way > the standard-built packages are all ABI compatible, but for those who abs= olutely > need max perf and are rolling-their-own-build to get it can disable that = ABI > compatibility. But currently there no ABI break. Right? We should do it before we have one= on those structures. I think, we should cleanup the low hanging ones first and to fa= st path structures in parallel. >=20 > /Bruce