>
> > 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.
