get:
Show a patch.

patch:
Update a patch.

put:
Update a patch.

GET /api/patches/66515/?format=api
HTTP 200 OK
Allow: GET, PUT, PATCH, HEAD, OPTIONS
Content-Type: application/json
Vary: Accept

{
    "id": 66515,
    "url": "http://patches.dpdk.org/api/patches/66515/?format=api",
    "web_url": "http://patches.dpdk.org/project/dpdk/patch/1583862551-2049-2-git-send-email-phil.yang@arm.com/",
    "project": {
        "id": 1,
        "url": "http://patches.dpdk.org/api/projects/1/?format=api",
        "name": "DPDK",
        "link_name": "dpdk",
        "list_id": "dev.dpdk.org",
        "list_email": "dev@dpdk.org",
        "web_url": "http://core.dpdk.org",
        "scm_url": "git://dpdk.org/dpdk",
        "webscm_url": "http://git.dpdk.org/dpdk",
        "list_archive_url": "https://inbox.dpdk.org/dev",
        "list_archive_url_format": "https://inbox.dpdk.org/dev/{}",
        "commit_url_format": ""
    },
    "msgid": "<1583862551-2049-2-git-send-email-phil.yang@arm.com>",
    "list_archive_url": "https://inbox.dpdk.org/dev/1583862551-2049-2-git-send-email-phil.yang@arm.com",
    "date": "2020-03-10T17:49:02",
    "name": "[01/10] doc: add generic atomic deprecation section",
    "commit_ref": null,
    "pull_url": null,
    "state": "superseded",
    "archived": true,
    "hash": "e5929026fc2ed85b6783711ce811bc2e60111b51",
    "submitter": {
        "id": 833,
        "url": "http://patches.dpdk.org/api/people/833/?format=api",
        "name": "Phil Yang",
        "email": "phil.yang@arm.com"
    },
    "delegate": null,
    "mbox": "http://patches.dpdk.org/project/dpdk/patch/1583862551-2049-2-git-send-email-phil.yang@arm.com/mbox/",
    "series": [
        {
            "id": 8875,
            "url": "http://patches.dpdk.org/api/series/8875/?format=api",
            "web_url": "http://patches.dpdk.org/project/dpdk/list/?series=8875",
            "date": "2020-03-10T17:49:01",
            "name": "generic rte atomic APIs deprecate proposal",
            "version": 1,
            "mbox": "http://patches.dpdk.org/series/8875/mbox/"
        }
    ],
    "comments": "http://patches.dpdk.org/api/patches/66515/comments/",
    "check": "fail",
    "checks": "http://patches.dpdk.org/api/patches/66515/checks/",
    "tags": {},
    "related": [],
    "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 414E9A0566;\n\tTue, 10 Mar 2020 18:50:03 +0100 (CET)",
            "from [92.243.14.124] (localhost [127.0.0.1])\n\tby dpdk.org (Postfix) with ESMTP id 5BF811C021;\n\tTue, 10 Mar 2020 18:49:59 +0100 (CET)",
            "from foss.arm.com (foss.arm.com [217.140.110.172])\n by dpdk.org (Postfix) with ESMTP id 578151C01E\n for <dev@dpdk.org>; Tue, 10 Mar 2020 18:49:58 +0100 (CET)",
            "from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14])\n by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id CDEAD1FB;\n Tue, 10 Mar 2020 10:49:57 -0700 (PDT)",
            "from phil-VirtualBox.arm.com (A010647.Arm.com [10.170.243.28])\n by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 413583F534;\n Tue, 10 Mar 2020 10:49:54 -0700 (PDT)"
        ],
        "From": "Phil Yang <phil.yang@arm.com>",
        "To": "thomas@monjalon.net, harry.van.haaren@intel.com,\n konstantin.ananyev@intel.com, stephen@networkplumber.org,\n maxime.coquelin@redhat.com, dev@dpdk.org",
        "Cc": "david.marchand@redhat.com, jerinj@marvell.com, hemant.agrawal@nxp.com,\n Honnappa.Nagarahalli@arm.com, gavin.hu@arm.com, ruifeng.wang@arm.com,\n joyce.kong@arm.com, nd@arm.com",
        "Date": "Wed, 11 Mar 2020 01:49:02 +0800",
        "Message-Id": "<1583862551-2049-2-git-send-email-phil.yang@arm.com>",
        "X-Mailer": "git-send-email 2.7.4",
        "In-Reply-To": "<1583862551-2049-1-git-send-email-phil.yang@arm.com>",
        "References": "<1583862551-2049-1-git-send-email-phil.yang@arm.com>",
        "Subject": "[dpdk-dev] [PATCH 01/10] doc: add generic atomic deprecation 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>"
    },
    "content": "Add deprecating the generic rte_atomic_xx APIs to c11 atomic built-ins\nguide and examples.\n\nSuggested-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>\nSigned-off-by: Phil Yang <phil.yang@arm.com>\nReviewed-by: Gavin Hu <gavin.hu@arm.com>\n---\n doc/guides/prog_guide/writing_efficient_code.rst | 60 +++++++++++++++++++++++-\n 1 file changed, 59 insertions(+), 1 deletion(-)",
    "diff": "diff --git a/doc/guides/prog_guide/writing_efficient_code.rst b/doc/guides/prog_guide/writing_efficient_code.rst\nindex 849f63e..b278bc6 100644\n--- a/doc/guides/prog_guide/writing_efficient_code.rst\n+++ b/doc/guides/prog_guide/writing_efficient_code.rst\n@@ -167,7 +167,13 @@ but with the added cost of lower throughput.\n Locks and Atomic Operations\n ---------------------------\n \n-Atomic operations imply a lock prefix before the instruction,\n+This section describes some key considerations when using locks and atomic\n+operations in the DPDK environment.\n+\n+Locks\n+~~~~~\n+\n+On x86, atomic operations imply a lock prefix before the instruction,\n causing the processor's LOCK# signal to be asserted during execution of the following instruction.\n This has a big impact on performance in a multicore environment.\n \n@@ -176,6 +182,58 @@ It can often be replaced by other solutions like per-lcore variables.\n Also, some locking techniques are more efficient than others.\n For instance, the Read-Copy-Update (RCU) algorithm can frequently replace simple rwlocks.\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+implemented by `__sync built-ins <https://gcc.gnu.org/onlinedocs/gcc/_005f_005fsync-Builtins.html>`_.\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+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+\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+\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+\n Coding Considerations\n ---------------------\n \n",
    "prefixes": [
        "01/10"
    ]
}