From patchwork Thu Jun 29 11:00:10 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: 106639 Delivered-To: patch@linaro.org Received: by 10.182.135.102 with SMTP id pr6csp4561744obb; Thu, 29 Jun 2017 04:06:44 -0700 (PDT) X-Received: by 10.55.99.85 with SMTP id x82mr19375083qkb.62.1498734404315; Thu, 29 Jun 2017 04:06:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1498734404; cv=none; d=google.com; s=arc-20160816; b=G469HmnlgCKYxgRbSZJqh9VCKDWCzoY1AKHjDY8wle4L91c1oItr6qoLC4FhOccxz8 juyiOg/BvvuUjqf76zB6U6fihNv7Mr6kYV0Muf7Uju0/Y+jaQPm4+9KBLswzcDoPNSGR eylCpn4yfuwAWoQgBGiGvgILQY15vOPAGivFXI3SNYwhGYZHfujI09R48rYrhbDiJ3J2 euamCsZCbqXJmXEB7cvpJBEAZAN1QYzJWBUri1P6/5b9shy4fXOXiKdqRobGq8KklLU+ jmPLPyfnLPs8+kEfsH9NTUY6OxvW9/ovHieMgVd0D+seq1wIN7AgG0uEPqSv9eXx3pEx m7nQ== 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=ralFludoc81PdaH8ZnHLojVZlnyKTcZYvfNBLBLEMKE=; b=q15YzCcLYZ5Omla1dAn6IniEe6A+FMCNcQdcX1cQOMPWukKL/ygRg9m58R3XomstVB FJ47wMs67p50cuUVGTtOK3FaQ9fKNHHeYaY3Ei04JQdX2Ps8U1dQE/gIECYQAYfvYRVo 5vh4U9Cd38xQTXI3w9J0+z2T6tRqS6QWMjGb/503AVMeD49ue02GFmEEZanAIwKHda0t CEh9uobRI1/jXPVlkyANo0iVe0QwicuZvGRLkjx/I6TD/o528UoQc0zcq9czw+NWTzig LF3cP7VkbgxF0LgOrtBVcnUNptUuEENcqAjXI6Pb9tSYQ+fnc2jlEmgvgjEtZvdNlWZc Fb3w== 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 q24si4615362qtf.256.2017.06.29.04.06.44; Thu, 29 Jun 2017 04:06:44 -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 EB1D260DB2; Thu, 29 Jun 2017 11:06:43 +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 7BA7F62AE8; Thu, 29 Jun 2017 11:02:02 +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 5703660EC3; Thu, 29 Jun 2017 11:01:53 +0000 (UTC) Received: from forward2j.cmail.yandex.net (forward2j.cmail.yandex.net [5.255.227.20]) by lists.linaro.org (Postfix) with ESMTPS id A4814611F4 for ; Thu, 29 Jun 2017 11:00:50 +0000 (UTC) Received: from smtp3o.mail.yandex.net (smtp3o.mail.yandex.net [IPv6:2a02:6b8:0:1a2d::27]) by forward2j.cmail.yandex.net (Yandex) with ESMTP id 28A3C21B92 for ; Thu, 29 Jun 2017 14:00:49 +0300 (MSK) Received: from smtp3o.mail.yandex.net (localhost.localdomain [127.0.0.1]) by smtp3o.mail.yandex.net (Yandex) with ESMTP id DA2152940E90 for ; Thu, 29 Jun 2017 14:00:47 +0300 (MSK) Received: by smtp3o.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id F0tMw2a6CH-0kL8T4dT; Thu, 29 Jun 2017 14:00:46 +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 14:00:10 +0300 Message-Id: <1498734013-20982-6-git-send-email-odpbot@yandex.ru> X-Mailer: git-send-email 1.9.1 In-Reply-To: <1498734013-20982-1-git-send-email-odpbot@yandex.ru> References: <1498734013-20982-1-git-send-email-odpbot@yandex.ru> Github-pr-num: 61 Subject: [lng-odp] [PATCH v2 5/8] 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: f6c89347fdd7243f9ed80e2c0356345f034696a9 **/ 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