get:
Show a patch.

patch:
Update a patch.

put:
Update a patch.

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

{
    "id": 12020,
    "url": "https://patches.dpdk.org/api/patches/12020/?format=api",
    "web_url": "https://patches.dpdk.org/project/dpdk/patch/1460411692-27107-1-git-send-email-thomas.monjalon@6wind.com/",
    "project": {
        "id": 1,
        "url": "https://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": "<1460411692-27107-1-git-send-email-thomas.monjalon@6wind.com>",
    "list_archive_url": "https://inbox.dpdk.org/dev/1460411692-27107-1-git-send-email-thomas.monjalon@6wind.com",
    "date": "2016-04-11T21:54:52",
    "name": "[dpdk-dev] doc: fix references in guides",
    "commit_ref": null,
    "pull_url": null,
    "state": "accepted",
    "archived": true,
    "hash": "6f900d26f67134f410d1dabd23c9e223e713a8f4",
    "submitter": {
        "id": 1,
        "url": "https://patches.dpdk.org/api/people/1/?format=api",
        "name": "Thomas Monjalon",
        "email": "thomas.monjalon@6wind.com"
    },
    "delegate": null,
    "mbox": "https://patches.dpdk.org/project/dpdk/patch/1460411692-27107-1-git-send-email-thomas.monjalon@6wind.com/mbox/",
    "series": [],
    "comments": "https://patches.dpdk.org/api/patches/12020/comments/",
    "check": "pending",
    "checks": "https://patches.dpdk.org/api/patches/12020/checks/",
    "tags": {},
    "related": [],
    "headers": {
        "Return-Path": "<dev-bounces@dpdk.org>",
        "X-Original-To": "patchwork@dpdk.org",
        "Delivered-To": "patchwork@dpdk.org",
        "Received": [
            "from [92.243.14.124] (localhost [IPv6:::1])\n\tby dpdk.org (Postfix) with ESMTP id 713442BEF;\n\tMon, 11 Apr 2016 23:55:00 +0200 (CEST)",
            "from mail-wm0-f51.google.com (mail-wm0-f51.google.com\n\t[74.125.82.51]) by dpdk.org (Postfix) with ESMTP id A347A2946\n\tfor <dev@dpdk.org>; Mon, 11 Apr 2016 23:54:59 +0200 (CEST)",
            "by mail-wm0-f51.google.com with SMTP id n3so3718322wmn.0\n\tfor <dev@dpdk.org>; Mon, 11 Apr 2016 14:54:59 -0700 (PDT)",
            "from XPS13.localdomain (245.111.75.86.rev.sfr.net. [86.75.111.245])\n\tby smtp.gmail.com with ESMTPSA id\n\tu16sm19535045wmd.5.2016.04.11.14.54.57\n\t(version=TLSv1/SSLv3 cipher=OTHER);\n\tMon, 11 Apr 2016 14:54:58 -0700 (PDT)"
        ],
        "DKIM-Signature": "v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=6wind-com.20150623.gappssmtp.com; s=20150623;\n\th=from:to:cc:subject:date:message-id;\n\tbh=5RQZ8oSvkalHqNtzKGs0tvPWBqsibxI6masOrDuPGJo=;\n\tb=U485Yhf2YrRerP2+/Tt2YYr7tnXtH7ebslQCgxNW2kUiKRTDEM3e7osPibMYEFTkWC\n\tkE8a5RnoXaF8VOJS4WFeSud2yh7cSeAwQqNij3/EwJDZAKM6gz65AjPWJLli5icNEDhU\n\tGa7xxuTjDasTkka20Oebhe2GnjNLJwg5FZ9JQc2iKrJcQXXbJleNETK425Y6xPLHy1e7\n\t7ibVN38jfRx754ovo1/s8AlW3xAndOMx1sqzlSpuN4zhC9i1/jshIpYULvMXvI7XLB6l\n\tXnEvLIeS1P8nd04jD9F577apIzHKsJSD6yZi2NIM9U1/BMPtk937Z6b5MMBfDjQaC9tE\n\t1pQw==",
        "X-Google-DKIM-Signature": "v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20130820;\n\th=x-gm-message-state:from:to:cc:subject:date:message-id;\n\tbh=5RQZ8oSvkalHqNtzKGs0tvPWBqsibxI6masOrDuPGJo=;\n\tb=W9PRvCmqhdMr1UdYYdyKeKhh4ro0AScr9a6uIdSzE1hbCGMkGqXRWEehA9ssdCSmMR\n\tzmIkkxLk0DuitZyHNduhlOqhbPaOC5fzTaCPITNAJpmhgsxqZMRs88MSgOAU5YtWN1Uv\n\tzeW6jH1Xlteeg3lWw89/b8OWhuBycwjygJtfsz+gqRRngQTmzcPGZ+CLA30xCxDw9luC\n\tvR4caqCidBAzh3vsw4UCRgqTqqa6IyDW1J5PjWn/UnAac0NGU8o2nCg/Edn2wrSHkvF3\n\tVcTaLKAIGprF6WOJvuqC06ZpoiVKfo28WX5aowxIvIwdRlF6FJoh1g91AQnB3AI7WZ3B\n\tE/UA==",
        "X-Gm-Message-State": "AD7BkJJBE1NlbDTj0A0oOtdzRXu95ssx+NJAXBl4ksSlSertSicdAs/9zCaPWp9JNL7pGjI8",
        "X-Received": "by 10.28.128.88 with SMTP id b85mr21838064wmd.46.1460411699433; \n\tMon, 11 Apr 2016 14:54:59 -0700 (PDT)",
        "From": "Thomas Monjalon <thomas.monjalon@6wind.com>",
        "To": "john.mcnamara@intel.com",
        "Cc": "dev@dpdk.org",
        "Date": "Mon, 11 Apr 2016 23:54:52 +0200",
        "Message-Id": "<1460411692-27107-1-git-send-email-thomas.monjalon@6wind.com>",
        "X-Mailer": "git-send-email 2.7.0",
        "Subject": "[dpdk-dev] [PATCH] doc: fix references in guides",
        "X-BeenThere": "dev@dpdk.org",
        "X-Mailman-Version": "2.1.15",
        "Precedence": "list",
        "List-Id": "patches and discussions about DPDK <dev.dpdk.org>",
        "List-Unsubscribe": "<http://dpdk.org/ml/options/dev>,\n\t<mailto:dev-request@dpdk.org?subject=unsubscribe>",
        "List-Archive": "<http://dpdk.org/ml/archives/dev/>",
        "List-Post": "<mailto:dev@dpdk.org>",
        "List-Help": "<mailto:dev-request@dpdk.org?subject=help>",
        "List-Subscribe": "<http://dpdk.org/ml/listinfo/dev>,\n\t<mailto:dev-request@dpdk.org?subject=subscribe>",
        "Errors-To": "dev-bounces@dpdk.org",
        "Sender": "\"dev\" <dev-bounces@dpdk.org>"
    },
    "content": "Replace some hard-coded section numbers by dynamic links.\n\nSigned-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>\n---\n doc/guides/nics/virtio.rst                           | 2 +-\n doc/guides/prog_guide/ip_fragment_reassembly_lib.rst | 2 +-\n doc/guides/prog_guide/kernel_nic_interface.rst       | 2 ++\n doc/guides/prog_guide/lpm6_lib.rst                   | 2 +-\n doc/guides/prog_guide/lpm_lib.rst                    | 2 ++\n doc/guides/prog_guide/mbuf_lib.rst                   | 2 ++\n doc/guides/prog_guide/mempool_lib.rst                | 2 ++\n doc/guides/prog_guide/multi_proc_support.rst         | 2 +-\n doc/guides/prog_guide/qos_framework.rst              | 8 ++++----\n doc/guides/prog_guide/writing_efficient_code.rst     | 2 +-\n doc/guides/sample_app_ug/l2_forward_job_stats.rst    | 5 +++--\n doc/guides/sample_app_ug/multi_process.rst           | 2 +-\n 12 files changed, 21 insertions(+), 12 deletions(-)",
    "diff": "diff --git a/doc/guides/nics/virtio.rst b/doc/guides/nics/virtio.rst\nindex 200a8be..06ca433 100644\n--- a/doc/guides/nics/virtio.rst\n+++ b/doc/guides/nics/virtio.rst\n@@ -140,7 +140,7 @@ Host2VM communication example\n     For each physical port, kni also creates a kernel thread that retrieves packets from the kni receive queue,\n     place them onto kni's raw socket's queue and wake up the vhost kernel thread to exchange packets with the virtio virt queue.\n \n-    For more details about kni, please refer to Chapter 24 \"Kernel NIC Interface\".\n+    For more details about kni, please refer to :ref:`kni`.\n \n #.  Enable the kni raw socket functionality for the specified physical NIC port,\n     get the generated file descriptor and set it in the qemu command line parameter.\ndiff --git a/doc/guides/prog_guide/ip_fragment_reassembly_lib.rst b/doc/guides/prog_guide/ip_fragment_reassembly_lib.rst\nindex 1d3d4ac..43168f0 100644\n--- a/doc/guides/prog_guide/ip_fragment_reassembly_lib.rst\n+++ b/doc/guides/prog_guide/ip_fragment_reassembly_lib.rst\n@@ -54,7 +54,7 @@ Finally 'direct' and 'indirect' mbufs for each fragment are linked together via\n \n The caller has an ability to explicitly specify which mempools should be used to allocate 'direct' and 'indirect' mbufs from.\n \n-For more information about direct and indirect mbufs, refer to the *DPDK Programmers guide 7.7 Direct and Indirect Buffers.*\n+For more information about direct and indirect mbufs, refer to :ref:`direct_indirect_buffer`.\n \n Packet reassembly\n -----------------\ndiff --git a/doc/guides/prog_guide/kernel_nic_interface.rst b/doc/guides/prog_guide/kernel_nic_interface.rst\nindex 0d91476..fac1960 100644\n--- a/doc/guides/prog_guide/kernel_nic_interface.rst\n+++ b/doc/guides/prog_guide/kernel_nic_interface.rst\n@@ -28,6 +28,8 @@\n     (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE\n     OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.\n \n+.. _kni:\n+\n Kernel NIC Interface\n ====================\n \ndiff --git a/doc/guides/prog_guide/lpm6_lib.rst b/doc/guides/prog_guide/lpm6_lib.rst\nindex 87f5066..0aea5c5 100644\n--- a/doc/guides/prog_guide/lpm6_lib.rst\n+++ b/doc/guides/prog_guide/lpm6_lib.rst\n@@ -75,7 +75,7 @@ The main methods exported for the LPM component are:\n Implementation Details\n ~~~~~~~~~~~~~~~~~~~~~~\n \n-This is a modification of the algorithm used for IPv4 (see Section 19.2 \"Implementation Details\").\n+This is a modification of the algorithm used for IPv4 (see :ref:`lpm4_details`).\n In this case, instead of using two levels, one with a tbl24 and a second with a tbl8, 14 levels are used.\n \n The implementation can be seen as a multi-bit trie where the *stride*\ndiff --git a/doc/guides/prog_guide/lpm_lib.rst b/doc/guides/prog_guide/lpm_lib.rst\nindex c33e469..8b5ff99 100644\n--- a/doc/guides/prog_guide/lpm_lib.rst\n+++ b/doc/guides/prog_guide/lpm_lib.rst\n@@ -62,6 +62,8 @@ The main methods exported by the LPM component are:\n     the algorithm picks the rule with the highest depth as the best match rule,\n     which means that the rule has the highest number of most significant bits matching between the input key and the rule key.\n \n+.. _lpm4_details:\n+\n Implementation Details\n ----------------------\n \ndiff --git a/doc/guides/prog_guide/mbuf_lib.rst b/doc/guides/prog_guide/mbuf_lib.rst\nindex 32a041e..8e61682 100644\n--- a/doc/guides/prog_guide/mbuf_lib.rst\n+++ b/doc/guides/prog_guide/mbuf_lib.rst\n@@ -235,6 +235,8 @@ The list of flags and their precise meaning is described in the mbuf API\n documentation (rte_mbuf.h). Also refer to the testpmd source code\n (specifically the csumonly.c file) for details.\n \n+.. _direct_indirect_buffer:\n+\n Direct and Indirect Buffers\n ---------------------------\n \ndiff --git a/doc/guides/prog_guide/mempool_lib.rst b/doc/guides/prog_guide/mempool_lib.rst\nindex f0ca06f..5fae79a 100644\n--- a/doc/guides/prog_guide/mempool_lib.rst\n+++ b/doc/guides/prog_guide/mempool_lib.rst\n@@ -98,6 +98,8 @@ no padding is required between objects (except for objects whose size are n x 3\n \n When creating a new pool, the user can specify to use this feature or not.\n \n+.. _mempool_local_cache:\n+\n Local Cache\n -----------\n \ndiff --git a/doc/guides/prog_guide/multi_proc_support.rst b/doc/guides/prog_guide/multi_proc_support.rst\nindex 1680d6b..badd102 100644\n--- a/doc/guides/prog_guide/multi_proc_support.rst\n+++ b/doc/guides/prog_guide/multi_proc_support.rst\n@@ -80,7 +80,7 @@ and point to the same objects, in both processes.\n \n .. note::\n \n-    Refer to Section 23.3 \"Multi-process Limitations\" for details of\n+    Refer to `Multi-process Limitations`_ for details of\n     how Linux kernel Address-Space Layout Randomization (ASLR) can affect memory sharing.\n \n .. _figure_multi_process_memory:\ndiff --git a/doc/guides/prog_guide/qos_framework.rst b/doc/guides/prog_guide/qos_framework.rst\nindex c4e390c..f3f60b8 100644\n--- a/doc/guides/prog_guide/qos_framework.rst\n+++ b/doc/guides/prog_guide/qos_framework.rst\n@@ -147,7 +147,7 @@ these packets are later on removed and handed over to the NIC TX with the packet\n \n The hierarchical scheduler is optimized for a large number of packet queues.\n When only a small number of queues are needed, message passing queues should be used instead of this block.\n-See Section 26.2.5 \"Worst Case Scenarios for Performance\" for a more detailed discussion.\n+See `Worst Case Scenarios for Performance`_ for a more detailed discussion.\n \n Scheduling Hierarchy\n ~~~~~~~~~~~~~~~~~~~~\n@@ -712,7 +712,7 @@ where, r = port line rate (in bytes per second).\n    |   |                         |     of the grinders), update the credits for the pipe and its subport.      |\n    |   |                         |                                                                             |\n    |   |                         | The current implementation is using option 3.  According to Section         |\n-   |   |                         | 26.2.4.4 \"Dequeue State Machine\", the pipe and subport credits are          |\n+   |   |                         | `Dequeue State Machine`_, the pipe and subport credits are                  |\n    |   |                         | updated every time a pipe is selected by the dequeue process before the     |\n    |   |                         | pipe and subport credits are actually used.                                 |\n    |   |                         |                                                                             |\n@@ -783,7 +783,7 @@ as described in :numref:`table_qos_10` and :numref:`table_qos_11`.\n    | 1 | tc_time               | Bytes | Time of the next update (upper limit refill) for the 4 TCs of the     |\n    |   |                       |       | current subport / pipe.                                               |\n    |   |                       |       |                                                                       |\n-   |   |                       |       | See  Section 26.2.4.5.1, \"Internal Time Reference\" for the            |\n+   |   |                       |       | See  Section `Internal Time Reference`_ for the                       |\n    |   |                       |       | explanation of why the time is maintained in byte units.              |\n    |   |                       |       |                                                                       |\n    +---+-----------------------+-------+-----------------------------------------------------------------------+\n@@ -1334,7 +1334,7 @@ Where:\n \n The time reference is in units of bytes,\n where a byte signifies the time duration required by the physical interface to send out a byte on the transmission medium\n-(see Section 26.2.4.5.1 \"Internal Time Reference\").\n+(see Section `Internal Time Reference`_).\n The parameter s is defined in the dropper module as a constant with the value: s=2^22.\n This corresponds to the time required by every leaf node in a hierarchy with 64K leaf nodes\n to transmit one 64-byte packet onto the wire and represents the worst case scenario.\ndiff --git a/doc/guides/prog_guide/writing_efficient_code.rst b/doc/guides/prog_guide/writing_efficient_code.rst\nindex 613db88..78d2afa 100644\n--- a/doc/guides/prog_guide/writing_efficient_code.rst\n+++ b/doc/guides/prog_guide/writing_efficient_code.rst\n@@ -113,7 +113,7 @@ it is advised to use the DPDK ring API, which provides a lockless ring implement\n \n The ring supports bulk and burst access,\n meaning that it is possible to read several elements from the ring with only one costly atomic operation\n-(see Chapter 5 \"Ring Library\").\n+(see :doc:`ring_lib`).\n Performance is greatly improved when using bulk access operations.\n \n The code algorithm that dequeues messages may be something similar to the following:\ndiff --git a/doc/guides/sample_app_ug/l2_forward_job_stats.rst b/doc/guides/sample_app_ug/l2_forward_job_stats.rst\nindex acf6273..03d9977 100644\n--- a/doc/guides/sample_app_ug/l2_forward_job_stats.rst\n+++ b/doc/guides/sample_app_ug/l2_forward_job_stats.rst\n@@ -154,7 +154,8 @@ Command Line Arguments\n ~~~~~~~~~~~~~~~~~~~~~~\n \n The L2 Forwarding sample application takes specific parameters,\n-in addition to Environment Abstraction Layer (EAL) arguments (see Section 9.3).\n+in addition to Environment Abstraction Layer (EAL) arguments\n+(see `Running the Application`_).\n The preferred way to parse parameters is to use the getopt() function,\n since it is part of a well-defined and portable library.\n \n@@ -344,7 +345,7 @@ The list of queues that must be polled for a given lcore is stored in a private\n Values of struct lcore_queue_conf:\n \n *   n_rx_port and rx_port_list[] are used in the main packet processing loop\n-    (see Section 9.4.6 \"Receive, Process and Transmit Packets\" later in this chapter).\n+    (see Section `Receive, Process and Transmit Packets`_ later in this chapter).\n \n *   rx_timers and flush_timer are used to ensure forced TX on low packet rate.\n \ndiff --git a/doc/guides/sample_app_ug/multi_process.rst b/doc/guides/sample_app_ug/multi_process.rst\nindex ffe7ee6..3571490 100644\n--- a/doc/guides/sample_app_ug/multi_process.rst\n+++ b/doc/guides/sample_app_ug/multi_process.rst\n@@ -495,7 +495,7 @@ For threads/processes not created in that way, either pinned to a core or not, t\n rte_lcore_id() function will not work in the correct way.\n However, sometimes these threads/processes still need the unique ID mechanism to do easy access on structures or resources.\n For example, the DPDK mempool library provides a local cache mechanism\n-(refer to *DPDK Programmer's Guide* , Section 6.4, \"Local Cache\")\n+(refer to :ref:`mempool_local_cache`)\n for fast element allocation and freeing.\n If using a non-unique ID or a fake one,\n a race condition occurs if two or more threads/ processes with the same core ID try to use the local cache.\n",
    "prefixes": [
        "dpdk-dev"
    ]
}