Hello Thomas,
Sunday, June 28, 2015, 9:38:14 PM, you wrote:
> 2015-06-28 10:59, Matthew Hall:
>> It would appear there is some bug in the new lock elision patches that is
>> preventing it from compiling with clang. Any suggestions?
> It builds with clang.
> My suggestion is to add the patch aut
This patch adds a new auto-test for testing the scaling
of concurrent inserts into rte_hash when protected by
the normal spinlock vs. the spinlock with HTM lock
elision. The test also benchmarks single-threaded
access without any locks.
Signed-off-by: Roman Dementiev
Acked-by: Bruce Richardson
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.
Signed-off-by: Roman Dementiev
Acked-by: Bruce Richardson
---
lib/librte_eal/common/Makefile
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.
Signed-off-by: Roman Dementiev
Acked-by: Bruce Richardson
---
.../common/include/arch
-don't use angle brackets for rte_common.h include
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
This patch adds a new auto-test for testing the scaling
of concurrent inserts into rte_hash when protected by
the normal spinlock vs. the spinlock with HTM lock
elision. The test also benchmarks single-threaded
access without any locks.
Signed-off-by: Roman Dementiev
---
app/test/Makefile
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.
Signed-off-by: Roman Dementiev
---
lib/librte_eal/common/Makefile | 4
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.
Signed-off-by: Roman Dementiev
---
.../common/include/arch/ppc_64/rte_spinlock.h
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
Hello Stephen,
Wednesday, June 3, 2015, 8:40:14 PM, you wrote:
> On Tue, 2 Jun 2015 15:11:30 +0200
> 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
Hello Jay,
Tuesday, June 2, 2015, 3:21:24 PM, you wrote:
> On Tue, Jun 2, 2015 at 8:11 AM, Roman Dementiev 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
This patch adds a new auto-test for testing the scaling
of concurrent inserts into rte_hash when protected by
the normal spinlock vs. the spinlock with HTM lock
elision. The test also benchmarks single-threaded
access without any locks.
Signed-off-by: Roman Dementiev
---
app/test/Makefile
normal rwlock if HTM is not
available or memory transactions fail. This is not a replacement
for all rwlock usages since not all critical sections protected
by locks are friendly to HTM.
Signed-off-by: Roman Dementiev
---
lib/librte_eal/common/Makefile | 4 +-
.../common
the normal spinlock if HTM is not
available or memory transactions fail.
This is not a replacement for all spinlock usages since not all
critical sections protected by spinlocks are friendly to HTM.
Signed-off-by: Roman Dementiev
---
.../common/include/arch/ppc_64/rte_spinlock.h | 41
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
15 matches
Mail list logo
