[dpdk-dev] add support for HTM lock elision for x86

[Stephen Hemminger]

On Tue,  2 Jun 2015 15:11:30 +0200
Roman Dementiev <roman.dementiev at intel.com> 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 lock usages since not all critical sections protected
> by locks are friendly to HTM.
> 
> 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(-)
> 
> 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
> 

You probably want to put a caveat around this, it won't work for people
that expect to use spinlocks to protect I/O operations on hardware.
Since I/O operations aren't like memory.