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. > > -- > With best wishes > Dmitry
