From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) by dpdk.org (Postfix) with ESMTP id B991FC3C2 for ; Wed, 17 Jun 2015 15:15:49 +0200 (CEST) Received: by wgv5 with SMTP id 5so36811301wgv.1 for ; Wed, 17 Jun 2015 06:15:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:organization :user-agent:in-reply-to:references:mime-version :content-transfer-encoding:content-type; bh=nccJYaFHzC37Iv/gGheEUFtVJ8HIgR5YtRH23H7BGlo=; b=fobBiKlE7cyy8AtnmeIXL+v/douMw65YwlOOMptPC3ByWt/6XXi8tt8dqVYyf6O7ub MDzdisvc4EEYXW+x6JTZFzVuktXcS3IttCrZMml9/8un0hTVO5EhMIh69G95Kt+6VYk7 NI6Ig4KQOLq9xxh5Us+M4wXO9iJYD7nyXaciaFrR/toa4lIoQ6c9MNMFpcH/RRVyjGD2 UmhOVZ0/8BVPneo3KRDLlIqiIkKFiBECX6pBCvGyMNj82hJYF3MQxXmfsw1JhRs7i37P qgFSYtHraduMU9Lyw2jIX80s1oqMuk+jueHCxOa/2uPrJkiC12IEnHaghh1h2gOsOknk NQkg== X-Gm-Message-State: ALoCoQkm0UIhqLr79o+K7UICG7PttnqalKl3bdBkT21p8fEvecI46S/2ch2dvD+2iKiaqWVEyd7u X-Received: by 10.180.11.225 with SMTP id t1mr3308296wib.94.1434546949616; Wed, 17 Jun 2015 06:15:49 -0700 (PDT) Received: from xps13.localnet (136-92-190-109.dsl.ovh.fr. [109.190.92.136]) by mx.google.com with ESMTPSA id qq1sm6766099wjc.0.2015.06.17.06.15.48 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 17 Jun 2015 06:15:48 -0700 (PDT) From: Thomas Monjalon To: Bruce Richardson Date: Wed, 17 Jun 2015 15:14:49 +0200 Message-ID: <2512427.xQU6O25ACN@xps13> Organization: 6WIND User-Agent: KMail/4.14.8 (Linux/4.0.4-2-ARCH; KDE/4.14.8; x86_64; ; ) In-Reply-To: <20150617130551.GA8208@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> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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:15:49 -0000 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? > Thomas, is a V3 needed for this small conflict, or can you handle it on applying > the patch? Don't worry about conflicts.