On 9 May 2017 at 23:03, Bogdan Pricope <bogdan.pric...@linaro.org> wrote: > You mean: generating ONE event in SA lifetime vs. carring around 5 > bits for each packet (result) (+ validation), bits that will be mostly > 0 and once in SA lifetime will be 1 (if ever. e.g. if soft/hard limits > supported/enabled). I see it as a inefficient design.
packet results are needed in all scenario and we might add expiry notification only for packets and bytes count and remove for rest. Having a different event will need additional pool configuration since these events cannot be allocated from the same packet pool and if you send them to a specific control core/queue then it would cause a bottleneck. IMO it is better to have them as part of the packet result. Regards, Bala > > On 9 May 2017 at 21:37, Bala Manoharan <bala.manoha...@linaro.org> wrote: >> On 9 May 2017 at 00:04, Bogdan Pricope <bogdan.pric...@linaro.org> wrote: >>> Hi, >>> >>> Can we have this event for all cases: sync/async/inline, >>> inbound/outbound, soft/hard limits? Lifetime expiration is destined to >>> control part of the application... we should be able to process it on >>> a different thread/queue. >> >> In the other cases you have mentioned the packet has to be still sent >> to the application, generating an event will be an additional work and >> there is an additional buffer allocated for the event which could have >> been avoided. I believe there will always be use cases where the data >> thread will have to communicate with control path. >> >> Regards, >> Bala >>> >>> Soft limit - will not affect normal processing of packets - no need >>> for flags as worker does not need to know this; control should >>> renegotiate/cleanup/etc. >>> Hard limits - worker should drop the packet (if platform will not drop >>> the packet for it); control should renegotiate/cleanup/etc. >>> >>> BR, >>> Bogdan >>> >>> >>> On 9 May 2017 at 03:00, Github ODP bot <odp...@yandex.ru> wrote: >>>> From: Dmitry Eremin-Solenikov <dmitry.ereminsoleni...@linaro.org> >>>> >>>> If outbound packet was processed in inline mode, soft limit expiration >>>> event is not reported, as packet goes to the interface. Instead report >>>> this as an ODP_IPSEC_STATUS_SA_SOFT_EXPIRED. >>>> >>>> Signed-off-by: Dmitry Eremin-Solenikov <dmitry.ereminsoleni...@linaro.org> >>>> --- >>>> /** Email created from pull request 22 (lumag:ipsec-limits) >>>> ** https://github.com/Linaro/odp/pull/22 >>>> ** Patch: https://github.com/Linaro/odp/pull/22.patch >>>> ** Base sha: 3ea9c1dac34e0fb4785b0d643056c731daa55e85 >>>> ** Merge commit sha: 85b927011c941f816b853da7284c0c3a939c5efb >>>> **/ >>>> include/odp/api/spec/ipsec.h | 9 ++++++++- >>>> 1 file changed, 8 insertions(+), 1 deletion(-) >>>> >>>> diff --git a/include/odp/api/spec/ipsec.h b/include/odp/api/spec/ipsec.h >>>> index e83494d..c4fe6cb 100644 >>>> --- a/include/odp/api/spec/ipsec.h >>>> +++ b/include/odp/api/spec/ipsec.h >>>> @@ -1080,7 +1080,14 @@ typedef struct odp_ipsec_op_result_t { >>>> */ >>>> typedef enum odp_ipsec_status_id_t { >>>> /** Response to SA disable command */ >>>> - ODP_IPSEC_STATUS_SA_DISABLE = 0 >>>> + ODP_IPSEC_STATUS_SA_DISABLE = 0, >>>> + >>>> + /** >>>> + * Soft limit expired on this SA >>>> + * >>>> + * This event is sent only if SA was configured in OUT INLINE mode. >>>> + */ >>>> + ODP_IPSEC_STATUS_SA_SOFT_EXPIRED >>>> >>>> } odp_ipsec_status_id_t; >>>> >>>>
