| Message ID | 20210412082901.652736-1-kda@semihalf.com (mailing list archive) |
|---|---|
| Headers |
Return-Path: <dev-bounces@dpdk.org> X-Original-To: patchwork@inbox.dpdk.org Delivered-To: patchwork@inbox.dpdk.org Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 22C05A0C44; Mon, 12 Apr 2021 10:29:31 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id B6601140F88; Mon, 12 Apr 2021 10:29:30 +0200 (CEST) Received: from mail-lf1-f43.google.com (mail-lf1-f43.google.com [209.85.167.43]) by mails.dpdk.org (Postfix) with ESMTP id 749354014E for <dev@dpdk.org>; Mon, 12 Apr 2021 10:29:29 +0200 (CEST) Received: by mail-lf1-f43.google.com with SMTP id x13so9878721lfr.2 for <dev@dpdk.org>; Mon, 12 Apr 2021 01:29:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=semihalf-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=vewlak+FqWPyil4AUIUcrvD2gQ5X0FHMsFKWyN5U1B4=; b=X+8tn/dX3Y+PGB5Succ9tAE7I2z2xpoj5fWSTAFtZUe7cW+qqiqNmw/95nP7NXrM4k A1tksO9Ljvf6H/EunJQ2EKBfHa3RxXKmzQqipKm/wK6gn2byYCP/8/s4pBO1THEXUzhV 00M7UsE3wjoBUZKRyeuJ/Vh0L7wdeVcLKCvmOm7axHAYmvNTxe/ogRV04oJPIpA/VjyX heLdd8rZ6+hpb8JG75Znt8hgr7Ry5ZZPKzlGs0Bd5LRiR+L+kEK6yK//yXkGE1jZtqFQ jgTapS/2KyyDtid9/KMWCvnusS7yEM0pkv+IsrtfFIevIabi/8Y45blT3yQPIMxjWGGI 0E+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=vewlak+FqWPyil4AUIUcrvD2gQ5X0FHMsFKWyN5U1B4=; b=R4H91kWLWRYApQu5k2eDHKaoizHtOQPyXEpeXKZyJ73C7TvD2rILWHD3Z7QFXM2nAO jFXq4nmORhq1Qe3KlCMyJ31Gt/QyX6tjzTaUiOfhVlJYYmsngXp3J7HAaSwpAJjSyfl/ 764Oivh86l2RnPDzcm7t4BuQZir/bhhfQ00szFodaly1VGc9Cf/1koA1wdm1+bUaPQoH b5FlDotQVGBFtX8d7xhjeKg+g4XOczGkwH4nzBZGU8ah36GxSXN4adyQEYKTafJyTqlv ycnkz+DG4pP61DFyJNZNCKFzynL0ZUr9etDoo4TkBEjDAynAKeHbRImfAIHdSw1/0nF2 B4gQ== X-Gm-Message-State: AOAM531kvLq3LkAyYyjyT7GfBD82ljaB8IPTyZWJ9QD92MSopKobPr3z XSbhApgjT+u6tet027pua/rMMw== X-Google-Smtp-Source: ABdhPJwwXMWvEWtn/kY69tv9/4Vs94ISdoQg1bZrGjctHswxNekC4rB/9IR/FTi24JpDbbSVSEdG6w== X-Received: by 2002:a19:3804:: with SMTP id f4mr19061374lfa.117.1618216168942; Mon, 12 Apr 2021 01:29:28 -0700 (PDT) Received: from toster.semihalf.com (host-193.106.246.139.static.3s.pl. [193.106.246.139]) by smtp.gmail.com with ESMTPSA id x4sm2691118ljd.112.2021.04.12.01.29.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 12 Apr 2021 01:29:28 -0700 (PDT) From: Stanislaw Kardach <kda@semihalf.com> To: Olivier Matz <olivier.matz@6wind.com> Cc: dev@dpdk.org, Stanislaw Kardach <kda@semihalf.com>, stable@dpdk.org Date: Mon, 12 Apr 2021 10:28:58 +0200 Message-Id: <20210412082901.652736-1-kda@semihalf.com> X-Mailer: git-send-email 2.27.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Subject: [dpdk-dev] [PATCH 0/3] add lock-free stack support discovery X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 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 |
add lock-free stack support discovery
|
|
Message
Stanislaw Kardach
April 12, 2021, 8:28 a.m. UTC
The lock-free stack implementation (RTE_STACK_F_LF) is supported only on a subset of platforms, namely x86_64 and arm64. Platforms supporting 128b atomics have to opt-in to a generic or C11 implementations. All other platforms use a stubbed implementation for push/pop operations which are basically NOPs. However rte_stack_create() will not fail and application can proceed assuming it has a working lock-free stack. This means that among other things the stack_lf fast and perf tests will fail as if implementation is wrong (which one can argue is). Therefore this patchset tries to give user a way to check whether a lock_free is supported or not both at compile time (build flag) and at runtime (ENOTSUP errno in rte_stack_create). I have added cc to stable@dpdk.org because check-git-log.sh suggested it. I'm not sure if adding a binary compatible change to API is worth stable@dpdk.org. Cc: stable@dpdk.org Stanislaw Kardach (3): stack: update lock-free supported archs stack: add compile flag for lock-free support test: run lock-free stack tests when supported app/test/test_stack.c | 4 ++++ app/test/test_stack_perf.c | 4 ++++ doc/guides/rel_notes/release_21_05.rst | 4 ++++ lib/librte_stack/rte_stack.c | 4 +++- lib/librte_stack/rte_stack.h | 3 ++- lib/librte_stack/rte_stack_lf.h | 5 +++++ 6 files changed, 22 insertions(+), 2 deletions(-)
Comments
On Mon, Apr 12, 2021 at 10:29 AM Stanislaw Kardach <kda@semihalf.com> wrote: > > The lock-free stack implementation (RTE_STACK_F_LF) is supported only on a > subset of platforms, namely x86_64 and arm64. Platforms supporting 128b atomics > have to opt-in to a generic or C11 implementations. All other platforms use a > stubbed implementation for push/pop operations which are basically NOPs. > However rte_stack_create() will not fail and application can proceed assuming > it has a working lock-free stack. Did you actually hit this issue or is this only theoretical? I can only think of ppc64 displaying such behavior.
On Fri, Apr 16, 2021 at 08:34:29AM +0200, David Marchand wrote: > On Mon, Apr 12, 2021 at 10:29 AM Stanislaw Kardach <kda@semihalf.com> wrote: > > > > The lock-free stack implementation (RTE_STACK_F_LF) is supported only on a > > subset of platforms, namely x86_64 and arm64. Platforms supporting 128b atomics > > have to opt-in to a generic or C11 implementations. All other platforms use a > > stubbed implementation for push/pop operations which are basically NOPs. > > However rte_stack_create() will not fail and application can proceed assuming > > it has a working lock-free stack. > > Did you actually hit this issue or is this only theoretical? > I can only think of ppc64 displaying such behavior. > I actually hit this issue while working on a RISC-V port. My reasoning here is that sooner or later someone else will stumble upon this, either on ppc64 or while trying to port to some new platform. It is also a really nasty limitation do debug given the silent nature of the failure. > > -- > David Marchand > -- Best Regards, Stanislaw Kardach
On Mon, Apr 12, 2021 at 10:29 AM Stanislaw Kardach <kda@semihalf.com> wrote: > > The lock-free stack implementation (RTE_STACK_F_LF) is supported only on a > subset of platforms, namely x86_64 and arm64. Platforms supporting 128b atomics > have to opt-in to a generic or C11 implementations. All other platforms use a > stubbed implementation for push/pop operations which are basically NOPs. > However rte_stack_create() will not fail and application can proceed assuming > it has a working lock-free stack. > > This means that among other things the stack_lf fast and perf tests will fail > as if implementation is wrong (which one can argue is). Therefore this patchset > tries to give user a way to check whether a lock_free is supported or not both > at compile time (build flag) and at runtime (ENOTSUP errno in rte_stack_create). > > I have added cc to stable@dpdk.org because check-git-log.sh suggested it. I'm > not sure if adding a binary compatible change to API is worth stable@dpdk.org. > > Cc: stable@dpdk.org The issue was hit while porting to a new architecture. The feature is broken in existing stable releases and it won't get fixed by this change. I'd rather not backport it. Opinions?
On Mon, May 03, 2021 at 04:21:25PM +0200, David Marchand wrote: > On Mon, Apr 12, 2021 at 10:29 AM Stanislaw Kardach <kda@semihalf.com> wrote: > > > > The lock-free stack implementation (RTE_STACK_F_LF) is supported only on a > > subset of platforms, namely x86_64 and arm64. Platforms supporting 128b atomics > > have to opt-in to a generic or C11 implementations. All other platforms use a > > stubbed implementation for push/pop operations which are basically NOPs. > > However rte_stack_create() will not fail and application can proceed assuming > > it has a working lock-free stack. > > > > This means that among other things the stack_lf fast and perf tests will fail > > as if implementation is wrong (which one can argue is). Therefore this patchset > > tries to give user a way to check whether a lock_free is supported or not both > > at compile time (build flag) and at runtime (ENOTSUP errno in rte_stack_create). > > > > I have added cc to stable@dpdk.org because check-git-log.sh suggested it. I'm > > not sure if adding a binary compatible change to API is worth stable@dpdk.org. > > > > Cc: stable@dpdk.org > > The issue was hit while porting to a new architecture. > The feature is broken in existing stable releases and it won't get > fixed by this change. > > I'd rather not backport it. > > Opinions? Agreed.
On Mon, 3 May 2021, 16:28 Olivier Matz, <olivier.matz@6wind.com> wrote: > On Mon, May 03, 2021 at 04:21:25PM +0200, David Marchand wrote: > > On Mon, Apr 12, 2021 at 10:29 AM Stanislaw Kardach <kda@semihalf.com> > wrote: > > > > > > The lock-free stack implementation (RTE_STACK_F_LF) is supported only > on a > > > subset of platforms, namely x86_64 and arm64. Platforms supporting > 128b atomics > > > have to opt-in to a generic or C11 implementations. All other > platforms use a > > > stubbed implementation for push/pop operations which are basically > NOPs. > > > However rte_stack_create() will not fail and application can proceed > assuming > > > it has a working lock-free stack. > > > > > > This means that among other things the stack_lf fast and perf tests > will fail > > > as if implementation is wrong (which one can argue is). Therefore this > patchset > > > tries to give user a way to check whether a lock_free is supported or > not both > > > at compile time (build flag) and at runtime (ENOTSUP errno in > rte_stack_create). > > > > > > I have added cc to stable@dpdk.org because check-git-log.sh suggested > it. I'm > > > not sure if adding a binary compatible change to API is worth > stable@dpdk.org. > > > > > > Cc: stable@dpdk.org > > > > The issue was hit while porting to a new architecture. > > The feature is broken in existing stable releases and it won't get > > fixed by this change. > > > > I'd rather not backport it. > > > > Opinions? > > Agreed. > Agreed. >
On Mon, May 3, 2021 at 8:35 PM Stanisław Kardach <kda@semihalf.com> wrote: > On Mon, 3 May 2021, 16:28 Olivier Matz, <olivier.matz@6wind.com> wrote: >> On Mon, May 03, 2021 at 04:21:25PM +0200, David Marchand wrote: >> > On Mon, Apr 12, 2021 at 10:29 AM Stanislaw Kardach <kda@semihalf.com> wrote: >> > > >> > > I have added cc to stable@dpdk.org because check-git-log.sh suggested it. I'm >> > > not sure if adding a binary compatible change to API is worth stable@dpdk.org. >> > > >> > > Cc: stable@dpdk.org >> > >> > The issue was hit while porting to a new architecture. >> > The feature is broken in existing stable releases and it won't get >> > fixed by this change. >> > >> > I'd rather not backport it. >> > >> > Opinions? >> >> Agreed. > > Agreed. Ok, thanks. I'll take this series dropping Cc: stable.
On Mon, Apr 12, 2021 at 10:29 AM Stanislaw Kardach <kda@semihalf.com> wrote: > > The lock-free stack implementation (RTE_STACK_F_LF) is supported only on a > subset of platforms, namely x86_64 and arm64. Platforms supporting 128b atomics > have to opt-in to a generic or C11 implementations. All other platforms use a > stubbed implementation for push/pop operations which are basically NOPs. > However rte_stack_create() will not fail and application can proceed assuming > it has a working lock-free stack. > > This means that among other things the stack_lf fast and perf tests will fail > as if implementation is wrong (which one can argue is). Therefore this patchset > tries to give user a way to check whether a lock_free is supported or not both > at compile time (build flag) and at runtime (ENOTSUP errno in rte_stack_create). Series applied. Thanks Stanislaw!