> On Feb 27, 2020, at 6:26 AM, Neale Ranns (nranns) <nra...@cisco.com> wrote: > > > Hi Chris, > > Adding an IS_INBOUND flag could be non-backward compatible if not setting the > INBOUND flag on an SA and then using it in an inbound context resulted in an > error being returned to the user. so existing clients would be obligated to > set this new flag. If that’s not the case, and client’s don’t have to set the > flag, then I’d ask the question, can the flag be set later, by VPP, when the > SA is used in an inbound context?
tl;dr - no error generated, behavior remains the same for current clients. The older clients wont get any error from not setting the flag. Currently (well 1908) the flag not being set causes things to happen in prep for outbound packets (fib stuff and template headers get created). This setup is skipped if the INBOUND flag is set, but as it doesn't exist in the current API that can't happen. Adding the missing flag allows clients to avoid having this unneeded state setup. Also I didn't look too close at the implications of this state (the fib stuff?) being setup for INBOUND SAs -- avoiding it may be more important than I'm making it sound. FWIW, in my case, I actually start running multiple workers which immediately start allocating and outputting packets when an outbound SA is created, so the impact is a bit more severe for me. Thanks, Chris. > Regards, > neale > > > From: <vpp-dev@lists.fd.io> on behalf of Christian Hopps <cho...@chopps.org> > Date: Tuesday 25 February 2020 at 16:25 > To: vpp-dev <vpp-dev@lists.fd.io> > Cc: Christian Hopps <cho...@chopps.org> > Subject: [vpp-dev] Can I submit some API changes for 19.08, et al. release > branches? > > I've got a couple of changes to the ipsec API that I'd like to upstream to > match the vpp "kernel" code I'm going try and upstream to strongswan. > > 1) Add: Add an ip_route_lookup/reply pair (semver minor++) > 2) Fix: Add IS_INBOUND flag (value 0x40) to ipsec_sad_flags (semver patch++) > optional) Fix: possibly add the other missing flags to ipsec_sad_flags so > they can be properly returned on queries. > > I think submitting these for release branches is OK after reading > https://wiki.fd.io/view/VPP/API_Versioning > > I'm coding to 19.08 right now, if I'd like to have those changes in that > branch I would imagine I'd need to also submit changes for 20.01 and master? > > I admit to being confused about the CRC stuff, and the warnings in the > 19.08.1 release notes and what those warnings imply. Is it safe to assume the > CRC stuff can be ignored and external clients will still work (given no > semver major change) even if a CRC chagnes? > > Side Note: from the API link: "If a new message type is added, the old > message type must be maintained for at least one release. The change must be > included in the release notes, and it would be helpful if the message could > be tagged as deprecated in the API language and a logging message given to > the user." > > Given there are 3 releases per year, only maintaining an old compatible > function for 1 release seems rather aggressive. It does say "at least" > though. :) > > Thanks, > Chris. > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#15589): https://lists.fd.io/g/vpp-dev/message/15589 Mute This Topic: https://lists.fd.io/mt/71535081/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
