From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id DA9F5C348 for ; Tue, 2 Jun 2015 16:55:34 +0200 (CEST) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga103.jf.intel.com with ESMTP; 02 Jun 2015 07:55:32 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.13,540,1427785200"; d="scan'208";a="501562182" Received: from obarbu-mobl.ger.corp.intel.com ([10.252.44.135]) by FMSMGA003.fm.intel.com with ESMTP; 02 Jun 2015 07:55:31 -0700 Date: Tue, 2 Jun 2015 16:55:30 +0200 From: Roman Dementiev X-Priority: 3 (Normal) Message-ID: <1281433045.20150602165530@intel.com> To: Jay Rolette In-Reply-To: References: <1433250693-23644-1-git-send-email-roman.dementiev@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: DPDK Subject: Re: [dpdk-dev] add support for HTM lock elision for x86 X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2015 14:55:35 -0000 Hello Jay, Tuesday, June 2, 2015, 3:21:24 PM, you wrote: > On Tue, Jun 2, 2015 at 8:11 AM, Roman Dementiev wrote: > This series of patches adds methods that use hardware memory transactions (HTM) > on fast-path for DPDK locks (a.k.a. lock elision). Here the methods are implemented > for x86 using Restricted Transactional Memory instructions (Intel(r) Transactional > Synchronization Extensions). The implementation fall-backs to the normal DPDK lock > if HTM is not available or memory transactions fail. It provides a very good scaling given the protected data structure is friendly to HTM. One example is rte_hash which is benchmarked in the unit test I have provided as the last patch. There are some papers showing additional test results with similar lock elision implementations: www.intel.com/software/tsx > This is very interesting. Do you have any summary you can give us > of what the performance implications are from your test data? > > This is not a replacement for lock usages since not all critical sections protected > by locks are friendly to HTM. > Any pointers to material that describe where HTM in its current incarnation on x86 is approprate? > > I meant to say: not a replacement to *ALL* lock usages. You can check the material here: www.intel.com/software/tsx Please let me know if you need additional information. > Roman Dementiev (3): > spinlock: add support for HTM lock elision for x86 > rwlock: add support for HTM lock elision for x86 > test scaling of HTM lock elision protecting rte_hash > > app/test/Makefile | 1 + > app/test/test_hash_scaling.c | 223 +++++++++++++++++++++ > lib/librte_eal/common/Makefile | 4 +- > .../common/include/arch/ppc_64/rte_rwlock.h | 38 ++++ > .../common/include/arch/ppc_64/rte_spinlock.h | 41 ++++ > lib/librte_eal/common/include/arch/x86/rte_rtm.h | 73 +++++++ > .../common/include/arch/x86/rte_rwlock.h | 82 ++++++++ > .../common/include/arch/x86/rte_spinlock.h | 107 ++++++++++ > lib/librte_eal/common/include/generic/rte_rwlock.h | 194 ++++++++++++++++++ > .../common/include/generic/rte_spinlock.h | 75 +++++++ > lib/librte_eal/common/include/rte_rwlock.h | 158 --------------- > 11 files changed, 836 insertions(+), 160 deletions(-) > Thanks! > Jay -- Best regards, Roman mailto:roman.dementiev@intel.com Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen, Deutschland Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk Registergericht: Muenchen HRB 47456 Ust.-IdNr./VAT Registration No.: DE129385895 Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052