| Message ID | 20170505123435.11019-1-petri.savolainen@linaro.org |
|---|---|
| State | Superseded |
| Headers | show |
| Series | [API-NEXT,1/3] api: ipsec: refine packet order specification | expand |
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 > >
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.
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