From patchwork Fri May 13 15:01:26 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Bill Fischofer X-Patchwork-Id: 67789 Delivered-To: patch@linaro.org Received: by 10.140.92.199 with SMTP id b65csp314205qge; Fri, 13 May 2016 08:02:42 -0700 (PDT) X-Received: by 10.55.212.139 with SMTP id s11mr16477748qks.179.1463151762487; Fri, 13 May 2016 08:02:42 -0700 (PDT) Return-Path: Received: from lists.linaro.org (lists.linaro.org. [54.225.227.206]) by mx.google.com with ESMTP id w21si6479302qkb.113.2016.05.13.08.02.42; Fri, 13 May 2016 08:02: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=pass (p=NONE dis=NONE) header.from=linaro.org Received: by lists.linaro.org (Postfix, from userid 109) id 2309061650; Fri, 13 May 2016 15:02: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, 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 2DAA061657; Fri, 13 May 2016 15: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 32EA56160F; Fri, 13 May 2016 15:01:42 +0000 (UTC) Received: from mail-oi0-f53.google.com (mail-oi0-f53.google.com [209.85.218.53]) by lists.linaro.org (Postfix) with ESMTPS id AEB5561651 for ; Fri, 13 May 2016 15:01:32 +0000 (UTC) Received: by mail-oi0-f53.google.com with SMTP id x201so174629519oif.3 for ; Fri, 13 May 2016 08:01:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=9HIcmRRzHzlvHZ203ECDecdNMo7pm3sIba7w3BxeXsk=; b=VmmmS/zgMmPZQxrGCJqTZIGNMRLB7I1nLKXRCtsDFwqr7mhFKIubjcei7662uPorBR 2DoIoe89OEERvHUhE+5/wXxozIMWK4XslWG3cK8SH1kWH0dF6qlx+4P3vmJ3heweFSg6 a8UpVmOIR5blcZDHWMpJvwAgTladndeZNw7i9hCtbDpB2pT1XED7xEFzk4U/i+CNzouJ CU3OlRJb3aB3dJoTzvnYYH+q62tcGzVNdnvwM4JOF1ana4HDQjbD2PhDG4w7UoTp135v M3b/IBOzIjWoo5C0PMQiops44J4iR5/Il7H9/54jNkiGXGLyJubFKVz30j1T2+adzoQb vJww== X-Gm-Message-State: AOPr4FXpM90wnT2B3ztVB280L/hXTe9U1f7vffXX2xOvtZuU8u2Gejl8nd9aPHQ6vrRzq0Wkupo= X-Received: by 10.202.66.135 with SMTP id p129mr9240955oia.153.1463151692000; Fri, 13 May 2016 08:01:32 -0700 (PDT) Received: from localhost.localdomain (cpe-66-68-129-43.austin.res.rr.com. [66.68.129.43]) by smtp.gmail.com with ESMTPSA id h9sm5439523otb.17.2016.05.13.08.01.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 13 May 2016 08:01:31 -0700 (PDT) From: Bill Fischofer To: lng-odp@lists.linaro.org Date: Fri, 13 May 2016 10:01:26 -0500 Message-Id: <1463151686-12230-2-git-send-email-bill.fischofer@linaro.org> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1463151686-12230-1-git-send-email-bill.fischofer@linaro.org> References: <1463151686-12230-1-git-send-email-bill.fischofer@linaro.org> X-Topics: timers patch Subject: [lng-odp] [PATCHv6 2/2] doc: userguide: add timer and timeout event section to user guide 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: , MIME-Version: 1.0 Errors-To: lng-odp-bounces@lists.linaro.org Sender: "lng-odp" Signed-off-by: Ivan Khoronzhuk Signed-off-by: Bill Fischofer Signed-off-by: Christophe Milard --- doc/users-guide/Makefile.am | 1 + doc/users-guide/users-guide-timer.adoc | 144 +++++++++++++++++++++++++++++++++ doc/users-guide/users-guide.adoc | 2 + 3 files changed, 147 insertions(+) create mode 100644 doc/users-guide/users-guide-timer.adoc diff --git a/doc/users-guide/Makefile.am b/doc/users-guide/Makefile.am index 2e1195e..5903392 100644 --- a/doc/users-guide/Makefile.am +++ b/doc/users-guide/Makefile.am @@ -4,6 +4,7 @@ SRC = $(top_srcdir)/doc/users-guide/users-guide.adoc \ $(top_srcdir)/doc/users-guide/users-guide-cls.adoc \ $(top_srcdir)/doc/users-guide/users-guide-packet.adoc \ $(top_srcdir)/doc/users-guide/users-guide-pktio.adoc \ + $(top_srcdir)/doc/users-guide/users-guide-timer.adoc \ $(top_srcdir)/doc/users-guide/users-guide-tm.adoc TARGET = users-guide.html IMAGES = $(top_srcdir)/doc/images/overview.svg \ diff --git a/doc/users-guide/users-guide-timer.adoc b/doc/users-guide/users-guide-timer.adoc new file mode 100644 index 0000000..9cd30de --- /dev/null +++ b/doc/users-guide/users-guide-timer.adoc @@ -0,0 +1,144 @@ +== Timers and Timeout Events +The ODP Timer APIs offer a set of functions that permit applications to react +to the passage of time, and are designed to reflect the underlying hardware +timing features found in various platforms that support ODP implementations. + +Timers are drawn from specialized pools called _timer pools_ that have their +own abstract type (`odp_timer_pool_t`). Each timer pool is a logically +independent time source with its own _resolution_ measured in nanoseconds (ns) +and a maximum number of timers that it can support. Applications can have many +timers active at the same time and can set them to use either relative or +absolute time. Associated with each timer is a queue that is to receive events +when this timer expires. This queue is created by a separate +`odp_queue_create()` call that is passed as a parameter to `odp_timer_alloc()`. + +Timeouts are specialized events of type `odp_timeout_t` that are used to +represent the expiration of timers. Timeouts are drawn from pools of type +`ODP_POOL_TIMEOUT` that are created by the standard `odp_pool_create()` API. +Timeout events are associated with timers when those timers are _set_ and are +enqueued to their timer's associated queue whenever a set timer expires. So the +effect of timer expiration is a timeout event being added to a queue and +delivered via normal ODP event scheduling. + +The following diagrams show the life cycle of timers and timeout events. +Transitions in these finite state machines are marked by the event +triggering them. Events marked in green are common to both state machines, +_i.e.,_ trigger both state machines. + +.ODP Timers lifecycle State Diagram +image::timer_fsm.svg[align="center"] + +.ODP Timeout event lifecyle State Diagram +image::timeout_fsm.svg[align="center"] + +Reminder: +On a `timer expire` event, the related timeout event is enqueued to the timer +related queue. + +Timers measure time in _ticks_ rather than nanoseconds because each timer pool +may have its own time source and associated conversion ratios. It is thus more +efficient to manipulate time in these native tick values. As a result time +measured in nanoseconds must be converted between timer-pool specific tick +values via the conversion functions `odp_timer_ns_to_tick()` and +`odp_timer_tick_to_ns()` as needed. Both of these functions take a timer pool +as an input parameter to enable the pool-specific conversion ratios to be +used. + +Associated with each timer pool is a free running tick counter that can be +sampled at any time via the `odp_timer_current_tick()` API. Timers can be set +to an absolute future tick value via `odp_timer_set_abs()` or to a future tick +value relative to the current tick via `odp_timer_set_rel()`. Implementations +may impose minimum and maximum future values supported by a given timer pool +and timer set operations will fail if the requested value is outside of the +supported range. + +Before a set timer expires, it can be canceled via the `odp_timer_cancel()` +API. A successful cancel has the same effect as if the timer were never set. +An attempted cancel will fail if the timer is not set or if it has already +expired. + +=== Timer Pool Management +To facilitate implementation of the ODP timer APIs, an additional timer API is +provided. During initialization, applications are expected to create the timer +pools they need and then call `odp_timer_pool_start()`. ODP implementations +may or may not fail further attempts to create timer pools after this API is +called. For best portability, applications should not attempt to create +further timer pools after calling `odp_timer_pool_start()`. Note that no such +restrictions exist on timeout pools, as these are just ordinary ODP pools. + +Following start, applications may allocate, set, cancel, and free timers +from their associated timer pools. During termination processing, after all +timers allocated from a timer pool have been freed, the pool itself should be +released via a call to `odp_timer_pool_destroy()`. + +=== Timeout Event Management +The purpose of ODP timers is to schedule their associated timeout events, which +are how applications actually react to the passage of time. To help with this, +several additional APIs and conventions are provided. + +Timer allocation is performed via the `odp_timer_alloc()` API: +[source,c] +----- +/** + * Allocate a timer + * + * Create a timer (allocating all necessary resources e.g. timeout event) from + * the timer pool. The user_ptr is copied to timeouts and can be retrieved + * using the odp_timeout_user_ptr() call. + * + * @param tpid Timer pool identifier + * @param queue Destination queue for timeout notifications + * @param user_ptr User defined pointer or NULL to be copied to timeouts + * + * @return Timer handle on success + * @retval ODP_TIMER_INVALID on failure and errno set. + */ +odp_timer_t odp_timer_alloc(odp_timer_pool_t tpid, + odp_queue_t queue, + void *user_ptr); +----- +Note that in addition to the timer pool id and queue, a user pointer is +provided. This is to allow context associated with the timeout to be +communicated. Upon receiving a timeout event, the application can use +the `odp_timeout_user_ptr()` API to retrieve the user pointer associated +with the timer that triggered this event. + +An worker thread receiving events that may include timeouts might be structured +as follows: +[source,c] +----- +while (1) { + ev = odp_schedule(&from, ODP_SCHED_WAIT); + + switch (odp_event_type(ev)) { + case ODP_EVENT_TIMEOUT: + odp_timeout_t timeout = odp_timeout_from_event(ev); + odp_timer_t timer = odp_timeout_timer(timeout); + void *userptr = odp_timeout_user_ptr(timeout); + uint64_t expiration = odp_timeout_tick(timeout); + + if (!odp_timeout_fresh(timeout)) { + odp_timeout_free(timeout); + continue; + } + + ...process the timeout event + break; + + ...process other event types + } +} +----- +When a worker thread receives a timeout event via `odp_schedule()`, it needs +to determine whether the event is still relevant. A timeout event that is still +relevant is said to be _fresh_ while one that is no longer relevant is said to +be _stale_. Timeouts may be stale for any number of reasons, most of which are +known only to the application itself. However, there are a few cases where the +ODP implementation may be able to assist in this determination and for those +cases the `odp_timeout_fresh()` API is provided. + +ODP defines a fresh timeout simply as one that has not been reset or +canceled since it expired. So if `odp_timeout_fresh()` returns 0 then it is +likely that the application should ignore this event, however if it returns 1 +then it remains an application responsibility to handle the event appropriate +to its needs. diff --git a/doc/users-guide/users-guide.adoc b/doc/users-guide/users-guide.adoc index 0221634..3f16608 100644 --- a/doc/users-guide/users-guide.adoc +++ b/doc/users-guide/users-guide.adoc @@ -907,6 +907,8 @@ include::users-guide-packet.adoc[] include::users-guide-pktio.adoc[] +include::users-guide-timer.adoc[] + == Cryptographic services ODP provides support for cryptographic operations required by various security