Message ID | 1563896626-44862-1-git-send-email-gavin.hu@arm.com (mailing list archive) |
---|---|
Headers |
Return-Path: <dev-bounces@dpdk.org> X-Original-To: patchwork@dpdk.org Delivered-To: patchwork@dpdk.org Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 5CFC81C043; Tue, 23 Jul 2019 17:43:59 +0200 (CEST) Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by dpdk.org (Postfix) with ESMTP id 0030C1C039 for <dev@dpdk.org>; Tue, 23 Jul 2019 17:43:57 +0200 (CEST) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 4DC6D28; Tue, 23 Jul 2019 08:43:57 -0700 (PDT) Received: from net-arm-thunderx2.shanghai.arm.com (net-arm-thunderx2.shanghai.arm.com [10.169.40.40]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 8CC863F71A; Tue, 23 Jul 2019 08:43:55 -0700 (PDT) From: Gavin Hu <gavin.hu@arm.com> To: dev@dpdk.org Cc: nd@arm.com, thomas@monjalon.net, stephen@networkplumber.org, jerinj@marvell.com, pbhagavatula@marvell.com, Honnappa.Nagarahalli@arm.com, gavin.hu@arm.com Date: Tue, 23 Jul 2019 23:43:41 +0800 Message-Id: <1563896626-44862-1-git-send-email-gavin.hu@arm.com> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1561911676-37718-1-git-send-email-gavin.hu@arm.com> References: <1561911676-37718-1-git-send-email-gavin.hu@arm.com> Subject: [dpdk-dev] [PATCH v3 0/5] use WFE for locks and ring on aarch64 X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions <dev.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org Sender: "dev" <dev-bounces@dpdk.org> |
Series |
use WFE for locks and ring on aarch64
|
|
Message
Gavin Hu
July 23, 2019, 3:43 p.m. UTC
DPDK has multiple use cases where the core repeatedly polls a location in memory. This polling results in many cache and memory transactions. Arm architecture provides WFE (Wait For Event) instruction, which allows the cpu core to enter a low power state until woken up by the update to the memory location being polled. Thus reducing the cache and memory transactions. x86 has the PAUSE hint instruction to reduce such overhead. The rte_wait_until_equal_xxx APIs abstract the functionality of 'polling for a memory location to become equal to a given value'. For non-Arm platforms, these APIs are just wrappers around do-while loop with rte_pause, so there are no performance differences. For Arm platforms, use of WFE can be configured using CONFIG_RTE_USE_WFE option. It is disabled by default. Currently, use of WFE is supported only for aarch64 platforms. armv7 platforms do support the WFE instruction, but they require explicit wake up events(sev) and are less performannt. Testing shows that, performance varies across different platforms, with some showing degradation. CONFIG_RTE_USE_WFE should be enabled depending on the performance on the target platforms. V3: * Convert RFCs to patches V2: * Use inline functions instead of marcos * Add load and compare in the beginning of the APIs * Fix some style errors in asm inline V1: * Add the new APIs and use it for ring and locks Gavin Hu (5): eal: add the APIs to wait until equal ticketlock: use new API to reduce contention on aarch64 ring: use wfe to wait for ring tail update on aarch64 spinlock: use wfe to reduce contention on aarch64 config: add WFE config entry for aarch64 config/arm/meson.build | 1 + config/common_armv8a_linux | 6 ++ .../common/include/arch/arm/rte_atomic_64.h | 4 + .../common/include/arch/arm/rte_pause_64.h | 106 +++++++++++++++++++++ .../common/include/arch/arm/rte_spinlock.h | 25 +++++ lib/librte_eal/common/include/generic/rte_pause.h | 39 +++++++- .../common/include/generic/rte_spinlock.h | 2 +- .../common/include/generic/rte_ticketlock.h | 3 +- lib/librte_ring/rte_ring_c11_mem.h | 4 +- lib/librte_ring/rte_ring_generic.h | 3 +- 10 files changed, 185 insertions(+), 8 deletions(-)
Comments
Hi Gavin, I think this should have been V1 (I mean, no versioning, just 'PATCH'), since it is converted to patch. I think we should be able to resend it as V1 and mark this V3 as 'superseded'. Hi Thomas, Please let us know if it is worth/helps fixing the version. Thanks, Honnappa > -----Original Message----- > From: Gavin Hu <gavin.hu@arm.com> > Sent: Tuesday, July 23, 2019 10:44 AM > To: dev@dpdk.org > Cc: nd <nd@arm.com>; thomas@monjalon.net; > stephen@networkplumber.org; jerinj@marvell.com; > pbhagavatula@marvell.com; Honnappa Nagarahalli > <Honnappa.Nagarahalli@arm.com>; Gavin Hu (Arm Technology China) > <Gavin.Hu@arm.com> > Subject: [PATCH v3 0/5] use WFE for locks and ring on aarch64 > > DPDK has multiple use cases where the core repeatedly polls a location in > memory. This polling results in many cache and memory transactions. > > Arm architecture provides WFE (Wait For Event) instruction, which allows the > cpu core to enter a low power state until woken up by the update to the > memory location being polled. Thus reducing the cache and memory > transactions. > > x86 has the PAUSE hint instruction to reduce such overhead. > > The rte_wait_until_equal_xxx APIs abstract the functionality of 'polling for a > memory location to become equal to a given value'. > > For non-Arm platforms, these APIs are just wrappers around do-while loop > with rte_pause, so there are no performance differences. > > For Arm platforms, use of WFE can be configured using > CONFIG_RTE_USE_WFE option. It is disabled by default. > > Currently, use of WFE is supported only for aarch64 platforms. armv7 > platforms do support the WFE instruction, but they require explicit wake up > events(sev) and are less performannt. > > Testing shows that, performance varies across different platforms, with some > showing degradation. > > CONFIG_RTE_USE_WFE should be enabled depending on the performance on > the target platforms. > > V3: > * Convert RFCs to patches > V2: > * Use inline functions instead of marcos > * Add load and compare in the beginning of the APIs > * Fix some style errors in asm inline > V1: > * Add the new APIs and use it for ring and locks > > Gavin Hu (5): > eal: add the APIs to wait until equal > ticketlock: use new API to reduce contention on aarch64 > ring: use wfe to wait for ring tail update on aarch64 > spinlock: use wfe to reduce contention on aarch64 > config: add WFE config entry for aarch64 > > config/arm/meson.build | 1 + > config/common_armv8a_linux | 6 ++ > .../common/include/arch/arm/rte_atomic_64.h | 4 + > .../common/include/arch/arm/rte_pause_64.h | 106 > +++++++++++++++++++++ > .../common/include/arch/arm/rte_spinlock.h | 25 +++++ > lib/librte_eal/common/include/generic/rte_pause.h | 39 +++++++- > .../common/include/generic/rte_spinlock.h | 2 +- > .../common/include/generic/rte_ticketlock.h | 3 +- > lib/librte_ring/rte_ring_c11_mem.h | 4 +- > lib/librte_ring/rte_ring_generic.h | 3 +- > 10 files changed, 185 insertions(+), 8 deletions(-) > > -- > 2.7.4
23/07/2019 21:15, Honnappa Nagarahalli: > Hi Gavin, > I think this should have been V1 (I mean, no versioning, just 'PATCH'), since it is converted to patch. I think we should be able to resend it as V1 and mark this V3 as 'superseded'. > > Hi Thomas, > Please let us know if it is worth/helps fixing the version. I don't follow why it should be v1.
> > 23/07/2019 21:15, Honnappa Nagarahalli: > > Hi Gavin, > > I think this should have been V1 (I mean, no versioning, just 'PATCH'), > since it is converted to patch. I think we should be able to resend it as V1 and > mark this V3 as 'superseded'. > > > > Hi Thomas, > > Please let us know if it is worth/helps fixing the version. > > I don't follow why it should be v1. This patch series was a RFC (RFC V1 and RFC v2). It is converted to a patch, I thought it should start with V1. > >
24/07/2019 04:44, Honnappa Nagarahalli: > > 23/07/2019 21:15, Honnappa Nagarahalli: > > > Hi Gavin, > > > I think this should have been V1 (I mean, no versioning, just 'PATCH'), > > since it is converted to patch. I think we should be able to resend it as V1 and > > mark this V3 as 'superseded'. > > > > > > Hi Thomas, > > > Please let us know if it is worth/helps fixing the version. > > > > I don't follow why it should be v1. > > This patch series was a RFC (RFC V1 and RFC v2). It is converted to a patch, I thought it should start with V1. No it can keep incrementing, it is OK and clear.