diff mbox series

[API-NEXT,v2,1/2] api: ipsec: refine packet order specification

Message ID 20170602093820.23064-2-petri.savolainen@linaro.org
State Accepted
Commit ce2122df54a67451741cb7f459278174e079276f
Headers show
Series IPsec API update | expand

Commit Message

Petri Savolainen June 2, 2017, 9:38 a.m. UTC
State more explicitly that async ipsec operations maintain packet
order the same way as odp_queue_enq_multi().

Signed-off-by: Petri Savolainen <petri.savolainen@linaro.org>

---
 include/odp/api/spec/ipsec.h | 40 ++++++++++++++++++++++++++--------------
 1 file changed, 26 insertions(+), 14 deletions(-)

-- 
2.11.0
diff mbox series

Patch

diff --git a/include/odp/api/spec/ipsec.h b/include/odp/api/spec/ipsec.h
index 3adc65f5..24f9fb18 100644
--- a/include/odp/api/spec/ipsec.h
+++ b/include/odp/api/spec/ipsec.h
@@ -1218,13 +1218,19 @@  int odp_ipsec_out(const odp_ipsec_op_param_t *input,
  * results through one or more ODP_EVENT_IPSEC_RESULT events with the following
  * ordering considerations.
  *
- * Asynchronous mode maintains (operation input) packet order per SA when
- * application calls the operation within an ordered or atomic scheduler context
- * of the same queue. Packet order is also maintained when application
- * otherwise guarantees (e.g. using locks) that the operation is not called
- * simultaneously from multiple threads for the same SA(s). Resulting
- * events for the same SA are enqueued in order, and packet handles (for the
- * same SA) are stored in order within an event.
+ * Asynchronous mode maintains packet order per SA when application calls the
+ * operation within an ordered or atomic scheduler context of the same queue.
+ * Resulting events for the same SA are enqueued in order and packet handles
+ * (for the same SA) are stored in order within an event. Packet order per SA at
+ * a destination queue is the same as if application would have enqueued packets
+ * there with odp_queue_enq_multi().
+ *
+ * Packet order is also maintained when application otherwise guarantees
+ * (e.g. using locks) that the operation is not called simultaneously from
+ * multiple threads for the same SA(s).
+ *
+ * Logically, packet processing (e.g. sequence number check) happens in the
+ * output order as defined above.
  *
  * The function may be used also in inline processing mode, e.g. for IPSEC
  * packets for which inline processing is not possible. Packets for the same SA
@@ -1248,13 +1254,19 @@  int odp_ipsec_in_enq(const odp_ipsec_op_param_t *input);
  * results through one or more ODP_EVENT_IPSEC_RESULT events with the following
  * ordering considerations.
  *
- * Asynchronous mode maintains (operation input) packet order per SA when
- * application calls the operation within an ordered or atomic scheduler context
- * of the same queue. Packet order is also maintained when application
- * otherwise guarantees (e.g. using locks) that the operation is not called
- * simultaneously from multiple threads for the same SA(s). Resulting
- * events for the same SA are enqueued in order, and packet handles (for the
- * same SA) are stored in order within an event.
+ * Asynchronous mode maintains packet order per SA when application calls the
+ * operation within an ordered or atomic scheduler context of the same queue.
+ * Resulting events for the same SA are enqueued in order and packet handles
+ * (for the same SA) are stored in order within an event. Packet order per SA at
+ * a destination queue is the same as if application would have enqueued packets
+ * there with odp_queue_enq_multi().
+ *
+ * Packet order is also maintained when application otherwise guarantees
+ * (e.g. using locks) that the operation is not called simultaneously from
+ * multiple threads for the same SA(s).
+ *
+ * Logically, packet processing (e.g. sequence number assignment) happens in the
+ * output order as defined above.
  *
  * The function may be used also in inline processing mode, e.g. for IPSEC
  * packets for which inline processing is not possible.