[dpdk-dev] [PATCH v2 1/7] examples/ipsec-secgw: change CBC IV generation

Sergio Gonzalez Monroy sergio.gonzalez.monroy at intel.com
Thu Sep 29 16:39:04 CEST 2016


On 28/09/2016 04:51, De Lara Guarch, Pablo wrote:
> Hi Sergio,
>
>> -----Original Message-----
>> From: Gonzalez Monroy, Sergio
>> Sent: Friday, September 23, 2016 12:45 AM
>> To: dev at dpdk.org; De Lara Guarch, Pablo
>> Subject: [PATCH v2 1/7] examples/ipsec-secgw: change CBC IV generation
>>
>> NIST SP800-38A recommends two methods to generate unpredictable IVs
>> (Initilisation Vector) for CBC mode:
>> 1) Apply the forward function to a nonce (ie. counter)
>> 2) Use a FIPS-approved random number generator
>>
>> This patch implements the first recommended method by using the forward
>> function to generate the IV.
>>
>> Signed-off-by: Sergio Gonzalez Monroy <sergio.gonzalez.monroy at intel.com>
> [...]
>
>> +static inline void *
>> +get_cop(struct rte_mbuf *m)
>> +{
>> +	struct ipsec_mbuf_metadata *priv = get_priv(m);
>> +
>> +	return &priv->cop;
>> +}
> This function is not used in anywhere. Should it be called somewhere to get the crypto op?

Indeed!
Will be removed in v3.

>> +
>> +static inline void *
>> +get_sym_cop(struct rte_crypto_op *cop)
>> +{
>> +	return (cop + 1);
> Why is this cop + 1? Am I missing something obvious?
> Maybe it is worth a comment here (I noticed this was already in the previous code, but I don't understand it :))

It is just the way the app stores the metadata.
If you look at 'struct ipsec_mbuf_metadata' you can see that sym_cop is 
just after cop.

Sergio

>> +}
>> +
>>   int
>>   inbound_sa_check(struct sa_ctx *sa_ctx, struct rte_mbuf *m, uint32_t
>> sa_idx);
>>
>> --
>> 2.5.5
> Thanks,
> Pablo




More information about the dev mailing list