There is perhaps some ambiguity now in the API on whether expired soft
lifetime means that a packet is not "successfully processed", which in
turn determines whether inline mode outbound packets get sent directly out.
Having the life time expiration in the error field could be interpreted
to imply that soft life time expiration in inline output is not considered
successful processing, so an application can expect getting a result event
with successfully transformed packet but with one of the soft lifetime
error bits set. That works, but I do not think we want to drop out from
inline processing mode just because of soft lifetime (/bytes/packets)
expiration.
Janne
> -----Original Message-----
> From: lng-odp [mailto:[email protected]] On Behalf Of
> Savolainen, Petri
> (Nokia - FI/Espoo)
> Sent: Friday, May 05, 2017 11:18 AM
> To: [email protected]
> Subject: Suspected SPAM - Re: [lng-odp] [PATCH API-NEXT v1 2/2] api: ipsec:
> move soft
> limits expiration to flags, rather than errors
>
>
>
> > -----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)))
>
>
> -Petri
