> -----Original Message----- > From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of > Peltonen, Janne (Nokia - FI/Espoo) > Sent: Thursday, March 23, 2017 5:25 PM > To: Nikhil Agarwal <nikhil.agar...@nxp.com>; lng-odp@lists.linaro.org > Subject: Suspected SPAM - Re: [lng-odp] [API-NEXT PATCH v2 2/3] api: > ipsec: add inline IPSEC support > > Hi, > > A few quick comments below. Petri will probably comment the other points. > > Janne > > > -----Original Message----- > > From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of > Nikhil Agarwal > > Sent: Thursday, March 23, 2017 2:02 PM > > To: Petri Savolainen <petri.savolai...@linaro.org>; lng- > o...@lists.linaro.org > > Subject: Re: [lng-odp] [API-NEXT PATCH v2 2/3] api: ipsec: add inline > IPSEC support > > > > Few initial comments: > > > > - For Mixing inline and async processing must maintain same SA context > in HW and > > implementation. In that case, we should shift to async SA creation so > that while creating > > an SA, HW interface can return the context to sw and Async processing > can be done for > > that context.
I think synchronous creation is simpler to use and it should not be a problem if creation takes a bit longer time in inline case. It's not a fast path function. > > - Why we want to add different level of header retention, we can add > retain header or > > discard. " Select up to which protocol layer (at least) outer headers are retained ... " So, it's OK to retain all layers always. Application just informs the minimum requirement. If implementation needs to do a copy (in SW) to retain headers, it would be waste to always require all headers (e.g. >60 bytes with IPv6+options) to be retained, when application is interested in only e.g. first 14 bytes. > > - Why parsing is optional and layer wise. Parsing should be same as on > the pktio > > interface. Even in the lookaside APIs L3 parsing was mandatory. > Otherwise application will > > have to do the parsing on its own. Moreover, application will never know > L3 protocol if > > there are no parse results. Fixed parsing requirement is replaced also for the lookaside API. Parsing is done for the decapsulated packet. The resulting packet after IPSEC has always an IP header, thus the L3 offset must be always set (== the start of the resulting packet). So, for LAYER_NONE application would not require any parsing - just the starting point (L3 offset). > > - Support for ESP/AH and Tunnel/Transport mode should be exposed via > capability. These are part of the protocol, not special features - so I think those should not be optional. > > - What about enabling HASH distribution post IPSEC for FAT tunnel use > case. Maybe in future. But if/when classifier is added with hashing capability, it may not be needed after that. -Petri
