Hi Hemant, > > The current crypto raw data vectors need to be extended to support > > out of place processing. It is proposed to add additional desl_sgl > > to provide details for destination sgl. > > The same is also extended to support rte_security usecases, where > > we need total data length to know how much additional memory space > > is available in buffer other than data length so that driver/HW > > can write expanded size data after encryption. > > > > Signed-off-by: Gagandeep Singh <g.si...@nxp.com> > > Signed-off-by: Hemant Agrawal <hemant.agra...@nxp.com> > > --- > > doc/guides/rel_notes/deprecation.rst | 12 ++++++++++++ > > 1 file changed, 12 insertions(+) > > > > diff --git a/doc/guides/rel_notes/deprecation.rst > > b/doc/guides/rel_notes/deprecation.rst > > index f4a4d00db2..c19a306c93 100644 > > --- a/doc/guides/rel_notes/deprecation.rst > > +++ b/doc/guides/rel_notes/deprecation.rst > > @@ -193,3 +193,15 @@ Deprecation Notices > > reserved bytes to 2 (from 3), and use 1 byte to indicate warnings and > > other > > information from the crypto/security operation. This field will be used > > to > > communicate events such as soft expiry with IPsec in lookaside mode. > > + > > +* cryptodev: The structure ``rte_crypto_sym_vec`` would be updated to add > > + ``dest_sgl`` to support out of place processing. This field will be null > > for > > + inplace processing. This change is targeted for DPDK 21.11
Seems ok to me, just one question: would layout (number of elems in SG, length of each elem) for sgl and dest_sgl always be identical? > > + > > +* cryptodev: The structure ``rte_crypto_vec`` would be updated to add > > + ``tot_len`` to support total buffer length. This is required for security > > + cases like IPsec and PDCP encryption offload to know how much additional > > + memory space is available in buffer other than data length so that > > driver/HW > > + can write expanded size data after encryption. This change is targeted > > for > > + DPDK 21.11 > > + Acked-by: Konstantin Ananyev <konstantin.anan...@intel.com>