[dpdk-dev] [PATCH v2 02/15] crypto: add total raw buffer length

[Hemant Agrawal]

Hi Konstantin

On 9/21/2021 12:58 AM, Akhil Goyal wrote:
>>> From: Gagandeep Singh <g.singh at 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.singh at nxp.com>
>>> Acked-by: Akhil Goyal <gakhil at 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.