Patch Comment Detail
get:
Show a patch comment.
patch:
Update a patch comment.
put:
Update a patch comment.
GET /api/patches/139675/comments/169665/?format=api
{ "id": 169665, "web_url": "http://patches.dpdk.org/comment/169665/", "msgid": "<c36f19cc-6c1c-4d14-8ba4-07a87ef5162a@lysator.liu.se>", "list_archive_url": "https://inbox.dpdk.org/dev/c36f19cc-6c1c-4d14-8ba4-07a87ef5162a@lysator.liu.se", "date": "2024-04-25T14:36:26", "subject": "Re: [RFC v2 5/6] eal: add atomic bit operations", "submitter": { "id": 906, "url": "http://patches.dpdk.org/api/people/906/?format=api", "name": "Mattias Rönnblom", "email": "hofors@lysator.liu.se" }, "content": "On 2024-04-25 12:25, Morten Brørup wrote:\n>> +#define rte_bit_atomic_test(addr, nr, memory_order)\t\t\t\\\n>> +\t_Generic((addr),\t\t\t\t\t\t\\\n>> +\t\t uint32_t *: __rte_bit_atomic_test32,\t\t\t\\\n>> +\t\t uint64_t *: __rte_bit_atomic_test64)(addr, nr, memory_order)\n> \n> I wonder if these should have RTE_ATOMIC qualifier:\n> \n> +\t\t RTE_ATOMIC(uint32_t) *: __rte_bit_atomic_test32,\t\t\t\\\n> +\t\t RTE_ATOMIC(uint64_t) *: __rte_bit_atomic_test64)(addr, nr, memory_order)\n> \n> \n>> +#define __RTE_GEN_BIT_ATOMIC_TEST(size)\t\t\t\t\t\\\n>> +\tstatic inline bool\t\t\t\t\t\t\\\n>> +\t__rte_bit_atomic_test ## size(const uint ## size ## _t *addr,\t\\\n> \n> I wonder if the \"addr\" parameter should have RTE_ATOMIC qualifier:\n> \n> +\t__rte_bit_atomic_test ## size(const RTE_ATOMIC(uint ## size ## _t) *addr,\t\\\n> \n> instead of casting into a_addr.\n> \n\nCheck the cover letter for the rationale for the cast.\n\nWhere I'm at now is that I think C11 _Atomic is rather poor design. The \nassumption that an object which allows for atomic access always should \nrequire all operations upon it to be atomic, regardless of where it is \nin its lifetime, and which thread is accessing it, does not hold, in the \ngeneral case.\n\nThe only reason for _Atomic being as it is, as far as I can see, is to \naccommodate for ISAs which does not have the appropriate atomic machine \ninstructions, and thus require a lock or some other data associated with \nthe actual user-data-carrying bits. Neither GCC nor DPDK supports any \nsuch ISAs, to my knowledge. I suspect neither never will. So the cast \nwill continue to work.\n\n>> +\t\t\t\t unsigned int nr, int memory_order) \\\n>> +\t{\t\t\t\t\t\t\t\t\\\n>> +\t\tRTE_ASSERT(nr < size);\t\t\t\t\t\\\n>> +\t\t\t\t\t\t\t\t\t\\\n>> +\t\tconst RTE_ATOMIC(uint ## size ## _t) *a_addr =\t\t\\\n>> +\t\t\t(const RTE_ATOMIC(uint ## size ## _t) *)addr;\t\\\n>> +\t\tuint ## size ## _t mask = (uint ## size ## _t)1 << nr;\t\\\n>> +\t\treturn rte_atomic_load_explicit(a_addr, memory_order) & mask; \\\n>> +\t}\n> \n> \n> Similar considerations regarding volatile qualifier for the \"once\" operations.\n>", "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])\n\tby inbox.dpdk.org (Postfix) with ESMTP id EBCCF43F05;\n\tThu, 25 Apr 2024 16:36:30 +0200 (CEST)", "from mails.dpdk.org (localhost [127.0.0.1])\n\tby mails.dpdk.org (Postfix) with ESMTP id B9652402EE;\n\tThu, 25 Apr 2024 16:36:30 +0200 (CEST)", "from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3])\n by mails.dpdk.org (Postfix) with ESMTP id C5FFD40284\n for <dev@dpdk.org>; Thu, 25 Apr 2024 16:36:29 +0200 (CEST)", "from mail.lysator.liu.se (localhost [127.0.0.1])\n by mail.lysator.liu.se (Postfix) with ESMTP id 2E838F88D\n for <dev@dpdk.org>; Thu, 25 Apr 2024 16:36:29 +0200 (CEST)", "by mail.lysator.liu.se (Postfix, from userid 1004)\n id 22BCEF88C; Thu, 25 Apr 2024 16:36:29 +0200 (CEST)", "from [192.168.1.59] (h-62-63-215-114.A163.priv.bahnhof.se\n [62.63.215.114])\n (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest\n SHA256)\n (No client certificate requested)\n by mail.lysator.liu.se (Postfix) with ESMTPSA id 33A77F88B;\n Thu, 25 Apr 2024 16:36:27 +0200 (CEST)" ], "X-Spam-Checker-Version": "SpamAssassin 4.0.0 (2022-12-13) on\n hermod.lysator.liu.se", "X-Spam-Level": "", "X-Spam-Status": "No, score=-1.3 required=5.0 tests=ALL_TRUSTED,AWL,\n T_SCC_BODY_TEXT_LINE autolearn=disabled version=4.0.0", "X-Spam-Score": "-1.3", "Message-ID": "<c36f19cc-6c1c-4d14-8ba4-07a87ef5162a@lysator.liu.se>", "Date": "Thu, 25 Apr 2024 16:36:26 +0200", "MIME-Version": "1.0", "User-Agent": "Mozilla Thunderbird", "Subject": "Re: [RFC v2 5/6] eal: add atomic bit operations", "To": "=?utf-8?q?Morten_Br=C3=B8rup?= <mb@smartsharesystems.com>, =?utf-8?q?Mat?=\n\t=?utf-8?q?tias_R=C3=B6nnblom?= <mattias.ronnblom@ericsson.com>, dev@dpdk.org", "Cc": "Heng Wang <heng.wang@ericsson.com>,\n Stephen Hemminger <stephen@networkplumber.org>,\n Tyler Retzlaff <roretzla@linux.microsoft.com>", "References": "<20240302135328.531940-2-mattias.ronnblom@ericsson.com>\n <20240425085853.97888-1-mattias.ronnblom@ericsson.com>\n <20240425085853.97888-6-mattias.ronnblom@ericsson.com>\n <98CBD80474FA8B44BF855DF32C47DC35E9F3E8@smartserver.smartshare.dk>", "Content-Language": "en-US", "From": "=?utf-8?q?Mattias_R=C3=B6nnblom?= <hofors@lysator.liu.se>", "In-Reply-To": "\n <98CBD80474FA8B44BF855DF32C47DC35E9F3E8@smartserver.smartshare.dk>", "Content-Type": "text/plain; charset=UTF-8; format=flowed", "Content-Transfer-Encoding": "8bit", "X-Virus-Scanned": "ClamAV using ClamSMTP", "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>,\n <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>,\n <mailto:dev-request@dpdk.org?subject=subscribe>", "Errors-To": "dev-bounces@dpdk.org" }, "addressed": null }