From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id AF519A04F7; Tue, 7 Jan 2020 02:26:13 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 185B21D8C9; Tue, 7 Jan 2020 02:26:13 +0100 (CET) Received: from mail-pf1-f196.google.com (mail-pf1-f196.google.com [209.85.210.196]) by dpdk.org (Postfix) with ESMTP id 304371D736 for ; Tue, 7 Jan 2020 02:26:11 +0100 (CET) Received: by mail-pf1-f196.google.com with SMTP id i6so20909745pfc.1 for ; Mon, 06 Jan 2020 17:26:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=tB0OJAOtpN/nzb6lX+OIoslxWEEdk4L6wUPXrtA80WU=; b=NvQPs2L7noH9AcufMPpqLNYx1GD8+XJ2oYOHJJ9smTJ5gEdA/18VxIkUUj66lNQWAl 7qjqHpfM1fM7rzqDchBD2XvqbjdZSkcak5rk4QHSabc1CIU7uNmz2V89YC7SjlJBrd/0 Hcp1KsxVZGoC0Xgeq9pv1Fd1bD99Dfm6vLbR/xl4HNZ/jdhvixRtb4Utd7rke2SjF11S lcDWalhn/Xij5+mB7WjePBxpGQALy0OKgLXed+S66GzyivBnOl9QqNQcolTaNmv6Vo/l nC+bw3DDZH/RdpguZbg06s20eeVGww7syuv0GM2pKG4yfsBoaNItkxP1FIVaAc5gy8HJ 4dKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=tB0OJAOtpN/nzb6lX+OIoslxWEEdk4L6wUPXrtA80WU=; b=WQfoS5nydpiQpYDLoy77Wb5MHkDfoGEQW/BBmUBHoUwNrxabYM0z/Cj5mqzu+rj+cu 7c3KuqJ8k7F9KwdI1Y5uV8NEpwR8yUt0a46RkZF+I/ks8GaPIhhKq/WoMT7jMLhVDJfx Ds/eySJv3UDScbeByqgMQdzZyeZnPwTWxCbb1aLyG6FlCZqP359l0tNr0NKY2FZIDENR ve2gHIhwGFTOG+WYqziPh5JjaNScW+AEQnHQGcNfwgapmOygdlMcySW/rTT+jM6uCeXW DGgHvCYynkP5I9MvpU5yO/GAa77O9KFIi/q/H18u0o8o+9N/PIAH91Gam/ZjxiiZuvoz Ro9g== X-Gm-Message-State: APjAAAVsThxLOmwFnvytiuN03RazbotTwQBYVWDKMsgPcFNKx/+sqJXH CU0loUwO+MfVloKEkTVfQip8fw== X-Google-Smtp-Source: APXvYqzDizQkc91Yu+vM2ljpA5s9hdjb3mVd0RapAiK7Sn7smt1BgxNHwwx7ddAMrv2RC6uxrlrd+w== X-Received: by 2002:a63:534d:: with SMTP id t13mr108832039pgl.89.1578360370108; Mon, 06 Jan 2020 17:26:10 -0800 (PST) Received: from hermes.lan (204-195-22-127.wavecable.com. [204.195.22.127]) by smtp.gmail.com with ESMTPSA id b4sm80843018pfd.18.2020.01.06.17.26.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 06 Jan 2020 17:26:09 -0800 (PST) Date: Mon, 6 Jan 2020 17:26:01 -0800 From: Stephen Hemminger To: Honnappa Nagarahalli Cc: Gavin Hu , Joyce Kong , "thomas@monjalon.net" , "david.marchand@redhat.com" , "mb@smartsharesystems.com" , "jerinj@marvell.com" , "bruce.richardson@intel.com" , "ravi1.kumar@amd.com" , "rmody@marvell.com" , "shshaikh@marvell.com" , "xuanziyang2@huawei.com" , "cloud.wangxiaoyun@huawei.com" , "zhouguoyang@huawei.com" , Phil Yang , nd , "dev@dpdk.org" Message-ID: <20200106172601.71750b85@hermes.lan> In-Reply-To: References: <1571125801-45773-1-git-send-email-joyce.kong@arm.com> <1576648808-24765-2-git-send-email-joyce.kong@arm.com> <20191221100752.04838f7a@hermes.lan> <20191223083644.4de8e184@hermes.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v6 1/6] lib/eal: implement the family of rte bit operation APIs 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, 7 Jan 2020 00:44:51 +0000 Honnappa Nagarahalli wrote: > > > > > > > > > > > > > > > > On Sat, 21 Dec 2019 16:07:23 +0000 Honnappa Nagarahalli > > > > > wrote: > > > > > > > > > > > Converting these into macros will help remove the size based > > > > > > duplication > > > of > > > > > APIs. I came up with the following macro: > > > > > > > > > > > > #define RTE_GET_BIT(nr, var, ret, memorder) \ ({ \ > > > > > > if (sizeof(var) == sizeof(uint32_t)) { \ > > > > > > uint32_t mask1 = 1U << (nr)%32; \ > > > > > > ret = __atomic_load_n(&var, (memorder)) & mask1;\ > > > > > > } \ > > > > > > else {\ > > > > > > uint64_t mask2 = 1UL << (nr)%64;\ > > > > > > ret = __atomic_load_n(&var, (memorder)) & mask2;\ > > > > > > } \ > > > > > > }) > > > > > > > > > > Macros are more error prone. Especially because this is in exposed > > > > > header > > > file > > > > That's another question I have. Why do we need to have these APIs in > > > > a > > > public header file? These will add to the ABI burden as well. These > > > APIs should be in a common-but-not-public header file. I am also not > > > sure how helpful these APIs are for applications as these APIs seem to > > > have considered requirements only from the PMDs. > > > > > > Why do we have to wrap every C atomic builtin? What value is there in that? > > > > The wrapping is aimed to reduce code duplication, on average 3 lines cut > > down to 1 line for a single core. > > Overall I am thinking this bitops APIs are targeted for use by PMDs only, > > applications can use C11 freely. > > The initial thought for the new APIs came from the idea of consolidating the > > scattered bit operations all over the PMDs. It is unwise to expanding to > > applications or libraries, as different memory orderings are required and > > complexity generate. > > > > If the use cases are limited to PMDs, a 'volatile' or a compiler barrier is > > sufficient therefore the number of APIs can be saved by half. > > http://inbox.dpdk.org/dev/VI1PR08MB53766C30B5CDA00FB9FCE9678F2E0 > > @VI1PR08MB5376.eurprd08.prod.outlook.com/ > > > > Any thoughts and comments are welcome! > I would prefer that the APIs/Macros just address PMD's requirements. These also should be kept private (through naming conventions?). Given that the current PMDs are not using C11, we can skip using C11 atomics in these APIs. Not in favor, just use existing Gcc/clang/icc atomics instead of creating unnecessary bloat wrappers.