Re: [dpdk-dev] [PATCH v2] doc: announce change in crypto raw data vector

["Ananyev, Konstantin" <konstantin.ananyev@intel.com>]

> >>> 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.Singh@nxp.com>
> >>> Signed-off-by: Hemant Agrawal <hemant.agrawal@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.ananyev@intel.com>
> >