From patchwork Thu Jun 29 00:00:03 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Github ODP bot X-Patchwork-Id: 106588 Delivered-To: patch@linaro.org Received: by 10.140.101.44 with SMTP id t41csp490659qge; Wed, 28 Jun 2017 17:04:09 -0700 (PDT) X-Received: by 10.55.40.140 with SMTP id o12mr15321340qko.50.1498694649486; Wed, 28 Jun 2017 17:04:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1498694649; cv=none; d=google.com; s=arc-20160816; b=YBL4SvaPKe7TjZhpso2TFDhlsEcm280e7bK4SOZUumR/YSUa45cwIhygl2aDEgJDlg 4DGQX7x1n7tFCMCkjn0POoDIMT7ofturuxp//BTAQBvwa+/XaupgNWfotd4iQ6CCUye+ XqbL104pqRUAH4FxIdf0GbELil94+74WR7PrVq++Qi/x/EgOy2krviaW20iUmFcfg7UJ ymViMXJeJVkLbHbtUXngHa0vbgG9fhjHqtRF8Cy8Cak1Tlz2vjhQvZc2CsBp0fzirgEl Dfj+O199+DiszCiPoNOU5gmi4CLSQKpy+AQ7t6PGw3/0ZjovqmjQbhgZsJcEies+HYFZ AwbQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=sender:errors-to:list-subscribe:list-help:list-post:list-archive :list-unsubscribe:list-id:precedence:subject:github-pr-num :references:in-reply-to:message-id:date:to:from:delivered-to :arc-authentication-results; bh=82cGzB8B/BtQDsMuTbDQ6iqE5qweSi+IXQd3k5hv6Dk=; b=EkpS99qCQLhUqo1Fr9y9dGwO2QLDe+0ErgGhjrC02bVtCJdVE/eLc2U444wGFiO4XZ mO/pSgUHlJVpu4LXIUS6UR5uEelZAoFmcxwa2RNCZuG4FIs8by/AKL/lljmsJH2b1NW1 QbkQY2I+efOIFjJDM9jbyPUVTsdOr/nsnaIVm6WM80kGyX7H1cPVuRI2WjxV6XzB2DEl ciVuPowHHnGMcKAxZ2v+ltkPc7DTMnf/OAK0V6OGdFPYnuLonkAhGArFsYAQBCcQa+HL HJXxs8a5UsKsJZzH5IswXYcabs1ceP1/K+WGtuStVHwYcPucyIk8Z91itDDGs0KS1y3Z aOlg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of lng-odp-bounces@lists.linaro.org designates 54.225.227.206 as permitted sender) smtp.mailfrom=lng-odp-bounces@lists.linaro.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=yandex.ru Return-Path: Received: from lists.linaro.org (lists.linaro.org. [54.225.227.206]) by mx.google.com with ESMTP id g68si3338700qkc.188.2017.06.28.17.04.09; Wed, 28 Jun 2017 17:04:09 -0700 (PDT) Received-SPF: pass (google.com: domain of lng-odp-bounces@lists.linaro.org designates 54.225.227.206 as permitted sender) client-ip=54.225.227.206; Authentication-Results: mx.google.com; spf=pass (google.com: domain of lng-odp-bounces@lists.linaro.org designates 54.225.227.206 as permitted sender) smtp.mailfrom=lng-odp-bounces@lists.linaro.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=yandex.ru Received: by lists.linaro.org (Postfix, from userid 109) id 2DC6D61056; Thu, 29 Jun 2017 00:04:09 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on ip-10-142-244-252 X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,FREEMAIL_FROM, RCVD_IN_DNSWL_LOW,URIBL_BLOCKED autolearn=disabled version=3.4.0 Received: from [127.0.0.1] (localhost [127.0.0.1]) by lists.linaro.org (Postfix) with ESMTP id 0656B60DCC; Thu, 29 Jun 2017 00:01:54 +0000 (UTC) X-Original-To: lng-odp@lists.linaro.org Delivered-To: lng-odp@lists.linaro.org Received: by lists.linaro.org (Postfix, from userid 109) id 2446561056; Thu, 29 Jun 2017 00:01:44 +0000 (UTC) Received: from forward4p.cmail.yandex.net (forward4p.cmail.yandex.net [77.88.31.19]) by lists.linaro.org (Postfix) with ESMTPS id 11C9360C10 for ; Thu, 29 Jun 2017 00:00:41 +0000 (UTC) Received: from smtp4p.mail.yandex.net (smtp4p.mail.yandex.net [95.108.252.166]) by forward4p.cmail.yandex.net (Yandex) with ESMTP id 7A66720E9A for ; Thu, 29 Jun 2017 03:00:38 +0300 (MSK) Received: from smtp4p.mail.yandex.net (localhost.localdomain [127.0.0.1]) by smtp4p.mail.yandex.net (Yandex) with ESMTP id 4F4C465010F1 for ; Thu, 29 Jun 2017 03:00:37 +0300 (MSK) Received: by smtp4p.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id lqJUGDUALt-0bgavHeK; Thu, 29 Jun 2017 03:00:37 +0300 (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (Client certificate not present) X-Yandex-Suid-Status: 1 0 From: Github ODP bot To: lng-odp@lists.linaro.org Date: Thu, 29 Jun 2017 03:00:03 +0300 Message-Id: <1498694405-16518-6-git-send-email-odpbot@yandex.ru> X-Mailer: git-send-email 1.9.1 In-Reply-To: <1498694405-16518-1-git-send-email-odpbot@yandex.ru> References: <1498694405-16518-1-git-send-email-odpbot@yandex.ru> Github-pr-num: 61 Subject: [lng-odp] [PATCH v1 5/7] doc: drop images full paths, we have imagesdir properly set X-BeenThere: lng-odp@lists.linaro.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: "The OpenDataPlane \(ODP\) List" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: lng-odp-bounces@lists.linaro.org Sender: "lng-odp" From: Dmitry Eremin-Solenikov Signed-off-by: Dmitry Eremin-Solenikov --- /** Email created from pull request 61 (lumag:docs-fix) ** https://github.com/Linaro/odp/pull/61 ** Patch: https://github.com/Linaro/odp/pull/61.patch ** Base sha: 9b78da8e2373ab0530cfbbd72b2229059b57ddf1 ** Merge commit sha: beb74541650c77e8682b58cfcdb8424e62c5b053 **/ doc/users-guide/users-guide-pktio.adoc | 14 +++++++------- doc/users-guide/users-guide-tm.adoc | 4 ++-- 2 files changed, 9 insertions(+), 9 deletions(-) diff --git a/doc/users-guide/users-guide-pktio.adoc b/doc/users-guide/users-guide-pktio.adoc index 9ca91f76..80a58d2f 100644 --- a/doc/users-guide/users-guide-pktio.adoc +++ b/doc/users-guide/users-guide-pktio.adoc @@ -10,7 +10,7 @@ PktIO objects are manipulated through various state transitions via `odp_pktio_xxx()` API calls as shown below: .ODP PktIO Finite State Machine -image::../images/pktio_fsm.svg[align="center"] +image::pktio_fsm.svg[align="center"] PktIOs begin in the *Unallocated* state. From here a call `odp_pktio_open()` is used to create an *odp_pktio_t* handle that is used in all subsequent calls @@ -159,7 +159,7 @@ maximum flexibility to the data plane application writer. The processing of DIRECT input is shown below: .PktIO DIRECT Mode Receive Processing -image::../images/pktin_direct_recv.svg[align="center"] +image::pktin_direct_recv.svg[align="center"] In DIRECT mode, received packets are stored in one or more special PktIO queues of type *odp_pktin_queue_t* and are retrieved by threads calling the @@ -376,7 +376,7 @@ to structure itself. A PktIO operating in DIRECT mode performs TX processing as shown here: .PktIO DIRECT Mode Transmit Processing -image::../images/pktout_direct_send.svg[align="center"] +image::pktout_direct_send.svg[align="center"] Direct TX processing operates similarly to Direct RX processing. Following open, the `odp_pktout_queue_config()` API is used to create and configure @@ -501,7 +501,7 @@ QUEUE mode uses standard ODP event queues to service packets. The processing for QUEUE input processing is shown below: .PktIO QUEUE Mode Receive Processing -image::../images/pktin_queue_recv.svg[align="center"] +image::pktin_queue_recv.svg[align="center"] In QUEUE mode, received packets are stored in one or more standard ODP queues. The difference is that these queues are not created directly by the @@ -550,7 +550,7 @@ with the PktIO. Transmit processing for PktIOs operating in QUEUE mode is shown below: .PktIO QUEUE Mode Transmit Processing -image::../images/pktout_queue_send.svg[align="center] +image::pktout_queue_send.svg[align="center] For TX processing QUEUE mode behaves similar to DIRECT mode except that output queues are regular ODP event queues that receive packets via @@ -578,7 +578,7 @@ input queues created by a subsequent `odp_pktin_queue_config()` call are to be used as input to the *ODP Scheduler*. .PktIO SCHED Mode Receive Processing -image::../images/pktin_sched_recv.svg[align="center'] +image::pktin_sched_recv.svg[align="center'] For basic use, SCHED mode simply associates the PktIO input event queues created by `odp_pktin_queue_config()` with the scheduler. Hashing may still be @@ -593,7 +593,7 @@ In its fullest form, PktIOs operating in SCHED mode use the *ODP Classifier* to permit fine-grained flow separation on *Class of Service (CoS)* boundaries. .PktIO SCHED Mode Receive Processing with Classification -image::../images/pktin_sched_cls.svg[align="center"] +image::pktin_sched_cls.svg[align="center"] In this mode of operation, the hash function of `odp_pktin_queue_config()` is typically not used. Instead, the event queues created by this call, diff --git a/doc/users-guide/users-guide-tm.adoc b/doc/users-guide/users-guide-tm.adoc index 36fa9ece..25129733 100644 --- a/doc/users-guide/users-guide-tm.adoc +++ b/doc/users-guide/users-guide-tm.adoc @@ -162,7 +162,7 @@ into one fan-in of a subsequent tm_node or egresss object - forming a proper tree. .Hierarchical Scheduling -image::../images/tm_hierarchy.svg[align="center"] +image::tm_hierarchy.svg[align="center"] Multi-level/hierarchical scheduling adds both great control and significant complexity. Logically, despite the implication of the tm_node tree diagrams, @@ -183,7 +183,7 @@ some very sophisticated behaviours. Each tm_node can contain a set of scheduler shaper and a WRED component - or a subset of these. .Traffic Manager Node -image::../images/tm_node.svg[align="center"] +image::tm_node.svg[align="center"] In its full generality an tm_node consists of a set of "fan-in" connections to preceding tm_queues or tm_nodes. The fan-in for a single tm_node can range