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

Message ID 20170505123435.11019-1-petri.savolainen@linaro.org
State New
Headers show
Series
  • [API-NEXT,1/3] api: ipsec: refine packet order specification
Related show

Commit Message

Petri Savolainen May 5, 2017, 12:34 p.m.
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

Comments

Bill Fischofer May 5, 2017, 3:31 p.m. | #1
Other than the small comment in part 3, for this series:

Reviewed-by: Bill Fischofer <bill.fischofer@linaro.org>


On Fri, May 5, 2017 at 7:34 AM, Petri Savolainen <
petri.savolainen@linaro.org> wrote:

> 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(-)

>

> diff --git a/include/odp/api/spec/ipsec.h b/include/odp/api/spec/ipsec.h

> index e83494d3..bec9c561 100644

> --- a/include/odp/api/spec/ipsec.h

> +++ b/include/odp/api/spec/ipsec.h

> @@ -1192,13 +1192,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

> @@ -1222,13 +1228,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.

> --

> 2.11.0

>

>

Patch hide | download patch | download mbox

diff --git a/include/odp/api/spec/ipsec.h b/include/odp/api/spec/ipsec.h
index e83494d3..bec9c561 100644
--- a/include/odp/api/spec/ipsec.h
+++ b/include/odp/api/spec/ipsec.h
@@ -1192,13 +1192,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
@@ -1222,13 +1228,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.