On Fri, May 5, 2017 at 3:17 AM, Savolainen, Petri (Nokia - FI/Espoo) < [email protected]> 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. > > checking always both (error.u64 == 0 && (status.u64 == 0 || > (status.soft_exp_sec == 0 && status.soft_exp_bytes == 0 && > status.soft_exp_packets == 0))) > Agree on keeping error bits together for check simplicity, but as discussed on other threads status events should be their own events, not piggybacked onto operation results since these are essentially control signals rather than things that worker threads would process. The point is that a worker receiving this notification can only pass it along to someone else since workers aren't (or shouldn't) be involved in rekeying. So better to have a separate control thread that receives such notifications directly. > > > -Petri > >
