From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from dpdk.org (dpdk.org [92.243.14.124])
	by inbox.dpdk.org (Postfix) with ESMTP id 98866A0352;
	Mon, 23 Dec 2019 09:59:37 +0100 (CET)
Received: from [92.243.14.124] (localhost [127.0.0.1])
	by dpdk.org (Postfix) with ESMTP id 69801F72;
	Mon, 23 Dec 2019 09:59:37 +0100 (CET)
Received: from mail-il1-f193.google.com (mail-il1-f193.google.com
 [209.85.166.193]) by dpdk.org (Postfix) with ESMTP id 8C3E21F5
 for <dev@dpdk.org>; Mon, 23 Dec 2019 09:59:35 +0100 (CET)
Received: by mail-il1-f193.google.com with SMTP id t17so13400084ilm.13
 for <dev@dpdk.org>; Mon, 23 Dec 2019 00:59:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=u2NvnOB7DBI9OrSYOR59CuildmyXPU8MAVTK8AJK4Pk=;
 b=HqTjpslVGb+7xVnCnBbTclDAol3B9F0Pyt4w6CPJKeoANaKqSvzAp2+poJ9eHYpL/L
 02e2qjYUCd+aq79iNaHzUWnSkeMVq8DYteuK1079Jj2qhwN65IfnrnzLU0BWkxnXjczk
 PyKFDlRRAEVEONWuTOBZOOGNx6uPi4ya3poc537xa1ehlRyB8v3L/LYAPNtY6RYkYtZX
 iQODSl77CBylbv66W63EywVdROsQOLfe/2sKnIf8/aRvuwzbuRA2gh1WcE39WViKs1lM
 5vwdVcVpb513VVYOrW2dYca71OacnLomJf+8ygU4BRnbCpz+mFTsnS/ah3bR0Yyo5vHw
 jkNA==
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=u2NvnOB7DBI9OrSYOR59CuildmyXPU8MAVTK8AJK4Pk=;
 b=FvHrWS4w1RsfPOlK2r3qmE+gIbId39seeP/byKPAt8ci6VofWmvjfzWvc3+ONC3tUK
 3ejNADB3re/dpXhQVfsQHdIVpucpALmJY6psetlEWBb/TK0zooYKiFkSwgXoz7oLEPUm
 tBzIOzCil/MpdSZyx2f1Yien1zFvEEDNy85mWHg3H2ch6w5RFbIoqi7bMZR+UO//B7dI
 5qPydQFh0DOpWBOMUTM5JQ8x2k9MoR09t0nwg+OiOjyU+QvRFyzuKFUvdG+2+lJXEV34
 uoNM14QWP3zZORHDFsz0m7BmRhXhf25w8D8a8/yf5699TkWXY7/wGywM6c4XUkTqPENu
 cW0w==
X-Gm-Message-State: APjAAAX4HYwwIfk5LndQNJL1JC1pG9NN59PkP3GFwk+J4xbVEEF6KvHe
 8kXF38U84wvd0L4ukEDIegAkU0Yz4hNfIQFCXIA=
X-Google-Smtp-Source: APXvYqwH9T/I/JXPdZ3L4YuDpHJeAeJpRGq8y5NQ9z4To2XKkRuuEclS5hPiTfmWxnYQJeu5jnjs3mS3BydNiomV9eA=
X-Received: by 2002:a92:1906:: with SMTP id 6mr25204825ilz.130.1577091574836; 
 Mon, 23 Dec 2019 00:59:34 -0800 (PST)
MIME-Version: 1.0
References: <1571125801-45773-1-git-send-email-joyce.kong@arm.com>
 <1576648808-24765-2-git-send-email-joyce.kong@arm.com>
 <VE1PR08MB514950694BD1532A840ABA9B982D0@VE1PR08MB5149.eurprd08.prod.outlook.com>
 <VE1PR08MB5149B57BCC162BF4317EFB4D982C0@VE1PR08MB5149.eurprd08.prod.outlook.com>
In-Reply-To: <VE1PR08MB5149B57BCC162BF4317EFB4D982C0@VE1PR08MB5149.eurprd08.prod.outlook.com>
From: Jerin Jacob <jerinjacobk@gmail.com>
Date: Mon, 23 Dec 2019 14:29:18 +0530
Message-ID: <CALBAE1N0M24dFM4a0kxcyzth4bHeh8+e=y6OR_=pO8tTv4iEng@mail.gmail.com>
To: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>
Cc: Joyce Kong <Joyce.Kong@arm.com>,
 "thomas@monjalon.net" <thomas@monjalon.net>, 
 "stephen@networkplumber.org" <stephen@networkplumber.org>, 
 "david.marchand@redhat.com" <david.marchand@redhat.com>, 
 "mb@smartsharesystems.com" <mb@smartsharesystems.com>,
 "jerinj@marvell.com" <jerinj@marvell.com>, 
 "bruce.richardson@intel.com" <bruce.richardson@intel.com>,
 "ravi1.kumar@amd.com" <ravi1.kumar@amd.com>, 
 "rmody@marvell.com" <rmody@marvell.com>,
 "shshaikh@marvell.com" <shshaikh@marvell.com>, 
 "xuanziyang2@huawei.com" <xuanziyang2@huawei.com>, 
 "cloud.wangxiaoyun@huawei.com" <cloud.wangxiaoyun@huawei.com>, 
 "zhouguoyang@huawei.com" <zhouguoyang@huawei.com>,
 Phil Yang <Phil.Yang@arm.com>, Gavin Hu <Gavin.Hu@arm.com>, 
 nd <nd@arm.com>, "dev@dpdk.org" <dev@dpdk.org>
Content-Type: text/plain; charset="UTF-8"
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 <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>

On Sat, Dec 21, 2019 at 9:37 PM Honnappa Nagarahalli
<Honnappa.Nagarahalli@arm.com> wrote:

> > > +__rte_experimental
> > > +static inline uint32_t
> > > +rte_get_bit32_relaxed(unsigned int nr, uint32_t *addr) {
> > Why not pass the memory order as a parameter? It would reduce the number
> > of API calls by half.
> I think these APIs should be modelled according to C11 __atomic_xxx APIs. Otherwise, the programmers have to understand another interface. It will also help reduce the number of APIs.
> 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;\
>     } \
> })
>
> The '%' is required to avoid a compiler warning/error. But the '%' operation will get removed by the compiler since 'nr' is a constant.
> IMO, the macro itself is not complex and should not be a pain for debugging.
>
> Currently, we have 20 APIs in this patch (possibly more coming in the future and creating an explosion with memory order/size combinations). The above macro will reduce this to 5 macros without further explosion in number of combinations.
>
> Any thoughts? What do others think?

# I think, the most common use case for register manipulation is
getting/setting of "fields"(set of consecutive bits). IMO, Linux
kernel bit manipulation APIs makes more sense.
At least have implementation similar to FIELD_GET() and FIELD_SET().
https://github.com/torvalds/linux/blob/master/include/linux/bitfield.h

# FIELD_GET will be superset API. A single bit can get through width = 1

# I think, it good to two versions of Macro/API. RTE_FIELD_GET(without
atomics) and RTE_FIELD_GET_ATOMIC(with C11 atomics)