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.
