On 28.04.2017 01:23, Bill Fischofer wrote: > > > On Thu, Apr 27, 2017 at 6:51 AM, Dmitry Eremin-Solenikov > <dmitry.ereminsoleni...@linaro.org > <mailto:dmitry.ereminsoleni...@linaro.org>> wrote: > > If an application has passed invalid SA in async mode, there is no way > to report it back to application except using default queue (which does > not exist at this moment). > > Signed-off-by: Dmitry Eremin-Solenikov > <dmitry.ereminsoleni...@linaro.org > <mailto:dmitry.ereminsoleni...@linaro.org>> > --- > include/odp/api/spec/ipsec.h | 7 +++++++ > 1 file changed, 7 insertions(+) > > diff --git a/include/odp/api/spec/ipsec.h b/include/odp/api/spec/ipsec.h > index 4f746f67..7f43e81c 100644 > --- a/include/odp/api/spec/ipsec.h > +++ b/include/odp/api/spec/ipsec.h > @@ -190,6 +190,13 @@ typedef struct odp_ipsec_inbound_config_t { > * Configuration options for IPSEC outbound processing > */ > typedef struct odp_ipsec_outbound_config_t { > + /** Default destination queue for IPSEC events > + * > + * When passed invalid SA in the asynchronous mode, > + * resulting IPSEC events are enqueued into this queue. > + */ > + odp_queue_t default_queue; > > > Is an invalid SA going to be passed for any legitimate reason or is this > always a programming error? If the latter then this seems unnecessary as > this case falls under the "results are undefined" category. If the > former, then why can't the call simply be failed before being accepted > for async processing? The caller is "owed" an odp_ipsec_result_t only if > the async call is successful.
Unfortunately returning an error or 'processing stopped here' does not allow application to determine the cause of that error/processing stop. So, it well might resubmit the packet later. Thus it might be better to accept such packet and return an error through event. -- With best wishes Dmitry
