From patchwork Wed Jun 28 12:00:18 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: 106524 Delivered-To: patch@linaro.org Received: by 10.140.101.44 with SMTP id t41csp932977qge; Wed, 28 Jun 2017 05:06:42 -0700 (PDT) X-Received: by 10.55.24.138 with SMTP id 10mr12726094qky.22.1498651602554; Wed, 28 Jun 2017 05:06:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1498651602; cv=none; d=google.com; s=arc-20160816; b=DhdUhXCtkRCRgCJq/ZwE8dmCMoJZVYbkCV8fV3YmcAyIMDDakZkRGM/OILrxxEDq37 r+r+8d56sRqJKxOQqZkDVJfWrv/9foJyyvXb69jznE2gS211fCkOtgxfK4/A6FDLrE1c kg9rk5K+7aDbEF5m3i0gNondyS5eAlOk3/aW9o2Ihs/mqTzaLJAaUt+0rCWLCDgftO09 y07VRKRFX75kAJL6s8Jz6dBMTiWKab+i5m6ZIFkklMCgaHgxJODBCrzXFmQ89dBRltne vFAGvvVb3JranRlPHgq4Hi/a8VblYboQNvvxyOPzqNeEEGxMFWhqjvqekMNCcxOJAMqr ocVA== 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=4fNUMTnOE4xpaMZI2vxcNz7KrrsUZbeWWytYYIMyR1k=; b=SfSf8CY15s0MydpJwzu+z6lBK2OW+qXN644jzijK0eeTeEq+WlX7zHL4W41E0ciaJX PTsMMvYUCPnuO6R2ixpnJGw+5901+yvju9EkwP7xtKmyGue29m4shC3rlSuhQnU0HsLD LBI6HbAUEQtnHADv0QDK5cOnjUzbg3nOUANfO7N//LsPpRH6cTcRjOGYy75Kntz+GGTK NtjGkmMu+7PUMl8eM1NVuT2P6WCa/0aA7qIq+4ZGfUE/eYOVNJp45xgF7ZOficL9woBQ efg7TLnCpB5FpXTSzwDClrqjDAW0y22Pdj1OnJg80hK6HAZzADWlZdQqY6UMvDuLlnsG 13Ew== 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 p41si1852055qta.19.2017.06.28.05.06.42; Wed, 28 Jun 2017 05:06:42 -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 3152460D6F; Wed, 28 Jun 2017 12:06:42 +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,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,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 CF8D960D88; Wed, 28 Jun 2017 12:01:55 +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 1D8D160C0B; Wed, 28 Jun 2017 12:01:23 +0000 (UTC) Received: from forward2o.cmail.yandex.net (forward2o.cmail.yandex.net [37.9.109.243]) by lists.linaro.org (Postfix) with ESMTPS id EEE886071A for ; Wed, 28 Jun 2017 12:00:54 +0000 (UTC) Received: from smtp2o.mail.yandex.net (smtp2o.mail.yandex.net [37.140.190.27]) by forward2o.cmail.yandex.net (Yandex) with ESMTP id 7CE39216DF for ; Wed, 28 Jun 2017 15:00:53 +0300 (MSK) Received: from smtp2o.mail.yandex.net (localhost.localdomain [127.0.0.1]) by smtp2o.mail.yandex.net (Yandex) with ESMTP id 31CEA5080F13 for ; Wed, 28 Jun 2017 15:00:52 +0300 (MSK) Received: by smtp2o.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id vsQvWKSvTY-0pj8aKLx; Wed, 28 Jun 2017 15:00:51 +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: Wed, 28 Jun 2017 15:00:18 +0300 Message-Id: <1498651220-13948-6-git-send-email-odpbot@yandex.ru> X-Mailer: git-send-email 1.9.1 In-Reply-To: <1498651220-13948-1-git-send-email-odpbot@yandex.ru> References: <1498651220-13948-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: c6a309f00f882fabe70fa535ebe8b765f6e9bd11 ** Merge commit sha: ab4e27ee16b8da05ab2d4d61c58f41235cfddbcf **/ 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