> >>> 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? > > No, there shall not be any such restriction. Both source and destination > can be different buffer with their own number of elem (if any) and > length of each elem.
Ok, thanks for clarification. > > >>> + > >>> +* 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> > >
