From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id 0B252C422 for ; Wed, 17 Jun 2015 15:48:27 +0200 (CEST) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga102.fm.intel.com with ESMTP; 17 Jun 2015 06:48:26 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.13,632,1427785200"; d="scan'208";a="712631543" Received: from bricha3-mobl3.ger.corp.intel.com ([10.243.20.21]) by orsmga001.jf.intel.com with SMTP; 17 Jun 2015 06:48:24 -0700 Received: by (sSMTP sendmail emulation); Wed, 17 Jun 2015 14:48:23 +0025 Date: Wed, 17 Jun 2015 14:48:23 +0100 From: Bruce Richardson To: Thomas Monjalon Message-ID: <20150617134823.GB8208@bricha3-MOBL3> References: <1433250693-23644-1-git-send-email-roman.dementiev@intel.com> <1434475006-13732-1-git-send-email-roman.dementiev@intel.com> <20150617130551.GA8208@bricha3-MOBL3> <2512427.xQU6O25ACN@xps13> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2512427.xQU6O25ACN@xps13> Organization: Intel Shannon Ltd. User-Agent: Mutt/1.5.23 (2014-03-12) Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH v2 0/3] 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: Wed, 17 Jun 2015 13:48:28 -0000 On Wed, Jun 17, 2015 at 03:14:49PM +0200, Thomas Monjalon wrote: > 2015-06-17 14:05, Bruce Richardson: > > On Tue, Jun 16, 2015 at 10:16:43AM -0700, 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. This > > > is not a replacement for ALL lock usages since not all critical sections > > > protected by locks are friendly to HTM. For example, an attempt to perform > > > a HW I/O operation inside a hardware memory transaction always aborts > > > the transaction since the CPU is not able to roll-back should the transaction > > > fail. Therefore, hardware transactional locks are not advised to be used around > > > rte_eth_rx_burst() and rte_eth_tx_burst() calls. > > > > > > v2 changes > > > -added a documentation note about hardware limitations > > > > > > 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 > > > > > A change with a conflict in the test makefile was merged last night. However, > > the patches themselves otherwise seem ok. > > Does it mean you ack these patches and they can be blindly applied > without double checking? > Series Acked-by: Bruce Richardson