On 06.05.2017 00:29, Bill Fischofer wrote: > On Fri, May 5, 2017 at 4:24 PM, Dmitry Eremin-Solenikov > <[email protected]> wrote: >> On 05.05.2017 11:17, Savolainen, Petri (Nokia - FI/Espoo) wrote: >>> >>> >>>> -----Original Message----- >>>> From: lng-odp [mailto:[email protected]] On Behalf Of >>>> Github ODP bot >>>> Sent: Thursday, May 04, 2017 8:00 PM >>>> To: [email protected] >>>> Subject: [lng-odp] [PATCH API-NEXT v1 2/2] api: ipsec: move soft limits >>>> expiration to flags, rather than errors >>>> >>>> From: Dmitry Eremin-Solenikov <[email protected]> >>>> >>>> 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. > > Hard and soft timeouts have the same problem in that they are > independent of any packet. So if no packets are being processed you > might never notice that a hard timeout has passed. Agree we need to > discuss this next week, but treating all such expirations uniformly as > async events seems consistent and straightforward.
This is for bytes and packets expiry, as stated above. -- With best wishes Dmitry
