> Hi Konstantin
>
> On 9/21/2021 12:58 AM, Akhil Goyal wrote:
> >>> From: Gagandeep Singh <g.si...@nxp.com>
> >>>
> >>> The current crypto raw data vectors is 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>
> >>> Acked-by: Akhil Goyal <gak...@marvell.com>
> >>> ---
> >>> lib/cryptodev/rte_crypto_sym.h | 6 ++++++
> >>> 1 file changed, 6 insertions(+)
> >>>
> >>> diff --git a/lib/cryptodev/rte_crypto_sym.h
> >> b/lib/cryptodev/rte_crypto_sym.h
> >>> index dcc0bd5933..e5cef1fb72 100644
> >>> --- a/lib/cryptodev/rte_crypto_sym.h
> >>> +++ b/lib/cryptodev/rte_crypto_sym.h
> >>> @@ -37,6 +37,8 @@ struct rte_crypto_vec {
> >>> rte_iova_t iova;
> >>> /** length of the data buffer */
> >>> uint32_t len;
> >>> + /** total buffer length*/
> >>> + uint32_t tot_len;
> >>> };
> >>>
> >>> /**
> >>> @@ -980,12 +982,14 @@ rte_crypto_mbuf_to_vec(const struct rte_mbuf
> >> *mb, uint32_t ofs, uint32_t len,
> >>> seglen = mb->data_len - ofs;
> >>> if (len <= seglen) {
> >>> vec[0].len = len;
> >>> + vec[0].tot_len = mb->buf_len;
> >> That doesn't look right.
> >> We should take into a count mbuf headroom and input offset.
> >> Something like:
> >> vec[0].tot_len = mb->buf_len - rte_pktmbuf_headroom(m) - ofs;
> >> Same in other places below.
> >>
> > I believe the packet can expand into headroom based on the protocol support.
> Yes, total length is representing the total buffer length available. The
> security protocol shall take care of the headroom and offsets.
Hmm, and how it will now how many bytes are in head-room, and how many are in
tail-room?
We either need to provide values for both, or assume that only tail-room is
available for the driver.
