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 1AA7BA0588; Sat, 21 Mar 2020 02:03:43 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id D82442BB9; Sat, 21 Mar 2020 02:03:41 +0100 (CET) Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id 11CB23B5 for ; Sat, 21 Mar 2020 02:03:39 +0100 (CET) IronPort-SDR: UtIOwJrkIm2HTPLmii/gTR7RMHn82PM6Bik3KBgrkkRiAIsfQDWXHo04j9yjrNvG9ZdS6GtSIo nEo3h473XipQ== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Mar 2020 18:03:38 -0700 IronPort-SDR: T9K1W9HJTXg6ULOZtWiWQzlrKwZJ1pcQ17f8aiW8z3GzawZGKyRyyVJY3nn4NkiKHinTzdqnzI 2DeN5DCNZSNA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.72,286,1580803200"; d="scan'208";a="418898735" Received: from fmsmsx103.amr.corp.intel.com ([10.18.124.201]) by orsmga005.jf.intel.com with ESMTP; 20 Mar 2020 18:03:38 -0700 Received: from fmsmsx608.amr.corp.intel.com (10.18.126.88) by FMSMSX103.amr.corp.intel.com (10.18.124.201) with Microsoft SMTP Server (TLS) id 14.3.439.0; Fri, 20 Mar 2020 18:03:38 -0700 Received: from fmsmsx606.amr.corp.intel.com (10.18.126.86) by fmsmsx608.amr.corp.intel.com (10.18.126.88) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Fri, 20 Mar 2020 18:03:37 -0700 Received: from FMSEDG001.ED.cps.intel.com (10.1.192.133) by fmsmsx606.amr.corp.intel.com (10.18.126.86) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.1713.5 via Frontend Transport; Fri, 20 Mar 2020 18:03:37 -0700 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (104.47.58.106) by edgegateway.intel.com (192.55.55.68) with Microsoft SMTP Server (TLS) id 14.3.439.0; Fri, 20 Mar 2020 18:03:37 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XIxvwtI2650mBeg5gjcvfh65A2ySC/F0nWbqGBoyy2filLzRfjigReSK4GAYu04iHvk/Oe5EMK2/BNlu6ND+j0C2F3h58MKi2u82nbBG6yTs66gQBypkXNDmFuv4rKsbz9ve10XgvyyaMYwoFX/ZZ5GRBQ8uYCHbZRuL57V8P8PDstEzwiOzMdGjNUCATKK7MpQ3+kh9dhP4ydrZmw5iX3pf2cmx7w4zjgsrFfP2z/XIV6RcEziSvYbMeIEm0Iy7HX/HZvpSI5KxSR77dZjXw7fMQvfZOIwXHkYpwK9CG6Jn8Fb0nHSQnzYHKkMH0nPZ+2AWoHo4ORZGqWvCBgPkXg== 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=60ruBXO59mfVNUjPOyhvVfWrhs3WuZqncOPqH5m3goM=; b=jqIInCGxheVNfxuH6DlEB/fto4vnqWnTA23fxtOVfjI6BCCDfMHz0wV9YK/KbWU7ibdecUP88B6gIuj0K43KJXNcr3HDwm1sY8SM2VwAKxFuqKyTIVeYIgF0oMae1tPRsijoNETZuTHQCkkXaSP0+yPJZTg/Xya7f4AYN7nwO9RZW8lJqqx7hJQUt8AL5DNFP2CukEB6s131LzSlFNsx/t2pa0JGxlrN3YkaBzG4NJAoSk1ltWnJgW0PjdasED9xCN6OMCrnULOxaWJHkMVYTjpEayGaLNiDONVV7k+f3a8sdYFTGuQVTLaM3y2lgczafNGLdYpY3Lv29iywikhzSQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel.onmicrosoft.com; s=selector2-intel-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=60ruBXO59mfVNUjPOyhvVfWrhs3WuZqncOPqH5m3goM=; b=UCKK7C9Qt1CYiVZjmisOlnQUwqlWgsg/spczQZUYEInVjF2NUmSKxZknJnGqKp7WrskYUoFej5cbbc2KjGPCCBcbOBDee3M0KEErdFuJxoSTRr7542sU1N3PJPXFh1wMP8Yam6zm0toHLiy/JduoL1bSNeoQHX82My2/JTRvpAk= Received: from SN6PR11MB2558.namprd11.prod.outlook.com (2603:10b6:805:5d::19) by SN6PR11MB2813.namprd11.prod.outlook.com (2603:10b6:805:61::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2835.20; Sat, 21 Mar 2020 01:03:36 +0000 Received: from SN6PR11MB2558.namprd11.prod.outlook.com ([fe80::5df7:d515:ec1d:8db1]) by SN6PR11MB2558.namprd11.prod.outlook.com ([fe80::5df7:d515:ec1d:8db1%7]) with mapi id 15.20.2835.017; Sat, 21 Mar 2020 01:03:35 +0000 From: "Ananyev, Konstantin" To: Stephen Hemminger CC: "dev@dpdk.org" , "olivier.matz@6wind.com" , "honnappa.nagarahalli@arm.com" , "jerinj@marvell.com" , "drc@linux.vnet.ibm.com" Thread-Topic: [RFC] ring: make ring implementation non-inlined Thread-Index: AQHV/taErFO0KtyJb0SAaV/LyHULbKhRw46AgAB3HwA= Date: Sat, 21 Mar 2020 01:03:35 +0000 Message-ID: References: <20200320164138.8510-1-konstantin.ananyev@intel.com> <20200320105435.47681954@hermes.lan> In-Reply-To: <20200320105435.47681954@hermes.lan> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-reaction: no-action dlp-version: 11.2.0.6 authentication-results: spf=none (sender IP is ) smtp.mailfrom=konstantin.ananyev@intel.com; x-originating-ip: [192.198.151.182] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e3b3e3f0-bdd3-4553-1319-08d7cd33af01 x-ms-traffictypediagnostic: SN6PR11MB2813: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 034902F5BC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(376002)(39860400002)(136003)(396003)(346002)(199004)(81156014)(8676002)(81166006)(9686003)(8936002)(4326008)(966005)(86362001)(478600001)(6916009)(71200400001)(66556008)(33656002)(66946007)(7696005)(54906003)(2906002)(186003)(52536014)(66476007)(76116006)(66446008)(55016002)(64756008)(316002)(5660300002)(6506007)(26005)(53546011); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR11MB2813; H:SN6PR11MB2558.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: JveDz9O3Yp8Wjb3CRiaFR2dwhwt60YEw4USo92H/u+usrG+Duuee1gfyAA24Pv/kHcLlyOGswhdOenGluEF8pWDoN27SdsUGQB0D1tR2OQSSSpUfVLDkZGD06fFq6gOD8b6fgs9ZZIYWYo81NH64FJ2kv8XfGC2FOESKlJuqNjpxmd/FicdLG5bQhSgScl2yZO283IXAvt+KTfY7vOKJ7E1yd4yIT6GiXddnkICWKBJxY7HZET9Pu9YxmNY3joL3m3ZzswGAnwoOzWtoYBwSau0H5v7rR9vweEW8ZU5fgVmURnQTNQ38ndb7HnqeZitc/rcnpiETqzAkCkQLaI+dkZXMSExEJCDxzwxokHhmSuI6Ts9hSkKpHRkD7lkAUQ5o0c0JFYCeBc6RnxrQtbC8DCp7Bi2Y93wLHb/SRFmERv/alywgnNwhCyCUYjR44DWjpmrbpRCdmh7P8m0ZN5y02ZdNpYSGqOciQnWcUiWIxkbVRQRmRGFlQWjEVuSqDTe2eCWj6k/2CxE8DjZWdPKW4g== x-ms-exchange-antispam-messagedata: i78jgx+cRisDpvUv2wBMQjN8EW1VNOZ6/4bpa5CBMFutGQcBHhdb08zCdxT7S+uzqfPZuHCfs9PjAaH2I63J511jrjJj/nizNxELMXxhQ8ttoupVoLhyIjKFe80t9kMvZoirxPufLueRNzAITKvp0Q== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: e3b3e3f0-bdd3-4553-1319-08d7cd33af01 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Mar 2020 01:03:35.8354 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: rTlMo0hXYpxAR0fl/+VBiWAmpPFN0XKaYW9A70MkdajhqmLk9TwHprEew0XUOFc3TwTC8rqpkpp/Ffgogk4FdYg7/GfQfFowBKAZHZSHi50= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR11MB2813 X-OriginatorOrg: intel.com Subject: Re: [dpdk-dev] [RFC] ring: make ring implementation non-inlined 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: Stephen Hemminger > Sent: Friday, March 20, 2020 5:55 PM > To: Ananyev, Konstantin > Cc: dev@dpdk.org; olivier.matz@6wind.com; honnappa.nagarahalli@arm.com; j= erinj@marvell.com; drc@linux.vnet.ibm.com > Subject: Re: [RFC] ring: make ring implementation non-inlined >=20 > On Fri, 20 Mar 2020 16:41:38 +0000 > Konstantin Ananyev wrote: >=20 > > As was discussed here: > > http://mails.dpdk.org/archives/dev/2020-February/158586.html > > this RFC aimed to hide ring internals into .c and make all > > ring functions non-inlined. In theory that might help to > > maintain ABI stability in future. > > This is just a POC to measure the impact of proposed idea, > > proper implementation would definetly need some extra effort. > > On IA box (SKX) ring_perf_autotest shows ~20-30 cycles extra for > > enqueue+dequeue pair. On some more realistic code, I suspect > > the impact it might be a bit higher. > > For MP/MC bulk transfers degradation seems quite small, > > though for SP/SC and/or small transfers it is more then noticable > > (see exact numbers below). > > From my perspective we'd probably keep it inlined for now > > to avoid any non-anticipated perfomance degradations. > > Though intersted to see perf results and opinions from > > other interested parties. > > > > Intel(R) Xeon(R) Platinum 8160 CPU @ 2.10GHz > > ring_perf_autotest (without patch/with patch) > > > > ### Testing single element enq/deq ### > > legacy APIs: SP/SC: single: 8.75/43.23 > > legacy APIs: MP/MC: single: 56.18/80.44 > > > > ### Testing burst enq/deq ### > > legacy APIs: SP/SC: burst (size: 8): 37.36/53.37 > > legacy APIs: SP/SC: burst (size: 32): 93.97/117.30 > > legacy APIs: MP/MC: burst (size: 8): 78.23/91.45 > > legacy APIs: MP/MC: burst (size: 32): 131.59/152.49 > > > > ### Testing bulk enq/deq ### > > legacy APIs: SP/SC: bulk (size: 8): 37.29/54.48 > > legacy APIs: SP/SC: bulk (size: 32): 92.68/113.01 > > legacy APIs: MP/MC: bulk (size: 8): 78.40/93.50 > > legacy APIs: MP/MC: bulk (size: 32): 131.49/154.25 > > > > ### Testing empty bulk deq ### > > legacy APIs: SP/SC: bulk (size: 8): 4.00/16.86 > > legacy APIs: MP/MC: bulk (size: 8): 7.01/15.55 > > > > ### Testing using two hyperthreads ### > > legacy APIs: SP/SC: bulk (size: 8): 10.64/17.56 > > legacy APIs: MP/MC: bulk (size: 8): 15.30/16.69 > > legacy APIs: SP/SC: bulk (size: 32): 5.84/7.09 > > legacy APIs: MP/MC: bulk (size: 32): 6.34/7.54 > > > > ### Testing using two physical cores ### > > legacy APIs: SP/SC: bulk (size: 8): 24.34/42.40 > > legacy APIs: MP/MC: bulk (size: 8): 70.34/71.82 > > legacy APIs: SP/SC: bulk (size: 32): 12.67/14.68 > > legacy APIs: MP/MC: bulk (size: 32): 22.41/17.93 > > > > ### Testing single element enq/deq ### > > elem APIs: element size 16B: SP/SC: single: 10.65/41.96 > > elem APIs: element size 16B: MP/MC: single: 44.33/81.36 > > > > ### Testing burst enq/deq ### > > elem APIs: element size 16B: SP/SC: burst (size: 8): 39.20/58.52 > > elem APIs: element size 16B: SP/SC: burst (size: 32): 123.19/142.79 > > elem APIs: element size 16B: MP/MC: burst (size: 8): 80.72/101.36 > > elem APIs: element size 16B: MP/MC: burst (size: 32): 169.21/185.38 > > > > ### Testing bulk enq/deq ### > > elem APIs: element size 16B: SP/SC: bulk (size: 8): 41.64/58.46 > > elem APIs: element size 16B: SP/SC: bulk (size: 32): 122.74/142.52 > > elem APIs: element size 16B: MP/MC: bulk (size: 8): 80.60/103.14 > > elem APIs: element size 16B: MP/MC: bulk (size: 32): 169.39/186.67 > > > > ### Testing empty bulk deq ### > > elem APIs: element size 16B: SP/SC: bulk (size: 8): 5.01/17.17 > > elem APIs: element size 16B: MP/MC: bulk (size: 8): 6.01/14.80 > > > > ### Testing using two hyperthreads ### > > elem APIs: element size 16B: SP/SC: bulk (size: 8): 12.02/17.18 > > elem APIs: element size 16B: MP/MC: bulk (size: 8): 16.81/21.14 > > elem APIs: element size 16B: SP/SC: bulk (size: 32): 7.87/9.01 > > elem APIs: element size 16B: MP/MC: bulk (size: 32): 8.22/10.57 > > > > ### Testing using two physical cores ### > > elem APIs: element size 16B: SP/SC: bulk (size: 8): 27.00/51.94 > > elem APIs: element size 16B: MP/MC: bulk (size: 8): 78.24/74.48 > > elem APIs: element size 16B: SP/SC: bulk (size: 32): 15.41/16.14 > > elem APIs: element size 16B: MP/MC: bulk (size: 32): 18.72/21.64 > > > > Signed-off-by: Konstantin Ananyev >=20 > What is impact with LTO? I suspect compiler might have a chance to > get speed back with LTO. Might be, but LTO is not enabled by default. So don't see much point in digging any further here.