From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.9 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 31B08C10F14 for ; Tue, 15 Oct 2019 12:16:40 +0000 (UTC) Received: from dpdk.org (dpdk.org [92.243.14.124]) by mail.kernel.org (Postfix) with ESMTP id B1CE521848 for ; Tue, 15 Oct 2019 12:16:39 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="SpX3L9DV" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B1CE521848 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=dev-bounces@dpdk.org Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id ED6771E8D6; Tue, 15 Oct 2019 14:16:38 +0200 (CEST) Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [207.211.31.120]) by dpdk.org (Postfix) with ESMTP id 8B55D1E8CB for ; Tue, 15 Oct 2019 14:16:37 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1571141796; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=IRhVTeNMFrlfeIsA1WQCqRP4f9XNw1K2IhVoRrxhDuk=; b=SpX3L9DVcWQYlZt2F3cfhExJ6qf+iiTulpvsSb5sDmILBjl336xMNqPNKicgGueGSukR5U ElqxKAcKVBHBzTfRmZ1LdcuIH/CJqpkx9JHZjEAT2+A3qotI4+3iHxn/A+enzoDgOCuUcA ygvWmTldIWeGwkORz4lzsiqFLBJm4hY= Received: from mail-vs1-f72.google.com (mail-vs1-f72.google.com [209.85.217.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-17-PvM0-IghM_Kx_gTtkNRr8A-1; Tue, 15 Oct 2019 08:16:33 -0400 Received: by mail-vs1-f72.google.com with SMTP id s123so2205696vss.5 for ; Tue, 15 Oct 2019 05:16:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xtolDHJT18bBWIPVGx15/s6z6SJwOxODwrop3alFppo=; b=f8/tzaOfV844XnWqT5gd3tvT0smeE+we502eMLfuC3TnXK6OJc65HrEw19rRuqGD94 1iLsWw4xowR/AhFiTdkWL6Bg+zgDATjmY/8l3XwVdU1UMr8N/kcXFB9JLL5swdkNM/zu JG8uB22luh92oMGQYVHbzJyvXq+XMMDUwaihuQ8o0VG7Spx5JZbKzgC4rhsA0F9bAmnQ 3ZI5BOdfMhoJ2451bHi8EtPgVJvJoolPLkcaILFvQNYTiuN3UI2cUCVeVbvtAnNZMVHx 3h/7O0DKTO0QVWHROe4ctJ1eG+y6ohfEmbQ8sitSCtCuj5FNnKHKLbTIFgiiCgNxHGyw ZVtw== X-Gm-Message-State: APjAAAVlbV3gI1aB3Ze2s6qIsAuCdlsSFmxQ4naQANIP8AqvdEKvZ7HW 4YWRGPdxOyLKpatWPk8fgWBDDyAkis7Zx6Uaa+2JZz9yvfsFpjLJNa02nYSLMHJaM9S3VmGsnG2 Zi+GHSvqOWALVr7a385k= X-Received: by 2002:a67:fc49:: with SMTP id p9mr19910939vsq.198.1571141792985; Tue, 15 Oct 2019 05:16:32 -0700 (PDT) X-Google-Smtp-Source: APXvYqxmiQUzg+FoY6pZzENyF0+L1lLLdXQbJrGqG3Bm7kQsL8BzdcqnQtWGtDuJB1xgCbHQWx1mSBUAs9UbEduVa/U= X-Received: by 2002:a67:fc49:: with SMTP id p9mr19910888vsq.198.1571141791987; Tue, 15 Oct 2019 05:16:31 -0700 (PDT) MIME-Version: 1.0 References: <20190723070536.30342-1-jerinj@marvell.com> <1565771263-27353-1-git-send-email-phil.yang@arm.com> In-Reply-To: From: David Marchand Date: Tue, 15 Oct 2019 14:16:20 +0200 Message-ID: To: "Phil Yang (Arm Technology China)" Cc: "thomas@monjalon.net" , "jerinj@marvell.com" , Gage Eads , dev , "hemant.agrawal@nxp.com" , Honnappa Nagarahalli , "Gavin Hu (Arm Technology China)" , nd X-MC-Unique: PvM0-IghM_Kx_gTtkNRr8A-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [dpdk-dev] [PATCH v9 1/3] eal/arm64: add 128-bit atomic compare exchange X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Tue, Oct 15, 2019 at 1:32 PM Phil Yang (Arm Technology China) wrote: > > -----Original Message----- > > From: David Marchand > > If LSE is available, we expose __rte_cas_XX (explicitely) *non* > > inlined functions, while without LSE, we expose inlined __rte_ldr_XX > > and __rte_stx_XX functions. > > So we have a first disparity with non-inlined vs inlined functions > > depending on a #ifdef. You did not comment on the inline / no inline part and I still see this in the v10. Is this __rte_noinline on the CAS function intentional? > > Then, we have a second disparity with two sets of "apis" depending on > > this #ifdef. > > > > And we expose those sets with a rte_ prefix, meaning people will try > > to use them, but those are not part of a public api. > > > > Can't we do without them ? (see below [2] for a proposal with ldr/stx, > > cas should be the same) > > No, it doesn't work. > Because we need to verify the return value at the end of the loop for the= se macros. Do you mean the return value for the stores? > > #define __STORE_128(op_string, dst, val, ret) \ > > asm volatile( \ > > op_string " %w0, %1, %2, %3" \ > > : "=3D&r" (ret) \ > > : "r" (val.val[0]), \ > > "r" (val.val[1]), \ > > "Q" (dst->val[0]) \ > > : "memory") The ret variable is still passed in this macro and the while loop can check it later. > > > diff --git a/lib/librte_eal/common/include/generic/rte_atomic.h > > b/lib/librte_eal/common/include/generic/rte_atomic.h > > > index 24ff7dc..e6ab15a 100644 > > > --- a/lib/librte_eal/common/include/generic/rte_atomic.h > > > +++ b/lib/librte_eal/common/include/generic/rte_atomic.h > > > @@ -1081,6 +1081,20 @@ static inline void > > rte_atomic64_clear(rte_atomic64_t *v) > > > > > > /*------------------------ 128 bit atomic operations ---------------= ----------*/ > > > > > > +/** > > > + * 128-bit integer structure. > > > + */ > > > +RTE_STD_C11 > > > +typedef struct { > > > + RTE_STD_C11 > > > + union { > > > + uint64_t val[2]; > > > +#ifdef RTE_ARCH_64 > > > + __extension__ __int128 int128; > > > +#endif > > > > You hid this field for x86. > > What is the reason? > No, we are not hid it for x86. The RTE_ARCH_64 flag covered x86 as well. Ah indeed, I read it wrong, ARCH_64 ... AARCH64 ... :-) -- David Marchand