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 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 ; Mon, 23 Dec 2019 09:59:35 +0100 (CET) Received: by mail-il1-f193.google.com with SMTP id t17so13400084ilm.13 for ; 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> In-Reply-To: From: Jerin Jacob Date: Mon, 23 Dec 2019 14:29:18 +0530 Message-ID: To: Honnappa Nagarahalli Cc: Joyce Kong , "thomas@monjalon.net" , "stephen@networkplumber.org" , "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 , Gavin Hu , nd , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Sat, Dec 21, 2019 at 9:37 PM Honnappa Nagarahalli 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)