On 05.05.2017 11:17, Savolainen, Petri (Nokia - FI/Espoo) wrote: > > >> -----Original Message----- >> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of >> Github ODP bot >> Sent: Thursday, May 04, 2017 8:00 PM >> To: lng-odp@lists.linaro.org >> Subject: [lng-odp] [PATCH API-NEXT v1 2/2] api: ipsec: move soft limits >> expiration to flags, rather than errors >> >> From: Dmitry Eremin-Solenikov <dmitry.ereminsoleni...@linaro.org> >> >> Soft limit expiration isn't an error per se. It does not mean, that we >> received invalid or unprocessed packet. They look more like flags, >> noting that soft limit on this SA was expired. > > Advantage of keeping those among error flags, is the easy/fast check in the > common case: > > Only check (error.u64 == 0) to see that everything is OK vs.
Well, that is exactly my point for moving soft_exp out of error bitfield. Soft expiration is not an error. The packet was processed successfully. In case of outbound inline processing, it was even sent to pktio. I have following code scenarios for the application (leaving alone time based expiration, which should be rethought, especially wrt. SYNC processing): - SYNC or ASYNC: application checks status.flag.soft_exp_* to check if it needs to rekey. Additional care should be applied so that rekeying is not started multiple times for the same SA, because further packet status will also contains soft_exp_* flag set on. - ASYNC or INLINE: application receives IPSEC_STATUS event for this SA queue and then starts rekeying based on that event. I should probably note that there is no direct need to introduce IPSEC_STATUS events for hard timeouts, since they will end up as errors. -- With best wishes Dmitry
