List patch comments

GET /api/patches/73411/comments/?format=api&order=-date
HTTP 200 OK
Allow: GET, HEAD, OPTIONS
Content-Type: application/json
Link: 
<https://patches.dpdk.org/api/patches/73411/comments/?format=api&order=-date&page=1>; rel="first",
<https://patches.dpdk.org/api/patches/73411/comments/?format=api&order=-date&page=1>; rel="last"
Vary: Accept
[ { "id": 115767, "web_url": "https://patches.dpdk.org/comment/115767/", "msgid": "<DB6PR0802MB221684B3C9377BEA2C4DC01298650@DB6PR0802MB2216.eurprd08.prod.outlook.com>", "list_archive_url": "https://inbox.dpdk.org/dev/DB6PR0802MB221684B3C9377BEA2C4DC01298650@DB6PR0802MB2216.eurprd08.prod.outlook.com", "date": "2020-07-10T23:47:55", "subject": "Re: [dpdk-dev] [PATCH v6 1/4] doc: add generic atomic deprecation\n section", "submitter": { "id": 1045, "url": "https://patches.dpdk.org/api/people/1045/?format=api", "name": "Honnappa Nagarahalli", "email": "honnappa.nagarahalli@arm.com" }, "content": "<snip>\n\n> Subject: Re: [dpdk-dev] [PATCH v6 1/4] doc: add generic atomic deprecation\n> section\n> \n> Interestingly, John, our doc maintainer is not Cc'ed.\n> I add him.\n> Please use --cc-cmd devtools/get-maintainer.sh I am expecting a review from\n> an x86 maintainer as well.\n> If no maintainer replies, ping them.\n> \n> 07/07/2020 11:50, Phil Yang:\n> > Add deprecating the generic rte_atomic_xx APIs to c11 atomic built-ins\n> > guide and examples.\n> [...]\n> > +Atomic Operations: Use C11 Atomic Built-ins\n> > +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n> > +\n> > +DPDK `generic rte_atomic\n> > +<https://github.com/DPDK/dpdk/blob/v20.02/lib/librte_eal/common/inclu\n> > +de/generic/rte_atomic.h>`_ operations are\n> \n> Why this github link on 20.02?\n> \n> Please try to keep lines small.\n> \n> > +implemented by `__sync built-ins\n> <https://gcc.gnu.org/onlinedocs/gcc/_005f_005fsync-Builtins.html>`_.\n> \n> Long links should be on their own line to avoid long lines.\n> \n> > +These __sync built-ins result in full barriers on aarch64, which are\n> > +unnecessary in many use cases. They can be replaced by `__atomic\n> > +built-ins <https://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-\n> Builtins.html>`_ that conform to the C11 memory model and provide finer\n> memory order control.\n> > +\n> > +So replacing the rte_atomic operations with __atomic built-ins might\n> > +improve performance for aarch64 machines. `More details\n> <https://www.dpdk.org/wp-\n> content/uploads/sites/35/2019/10/StateofC11Code.pdf>`_.\n> \n> \"More details.\"\n> Please make a sentence.\nThe full stop is after the link. But, I think we will remove this link as well.\n\n> \n> > +\n> > +Some typical optimization cases are listed below:\n> > +\n> > +Atomicity\n> > +^^^^^^^^^\n> > +\n> > +Some use cases require atomicity alone, the ordering of the memory\n> > +operations does not matter. For example the packets statistics in the\n> `vhost\n> <https://github.com/DPDK/dpdk/blob/v20.02/examples/vhost/main.c#L796>`\n> _ example application.\n> \n> Again github.\n> If you really want a web link, use code.dpdk.org or doc.dpdk.org/api\n> \n> But why giving code example at all?\n> \n> > +\n> > +It just updates the number of transmitted packets, no subsequent\n> > +logic depends on these counters. So the RELAXED memory ordering is\n> sufficient:\n> > +\n> > +.. code-block:: c\n> > +\n> > + static __rte_always_inline void\n> > + virtio_xmit(struct vhost_dev *dst_vdev, struct vhost_dev *src_vdev,\n> > + struct rte_mbuf *m)\n> > + {\n> > + ...\n> > + ...\n> > + if (enable_stats) {\n> > + __atomic_add_fetch(&dst_vdev->stats.rx_total_atomic, 1,\n> __ATOMIC_RELAXED);\n> > + __atomic_add_fetch(&dst_vdev->stats.rx_atomic, ret,\n> __ATOMIC_RELAXED);\n> > + ...\n> > + }\n> > + }\n> \n> I don't see how adding real code helps here.\n> Why not just mentioning __atomic_add_fetch and __ATOMIC_RELAXED?\n> \n> > +\n> > +One-way Barrier\n> > +^^^^^^^^^^^^^^^\n> > +\n> > +Some use cases allow for memory reordering in one way while requiring\n> > +memory ordering in the other direction.\n> > +\n> > +For example, the memory operations before the `lock\n> > +<https://github.com/DPDK/dpdk/blob/v20.02/lib/librte_eal/common/inclu\n> > +de/generic/rte_spinlock.h#L66>`_ can move to the critical section,\n> > +but the memory operations in the critical section cannot move above\n> > +the lock. In this case, the full memory barrier in the CAS operation\n> > +can be replaced to ACQUIRE. On the other hand, the memory operations\n> > +after the `unlock\n> <https://github.com/DPDK/dpdk/blob/v20.02/lib/librte_eal/common/include/\n> generic/rte_spinlock.h#L88>`_ can move to the critical section, but the\n> memory operations in the critical section cannot move below the unlock. So\n> the full barrier in the STORE operation can be replaced with RELEASE.\n> \n> Again github links instead of our doxygen.\n> \n> > +\n> > +Reader-Writer Concurrency\n> > +^^^^^^^^^^^^^^^^^^^^^^^^^\n> \n> No blank line here?\nWill fix\n\n> \n> > +Lock-free reader-writer concurrency is one of the common use cases in\n> DPDK.\n> > +\n> > +The payload or the data that the writer wants to communicate to the\n> > +reader, can be written with RELAXED memory order. However, the guard\n> > +variable should be written with RELEASE memory order. This ensures\n> > +that the store to guard variable is observable only after the store to\n> payload is observable.\n> > +Refer to `rte_hash insert\n> <https://github.com/DPDK/dpdk/blob/v20.02/lib/librte_hash/rte_cuckoo_has\n> h.c#L737>`_ for an example.\n> \n> Hum...\n> \n> > +\n> > +.. code-block:: c\n> > +\n> > + static inline int32_t\n> > + rte_hash_cuckoo_insert_mw(const struct rte_hash *h,\n> > + ...\n> > + int32_t *ret_val)\n> > + {\n> > + ...\n> > + ...\n> > +\n> > + /* Insert new entry if there is room in the primary\n> > + * bucket.\n> > + */\n> > + for (i = 0; i < RTE_HASH_BUCKET_ENTRIES; i++) {\n> > + /* Check if slot is available */\n> > + if (likely(prim_bkt->key_idx[i] == EMPTY_SLOT)) {\n> > + prim_bkt->sig_current[i] = sig;\n> > + /* Store to signature and key should not\n> > + * leak after the store to key_idx. i.e.\n> > + * key_idx is the guard variable for signature\n> > + * and key.\n> > + */\n> > + __atomic_store_n(&prim_bkt->key_idx[i],\n> > + new_idx,\n> > + __ATOMIC_RELEASE);\n> > + break;\n> > + }\n> > + }\n> > +\n> > + ...\n> > + }\n> > +\n> > +Correspondingly, on the reader side, the guard variable should be\n> > +read with ACQUIRE memory order. The payload or the data the writer\n> > +communicated, can be read with RELAXED memory order. This ensures\n> > +that, if the store to guard variable is observable, the store to payload is\n> also observable. Refer to `rte_hash lookup\n> <https://github.com/DPDK/dpdk/blob/v20.02/lib/librte_hash/rte_cuckoo_has\n> h.c#L1215>`_ for an example.\n> > +\n> > +.. code-block:: c\n> > +\n> > + static inline int32_t\n> > + search_one_bucket_lf(const struct rte_hash *h, const void *key,\n> uint16_t sig,\n> > + void **data, const struct rte_hash_bucket *bkt)\n> > + {\n> > + ...\n> > +\n> > + for (i = 0; i < RTE_HASH_BUCKET_ENTRIES; i++) {\n> > + ....\n> > + if (bkt->sig_current[i] == sig) {\n> > + key_idx = __atomic_load_n(&bkt->key_idx[i],\n> > + __ATOMIC_ACQUIRE);\n> > + if (key_idx != EMPTY_SLOT) {\n> > + k = (struct rte_hash_key *) ((char *)keys +\n> > + key_idx * h->key_entry_size);\n> > +\n> > + if (rte_hash_cmp_eq(key, k->key, h) == 0) {\n> > + if (data != NULL) {\n> > + *data = __atomic_load_n(&k->pdata,\n> > + __ATOMIC_ACQUIRE);\n> > + }\n> > +\n> > + /*\n> > + * Return index where key is stored,\n> > + * subtracting the first dummy index\n> > + */\n> > + return key_idx - 1;\n> > + }\n> > + ...\n> > + }\n> > +\n> \n> NACK for the big chunks of real code.\n> Please use words and avoid code.\n> \n> If you insist on keeping code in doc, I will make you responsible of updating\n> all the code we have already in the doc :)\nOk, understood, will re-spin.\n\n>", "headers": { "Return-Path": "<dev-bounces@dpdk.org>", "X-Original-To": "patchwork@inbox.dpdk.org", "Delivered-To": "patchwork@inbox.dpdk.org", "Received": [ "from dpdk.org (dpdk.org [92.243.14.124])\n\tby inbox.dpdk.org (Postfix) with ESMTP id 02C7CA0528;\n\tSat, 11 Jul 2020 01:48:07 +0200 (CEST)", "from [92.243.14.124] (localhost [127.0.0.1])\n\tby dpdk.org (Postfix) with ESMTP id C712A1DA22;\n\tSat, 11 Jul 2020 01:48:06 +0200 (CEST)", "from EUR05-VI1-obe.outbound.protection.outlook.com\n (mail-vi1eur05on2076.outbound.protection.outlook.com [40.107.21.76])\n by dpdk.org (Postfix) with ESMTP id 275BB1D8EF\n for <dev@dpdk.org>; Sat, 11 Jul 2020 01:48:04 +0200 (CEST)", "from AM5PR0601CA0069.eurprd06.prod.outlook.com (2603:10a6:206::34)\n by DBBPR08MB4853.eurprd08.prod.outlook.com (2603:10a6:10:d5::11) with\n Microsoft SMTP Server (version=TLS1_2,\n cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3174.21; Fri, 10 Jul\n 2020 23:48:02 +0000", "from AM5EUR03FT027.eop-EUR03.prod.protection.outlook.com\n (2603:10a6:206:0:cafe::f) by AM5PR0601CA0069.outlook.office365.com\n (2603:10a6:206::34) with Microsoft SMTP Server (version=TLS1_2,\n cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3174.21 via Frontend\n Transport; Fri, 10 Jul 2020 23:48:02 +0000", "from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by\n AM5EUR03FT027.mail.protection.outlook.com (10.152.16.138) with\n Microsoft SMTP\n Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id\n 15.20.3174.21 via Frontend Transport; Fri, 10 Jul 2020 23:48:02 +0000", "(\"Tessian outbound 1dc58800d5dd:v62\");\n Fri, 10 Jul 2020 23:48:01 +0000", "from ba567a206739.1\n by 64aa7808-outbound-1.mta.getcheckrecipient.com id\n 2FDCB403-BF92-4618-8099-E52A779E0D25.1;\n Fri, 10 Jul 2020 23:47:56 +0000", "from EUR04-DB3-obe.outbound.protection.outlook.com\n by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id\n ba567a206739.1\n (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384);\n Fri, 10 Jul 2020 23:47:56 +0000", "from DB6PR0802MB2216.eurprd08.prod.outlook.com (2603:10a6:4:85::9)\n by DB7PR08MB3131.eurprd08.prod.outlook.com (2603:10a6:5:1e::13) with\n Microsoft SMTP Server (version=TLS1_2,\n cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3174.21; Fri, 10 Jul\n 2020 23:47:55 +0000", "from DB6PR0802MB2216.eurprd08.prod.outlook.com\n ([fe80::9d1d:207b:e89d:199d]) by DB6PR0802MB2216.eurprd08.prod.outlook.com\n ([fe80::9d1d:207b:e89d:199d%10]) with mapi id 15.20.3174.024; Fri, 10 Jul\n 2020 23:47:55 +0000" ], "DKIM-Signature": [ "v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com;\n s=selector2-armh-onmicrosoft-com;\n h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;\n bh=8ZqpwAj0jsTnOZGsAD0SFMX6tTzj8BYyN2jj68RtehI=;\n b=K/dXo8QbT+YlV4HyFh5O1XYQHtGJbUOWVhNrqHHARUp23j5OKoo5y0VMEFW00uAYgVQ3DH1UIz937JTEEkhO7zwxGyrd5G9DkbCPMMFOOZemxBoxp0rUVjbyvQPJ5tMNZhP4xOWJ1o25yW8i2LcPhldFdUZI5AXgNzB4YiD2tLw=", "v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com;\n s=selector2-armh-onmicrosoft-com;\n h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;\n bh=8ZqpwAj0jsTnOZGsAD0SFMX6tTzj8BYyN2jj68RtehI=;\n b=K/dXo8QbT+YlV4HyFh5O1XYQHtGJbUOWVhNrqHHARUp23j5OKoo5y0VMEFW00uAYgVQ3DH1UIz937JTEEkhO7zwxGyrd5G9DkbCPMMFOOZemxBoxp0rUVjbyvQPJ5tMNZhP4xOWJ1o25yW8i2LcPhldFdUZI5AXgNzB4YiD2tLw=" ], "X-MS-Exchange-Authentication-Results": "spf=pass (sender IP is 63.35.35.123)\n smtp.mailfrom=arm.com; dpdk.org; dkim=pass (signature was verified)\n header.d=armh.onmicrosoft.com;dpdk.org; dmarc=bestguesspass action=none\n header.from=arm.com;", "Received-SPF": "Pass (protection.outlook.com: domain of arm.com designates\n 63.35.35.123 as permitted sender) receiver=protection.outlook.com;\n client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com;", "X-CR-MTA-TID": "64aa7808", "ARC-Seal": "i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;\n b=nNV9F5LlbsTA9GSq9gwY9HTc3jegG1csEY3rH5wpoRoylLqGChtSeK7QWwI6/2QGmFUUXwdmXXsdGRW6fKNhbBaKdEjPVBH12KJn9EHPB0ehjAnhsZXA6hKj7lWkskt6fqfK35AR3sQl6hVgZDGDcC4Nyic/vQVRHNmycHqFdPGJjMNkDRW9Pv1T9uAYBpuI9Cs4cLinxGmesiT4MzJnv/NJ8Oxfvd5GunK2ZFeMgXIpjdgLsvxC2btHeoQROs61SFH/lqoyOGsWmQ30BUog0exhuz8uY2DuMYMr28gy9qFmfdD+DCzIDnn3COT7n0OLGF8GcKKKlX1FBZ2RhjDDng==", "ARC-Message-Signature": "i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;\n s=arcselector9901;\n h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;\n bh=8ZqpwAj0jsTnOZGsAD0SFMX6tTzj8BYyN2jj68RtehI=;\n b=oEE2/FhBwvLNJAwFwiXMNOrMmRh+Pxd3rBEavNea8DC8Ujk8lzPKVHsELvZlvq4cfMLVojORrE9DcyrRPM7fm2EYqtdqPbUNqo4aYsVPI6a+vnQaHJENxvCVi42YpY4w3gPVSkQ/c7LMIwGaB0b8SbHE7I8EvRq8LV0gQpx1j3lfeudS73EZH8xSc6tghhH4GArW4qWShuoP0rrzc813v7wEAqjSeLUA3Ie03gqqfIqK4bp+R86YbIKz4D/Mc1lhzC00CyWJCAmm2HRhDjWDtvuusvROE6YJPQXce1kxJZ6v8jLfOQBMZSsr8JSrAFH+pNQe+rf6MTFdz2XjQpEvtQ==", "ARC-Authentication-Results": "i=1; mx.microsoft.com 1; spf=pass\n smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass\n header.d=arm.com; arc=none", "From": "Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>", "To": "\"thomas@monjalon.net\" <thomas@monjalon.net>, Phil Yang <Phil.Yang@arm.com>", "CC": "\"dev@dpdk.org\" <dev@dpdk.org>, \"david.marchand@redhat.com\"\n <david.marchand@redhat.com>, \"drc@linux.vnet.ibm.com\"\n <drc@linux.vnet.ibm.com>, \"jerinj@marvell.com\" <jerinj@marvell.com>,\n \"konstantin.ananyev@intel.com\" <konstantin.ananyev@intel.com>, Ola Liljedahl\n <Ola.Liljedahl@arm.com>, Ruifeng Wang <Ruifeng.Wang@arm.com>, nd\n <nd@arm.com>, \"john.mcnamara@intel.com\" <john.mcnamara@intel.com>,\n \"bruce.richardson@intel.com\" <bruce.richardson@intel.com>, Honnappa\n Nagarahalli <Honnappa.Nagarahalli@arm.com>, nd <nd@arm.com>", "Thread-Topic": "[dpdk-dev] [PATCH v6 1/4] doc: add generic atomic deprecation\n section", "Thread-Index": "AQHWVxSIhq5cz44f0Uahpu9qDTM52Q==", "Date": "Fri, 10 Jul 2020 23:47:55 +0000", "Message-ID": "\n <DB6PR0802MB221684B3C9377BEA2C4DC01298650@DB6PR0802MB2216.eurprd08.prod.outlook.com>", "References": "<1590483667-10318-1-git-send-email-phil.yang@arm.com>\n <1594115449-13750-1-git-send-email-phil.yang@arm.com>\n <1594115449-13750-2-git-send-email-phil.yang@arm.com>\n <1746729.2ERU3Mzd2g@thomas>", "In-Reply-To": "<1746729.2ERU3Mzd2g@thomas>", "Accept-Language": "en-US", "Content-Language": "en-US", "X-MS-Has-Attach": "", "X-MS-TNEF-Correlator": "", "x-ts-tracking-id": "b0fe359f-ddb5-4428-b3ea-b11606780f1e.0", "x-checkrecipientchecked": "true", "Authentication-Results-Original": "monjalon.net; dkim=none (message not signed)\n header.d=none; monjalon.net;\n dmarc=none action=none header.from=arm.com;", "x-originating-ip": "[70.112.90.121]", "x-ms-publictraffictype": "Email", "X-MS-Office365-Filtering-HT": "Tenant", "X-MS-Office365-Filtering-Correlation-Id": "6b81f016-437e-4500-6d90-08d8252baee0", "x-ms-traffictypediagnostic": "DB7PR08MB3131:|DBBPR08MB4853:", "x-ld-processed": "f34e5979-57d9-4aaa-ad4d-b122a662184d,ExtAddr", "x-ms-exchange-transport-forked": "True", "X-Microsoft-Antispam-PRVS": "\n <DBBPR08MB4853785E150EC68EFE06E16998650@DBBPR08MB4853.eurprd08.prod.outlook.com>", "x-checkrecipientrouted": "true", "nodisclaimer": "true", "x-ms-oob-tlc-oobclassifiers": "OLM:10000;OLM:10000;", "X-MS-Exchange-SenderADCheck": "1", "X-Microsoft-Antispam-Untrusted": "BCL:0;", "X-Microsoft-Antispam-Message-Info-Original": "\n FAY8RYP6jt6WFGVMAmBZIc4upOYJRURLhtA2/SeAox6t74wUjNB3XQEC8SOx1Wid8VyvcduBbET9AELdknNTPH7/7rhzTI5Q3xXXwuR9tzYNfxVmWrRbIp2Eue7xCZ+PEhgsBDwV08KStDHNRo4y6zgDdmNB4nfGRUNYZD7JJVruaybuhJ9Lca2aUwvHKEn8gijzZiKRaWUqRUZ2qLmmo1sw7J3iNfebIuR+PNrWALLkFGEfQrbmb4f93bNFR9He40/JjA/41wAg6k/DsKQZVzbp4tVJGlxi8LWlGbYeztvtUDr6f7r+uwhdgWy1nvTdSKMovdByzjp8fr3TIUNbXW72XnxWDR/Kbr4Gg2ne2bvS0eDxKBTXMOHPoBD556KskAaEK1DoC3Ye3u+HjUrBxH9zawXqbUxw3sRbILmtVYU/5+rNp2uVvWyLNUf1XB4H", "X-Forefront-Antispam-Report-Untrusted": "CIP:255.255.255.255; CTRY:; LANG:en;\n SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB6PR0802MB2216.eurprd08.prod.outlook.com;\n PTR:; CAT:NONE; SFTY:;\n SFS:(4636009)(39860400002)(376002)(136003)(366004)(346002)(396003)(110136005)(54906003)(86362001)(83380400001)(9686003)(6636002)(2906002)(316002)(5660300002)(8676002)(8936002)(478600001)(33656002)(55016002)(52536014)(7696005)(6506007)(4326008)(26005)(71200400001)(186003)(66556008)(66446008)(66946007)(66476007)(76116006)(64756008)(41533002);\n DIR:OUT; SFP:1101;", "x-ms-exchange-antispam-messagedata": "\n I2gwQIkz7awlrQJvMgi8QGSZ2uHTVSpdmLwtgODC52Ju0nbo/YjsdKiZFIaNpgplSaM7AEhyogMMtwbYgLmJHxfE0YJgDRw8owAyz/pyfw1PR0DXp0mkd4+m0Fc95YXpILzHiLXPiEfNFehX79sL0r8tzn+KxETBq9wbfpkytGgBv5c7lWuF8vLL4/0m3OEcdv1Ys9q84tW4NqQFgsXHB4Sw6c6UVt4hVrJ8X/0IdPEUtyv3cBxVmbgQoStvTsBNssHqExNPX9utKV14kEO4cqslX2xPKUpFCAX2UMPvhpIbvTu81RQ5kxqjvyeKZLW3nUv+QaZBSFtWZGbfubhMa1imjcDFCCBKhl4Cd5zqza6nQni7AbXb09PMOxC+cn6Uw+S1gPb+m/ICNoqlISGokRMfJ/UfGfCf7SbYgjHPvIl7FnLyk/7S8sOfY0GSmsSapnQ7qNIxaWdeaKE1905XD14ewB/iJlPxOTRllo8bMIS1hO9+H97F7KJvOgcBTiHH", "Content-Type": "text/plain; charset=\"us-ascii\"", "Content-Transfer-Encoding": "quoted-printable", "MIME-Version": "1.0", "X-MS-Exchange-Transport-CrossTenantHeadersStamped": [ "DB7PR08MB3131", "DBBPR08MB4853" ], "Original-Authentication-Results": "monjalon.net; dkim=none (message not signed)\n header.d=none; monjalon.net;\n dmarc=none action=none header.from=arm.com;", "X-EOPAttributedMessage": "0", "X-MS-Exchange-Transport-CrossTenantHeadersStripped": "\n AM5EUR03FT027.eop-EUR03.prod.protection.outlook.com", "X-Forefront-Antispam-Report": "CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:;\n IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com;\n PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFTY:;\n SFS:(4636009)(39860400002)(346002)(376002)(136003)(396003)(46966005)(336012)(70586007)(5660300002)(52536014)(70206006)(6636002)(47076004)(81166007)(26005)(186003)(478600001)(55016002)(9686003)(356005)(110136005)(83380400001)(6506007)(4326008)(82740400003)(7696005)(316002)(36906005)(86362001)(33656002)(82310400002)(54906003)(2906002)(8676002)(8936002)(41533002);\n DIR:OUT; SFP:1101;", "X-MS-Office365-Filtering-Correlation-Id-Prvs": "\n 3b669162-a190-48a8-f593-08d8252bab36", "X-Microsoft-Antispam": "BCL:0;", "X-Microsoft-Antispam-Message-Info": "\n Tgy+bbGsSGxlFIO0aMDILSX4nC0AQI7icjMzsfWg28P+ZZFi/2FfhegJB+7+ecijogDVI/Se5WV7HkMTOlHZzpvreNi2QTJc9wTr+PyaSqaSV1XITu+mwWZ2hgCrYSUhSnkfXHtrULqvec3A2ek4n97B1K4ety7UAA4BrnYKYXElFEDoFNIJCvtHs4oCR8JTWsdOI2ipHgRginWi6zcHuQt75DvzOX8pSyfe0DHuPyN6Xs/0+XZRve09GujP/q8u7pGnaMNfwGdc1WwgIb+ASL4yUcgpJN1ktaMObbzKJJEKDpiCZoojtrqMsCXYw7CtNoOM/BoqqcNxGY7Rf5KsyjvSOMcABaoJtD/eSQB/I1nge/VvMqZaEElfFDM4ehaCkg91sm27ftRZrtCSIgrWaI5ZStDhYySR5Vhax6Npl1NqAK2nywllPmjVDG6cGI3gHSJYvmtf3GjuR53PWm1kN9p+ifccCpNHnmNc2hlCjbzb5UKtZShiBA5j5DzPsXFJ", "X-OriginatorOrg": "arm.com", "X-MS-Exchange-CrossTenant-OriginalArrivalTime": "10 Jul 2020 23:48:02.0150 (UTC)", "X-MS-Exchange-CrossTenant-Network-Message-Id": "\n 6b81f016-437e-4500-6d90-08d8252baee0", "X-MS-Exchange-CrossTenant-Id": "f34e5979-57d9-4aaa-ad4d-b122a662184d", "X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp": "\n TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123];\n Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com]", "X-MS-Exchange-CrossTenant-AuthSource": "\n AM5EUR03FT027.eop-EUR03.prod.protection.outlook.com", "X-MS-Exchange-CrossTenant-AuthAs": "Anonymous", "X-MS-Exchange-CrossTenant-FromEntityHeader": "HybridOnPrem", "Subject": "Re: [dpdk-dev] [PATCH v6 1/4] doc: add generic atomic deprecation\n section", "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>,\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", "Sender": "\"dev\" <dev-bounces@dpdk.org>" }, "addressed": null }, { "id": 115735, "web_url": "https://patches.dpdk.org/comment/115735/", "msgid": "<1746729.2ERU3Mzd2g@thomas>", "list_archive_url": "https://inbox.dpdk.org/dev/1746729.2ERU3Mzd2g@thomas", "date": "2020-07-10T16:55:52", "subject": "Re: [dpdk-dev] [PATCH v6 1/4] doc: add generic atomic deprecation\n\tsection", "submitter": { "id": 685, "url": "https://patches.dpdk.org/api/people/685/?format=api", "name": "Thomas Monjalon", "email": "thomas@monjalon.net" }, "content": "Interestingly, John, our doc maintainer is not Cc'ed.\nI add him.\nPlease use --cc-cmd devtools/get-maintainer.sh\nI am expecting a review from an x86 maintainer as well.\nIf no maintainer replies, ping them.\n\n07/07/2020 11:50, Phil Yang:\n> Add deprecating the generic rte_atomic_xx APIs to c11 atomic built-ins\n> guide and examples.\n[...]\n> +Atomic Operations: Use C11 Atomic Built-ins\n> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n> +\n> +DPDK `generic rte_atomic <https://github.com/DPDK/dpdk/blob/v20.02/lib/librte_eal/common/include/generic/rte_atomic.h>`_ operations are\n\nWhy this github link on 20.02?\n\nPlease try to keep lines small.\n\n> +implemented by `__sync built-ins <https://gcc.gnu.org/onlinedocs/gcc/_005f_005fsync-Builtins.html>`_.\n\nLong links should be on their own line to avoid long lines.\n\n> +These __sync built-ins result in full barriers on aarch64, which are unnecessary\n> +in many use cases. They can be replaced by `__atomic built-ins <https://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html>`_ that\n> +conform to the C11 memory model and provide finer memory order control.\n> +\n> +So replacing the rte_atomic operations with __atomic built-ins might improve\n> +performance for aarch64 machines. `More details <https://www.dpdk.org/wp-content/uploads/sites/35/2019/10/StateofC11Code.pdf>`_.\n\n\"More details.\"\nPlease make a sentence.\n\n> +\n> +Some typical optimization cases are listed below:\n> +\n> +Atomicity\n> +^^^^^^^^^\n> +\n> +Some use cases require atomicity alone, the ordering of the memory operations\n> +does not matter. For example the packets statistics in the `vhost <https://github.com/DPDK/dpdk/blob/v20.02/examples/vhost/main.c#L796>`_ example application.\n\nAgain github.\nIf you really want a web link, use code.dpdk.org or doc.dpdk.org/api\n\nBut why giving code example at all?\n\n> +\n> +It just updates the number of transmitted packets, no subsequent logic depends\n> +on these counters. So the RELAXED memory ordering is sufficient:\n> +\n> +.. code-block:: c\n> +\n> + static __rte_always_inline void\n> + virtio_xmit(struct vhost_dev *dst_vdev, struct vhost_dev *src_vdev,\n> + struct rte_mbuf *m)\n> + {\n> + ...\n> + ...\n> + if (enable_stats) {\n> + __atomic_add_fetch(&dst_vdev->stats.rx_total_atomic, 1, __ATOMIC_RELAXED);\n> + __atomic_add_fetch(&dst_vdev->stats.rx_atomic, ret, __ATOMIC_RELAXED);\n> + ...\n> + }\n> + }\n\nI don't see how adding real code helps here.\nWhy not just mentioning __atomic_add_fetch and __ATOMIC_RELAXED?\n\n> +\n> +One-way Barrier\n> +^^^^^^^^^^^^^^^\n> +\n> +Some use cases allow for memory reordering in one way while requiring memory\n> +ordering in the other direction.\n> +\n> +For example, the memory operations before the `lock <https://github.com/DPDK/dpdk/blob/v20.02/lib/librte_eal/common/include/generic/rte_spinlock.h#L66>`_ can move to the\n> +critical section, but the memory operations in the critical section cannot move\n> +above the lock. In this case, the full memory barrier in the CAS operation can\n> +be replaced to ACQUIRE. On the other hand, the memory operations after the\n> +`unlock <https://github.com/DPDK/dpdk/blob/v20.02/lib/librte_eal/common/include/generic/rte_spinlock.h#L88>`_ can move to the critical section, but the memory operations in the\n> +critical section cannot move below the unlock. So the full barrier in the STORE\n> +operation can be replaced with RELEASE.\n\nAgain github links instead of our doxygen.\n\n> +\n> +Reader-Writer Concurrency\n> +^^^^^^^^^^^^^^^^^^^^^^^^^\n\nNo blank line here?\n\n> +Lock-free reader-writer concurrency is one of the common use cases in DPDK.\n> +\n> +The payload or the data that the writer wants to communicate to the reader,\n> +can be written with RELAXED memory order. However, the guard variable should\n> +be written with RELEASE memory order. This ensures that the store to guard\n> +variable is observable only after the store to payload is observable.\n> +Refer to `rte_hash insert <https://github.com/DPDK/dpdk/blob/v20.02/lib/librte_hash/rte_cuckoo_hash.c#L737>`_ for an example.\n\nHum...\n\n> +\n> +.. code-block:: c\n> +\n> + static inline int32_t\n> + rte_hash_cuckoo_insert_mw(const struct rte_hash *h,\n> + ...\n> + int32_t *ret_val)\n> + {\n> + ...\n> + ...\n> +\n> + /* Insert new entry if there is room in the primary\n> + * bucket.\n> + */\n> + for (i = 0; i < RTE_HASH_BUCKET_ENTRIES; i++) {\n> + /* Check if slot is available */\n> + if (likely(prim_bkt->key_idx[i] == EMPTY_SLOT)) {\n> + prim_bkt->sig_current[i] = sig;\n> + /* Store to signature and key should not\n> + * leak after the store to key_idx. i.e.\n> + * key_idx is the guard variable for signature\n> + * and key.\n> + */\n> + __atomic_store_n(&prim_bkt->key_idx[i],\n> + new_idx,\n> + __ATOMIC_RELEASE);\n> + break;\n> + }\n> + }\n> +\n> + ...\n> + }\n> +\n> +Correspondingly, on the reader side, the guard variable should be read\n> +with ACQUIRE memory order. The payload or the data the writer communicated,\n> +can be read with RELAXED memory order. This ensures that, if the store to\n> +guard variable is observable, the store to payload is also observable. Refer to `rte_hash lookup <https://github.com/DPDK/dpdk/blob/v20.02/lib/librte_hash/rte_cuckoo_hash.c#L1215>`_ for an example.\n> +\n> +.. code-block:: c\n> +\n> + static inline int32_t\n> + search_one_bucket_lf(const struct rte_hash *h, const void *key, uint16_t sig,\n> + void **data, const struct rte_hash_bucket *bkt)\n> + {\n> + ...\n> +\n> + for (i = 0; i < RTE_HASH_BUCKET_ENTRIES; i++) {\n> + ....\n> + if (bkt->sig_current[i] == sig) {\n> + key_idx = __atomic_load_n(&bkt->key_idx[i],\n> + __ATOMIC_ACQUIRE);\n> + if (key_idx != EMPTY_SLOT) {\n> + k = (struct rte_hash_key *) ((char *)keys +\n> + key_idx * h->key_entry_size);\n> +\n> + if (rte_hash_cmp_eq(key, k->key, h) == 0) {\n> + if (data != NULL) {\n> + *data = __atomic_load_n(&k->pdata,\n> + __ATOMIC_ACQUIRE);\n> + }\n> +\n> + /*\n> + * Return index where key is stored,\n> + * subtracting the first dummy index\n> + */\n> + return key_idx - 1;\n> + }\n> + ...\n> + }\n> +\n\nNACK for the big chunks of real code.\nPlease use words and avoid code.\n\nIf you insist on keeping code in doc, I will make you responsible\nof updating all the code we have already in the doc :)", "headers": { "Return-Path": "<dev-bounces@dpdk.org>", "X-Original-To": "patchwork@inbox.dpdk.org", "Delivered-To": "patchwork@inbox.dpdk.org", "Received": [ "from dpdk.org (dpdk.org [92.243.14.124])\n\tby inbox.dpdk.org (Postfix) with ESMTP id 44E5BA052A;\n\tFri, 10 Jul 2020 18:55:58 +0200 (CEST)", "from [92.243.14.124] (localhost [127.0.0.1])\n\tby dpdk.org (Postfix) with ESMTP id F37F91DB68;\n\tFri, 10 Jul 2020 18:55:56 +0200 (CEST)", "from new3-smtp.messagingengine.com (new3-smtp.messagingengine.com\n [66.111.4.229]) by dpdk.org (Postfix) with ESMTP id EC73C1DA5D\n for <dev@dpdk.org>; Fri, 10 Jul 2020 18:55:55 +0200 (CEST)", "from compute7.internal (compute7.nyi.internal [10.202.2.47])\n by mailnew.nyi.internal (Postfix) with ESMTP id 845435801E4;\n Fri, 10 Jul 2020 12:55:55 -0400 (EDT)", "from mailfrontend2 ([10.202.2.163])\n by compute7.internal (MEProxy); Fri, 10 Jul 2020 12:55:55 -0400", "from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184])\n by mail.messagingengine.com (Postfix) with ESMTPA id 7129A30653F1;\n Fri, 10 Jul 2020 12:55:53 -0400 (EDT)" ], "DKIM-Signature": [ "v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h=\n from:to:cc:subject:date:message-id:in-reply-to:references\n :mime-version:content-transfer-encoding:content-type; s=fm1; bh=\n sPkWdwH7HBU34x2B5KfcLEkMxN/HYWWh485ksK+Uais=; b=r3RzBIxqQLQPtewg\n D1j+UxwZInJIqS6VpvS/YsymKby3VODBThYa6/8Vci9ziBNbd5mzyY6AhSxx2PEl\n UuNlCO4Pl3mDPWMn9JllYproUjCnmcYRW2w/f+CsVjYsS2sgAOrQtZHY/GUNHi8M\n L5v1FLf/lZmyDDbF7dukMN6kYHwjrCZD7se+woiUL6SFXEVEFvvothvDFNDidIQG\n 1TTn4aX3p29DCgZ1st254WVnFd5FUdNSne32wbB9A1CLK70jO2xjDsZFAKTq+uKD\n iJVFq7PS1HRGcRk71v7OE2U4b5+kUS/XNXA4I1k9yjdP7lP2Ju+YbXJ0IYDTTgtI\n 8kQBcA==", "v=1; a=rsa-sha256; c=relaxed/relaxed; d=\n messagingengine.com; h=cc:content-transfer-encoding:content-type\n :date:from:in-reply-to:message-id:mime-version:references\n :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender\n :x-sasl-enc; s=fm3; bh=sPkWdwH7HBU34x2B5KfcLEkMxN/HYWWh485ksK+Ua\n is=; b=q4amxP4MxqHsqtqnSHZg4nJwLyDyQkBhBMHcKNOntq5AShFApFxWGQO/W\n cN3mh07cyxyOZrNhQsWeojGa6mACCYWlNkiEJXY6SxpBI9oSEgjpSxh22q/51EdN\n X+4NF/7LVJgGHNDNKsAeNXtaZpWRnvFdj9uVcxPN8EkG+iQNSO6HJ/06Tn1crpSc\n jAGVSVU1PtoO0BP7mII2mAk0VeAJVXQ8ncjqHOoB0cFixyFoNFWFE4RnGmCyrP/F\n vyyembDysVXBtrJ9ZbSnLdJLSeJdOwqUMRuugQeNBfvcxuKY/fCgw2EdRnQnAOZj\n HLpguLUnquqs2rf9Ng3fdycvm01cg==" ], "X-ME-Sender": "<xms:mp0IX3s7WnfJ94M9--ui9Hc6H5ZRM3Esi0QblycQT-pfPkuHm5WK7w>", "X-ME-Proxy-Cause": "\n gggruggvucftvghtrhhoucdtuddrgeduiedrvddugdduudduucetufdoteggodetrfdotf\n fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen\n uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne\n cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr\n shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg\n ftrfgrthhtvghrnhepvdffgeffhefgtedvuedvgeetuddvieduffevgeefvdfggeejveel\n geevjeduffdvnecuffhomhgrihhnpehgihhthhhusgdrtghomhdpghhnuhdrohhrghdpug\n hpughkrdhorhhgnecukfhppeejjedrudefgedrvddtfedrudekgeenucevlhhushhtvghr\n ufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhhomhgrshesmhhonhhjrg\n hlohhnrdhnvght", "X-ME-Proxy": "<xmx:mp0IX4fxNarWmmA0pJa_Xgsy_5NhJHW5U2YZ7kvswQBIUbArUgvE5g>\n <xmx:mp0IX6x4y6H1R6yQOkjd7M5iI8Mzp5jNdw1NvKosz2yVjNIEtKhD1w>\n <xmx:mp0IX2NVgF1uqjTDagSVHST41rz6N4eMtTdwuWj648mnBb2On49-HQ>\n <xmx:m50IXzTkORG4Jt9GH9ZP3qBaCsbahIJLYfzIyx0sPvRbgTBIvUZ2tg>", "From": "Thomas Monjalon <thomas@monjalon.net>", "To": "Phil Yang <phil.yang@arm.com>", "Cc": "dev@dpdk.org, david.marchand@redhat.com, drc@linux.vnet.ibm.com,\n Honnappa.Nagarahalli@arm.com, jerinj@marvell.com,\n konstantin.ananyev@intel.com,\n Ola.Liljedahl@arm.com, ruifeng.wang@arm.com, nd@arm.com,\n john.mcnamara@intel.com, bruce.richardson@intel.com", "Date": "Fri, 10 Jul 2020 18:55:52 +0200", "Message-ID": "<1746729.2ERU3Mzd2g@thomas>", "In-Reply-To": "<1594115449-13750-2-git-send-email-phil.yang@arm.com>", "References": "<1590483667-10318-1-git-send-email-phil.yang@arm.com>\n <1594115449-13750-1-git-send-email-phil.yang@arm.com>\n <1594115449-13750-2-git-send-email-phil.yang@arm.com>", "MIME-Version": "1.0", "Content-Transfer-Encoding": "7Bit", "Content-Type": "text/plain; charset=\"us-ascii\"", "Subject": "Re: [dpdk-dev] [PATCH v6 1/4] doc: add generic atomic deprecation\n\tsection", "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>,\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", "Sender": "\"dev\" <dev-bounces@dpdk.org>" }, "addressed": null } ]