[PATCH] crypto/qat: fix build

De Lara Guarch, Pablo pablo.de.lara.guarch at intel.com
Thu Jan 12 14:22:09 CET 2023


Hi Thomas,

> -----Original Message-----
> From: Thomas Monjalon <thomas at monjalon.net>
> Sent: Thursday, January 12, 2023 10:41 AM
> To: De Lara Guarch, Pablo <pablo.de.lara.guarch at intel.com>; Akhil Goyal
> <gakhil at marvell.com>; Ji, Kai <kai.ji at intel.com>
> Cc: dev at dpdk.org; Tyler Retzlaff <roretzla at linux.microsoft.com>;
> dev at dpdk.org; David Marchand <david.marchand at redhat.com>; Dooley,
> Brian <brian.dooley at intel.com>; Power, Ciara <ciara.power at intel.com>;
> Mcnamara, John <john.mcnamara at intel.com>
> Subject: Re: [PATCH] crypto/qat: fix build
> 
> 12/01/2023 11:32, Ji, Kai:
> > Ok, a long story short, this issue should only occurred when
> RTE_QAT_LIBIPSECMB is enabled.
> > It was intend to remove Openssl lib dependency in QAT replaced with
> > ipsec_mb lib, but the work was partially done due to limitation of
> > ipsec_mb by the time (FIPS certification)
> >
> > I'm happy with current fix and please cc: stable at dpdk.org
> 
> I'm not happy with this fix. It is a dirty workaround.
> It would be better to have an #ifdef in ipsec_mb.
> 
> Also I would like an answer to the question below. What triggered this error?
> Is it a new thing in the lib ipsec_mb?
> Why defining AES_BLOCK_SIZE while IMB_AES_BLOCK_SIZE can be used and
> have a proper prefix?

Apologies for the late response.

This macro was renamed to IMB_AES_BLOCK_SIZE, as you already know.
The problem is that, for compatibility reasons, we had to keep the old macro as well.
However, we added a compile time flag to remove these legacy macros, for exactly this reason
(NO_COMPAT_IMB_API_053).

I think a solution could be to use this flag in QAT, so the legacy macros are not defined.

I will send a patch to fix this.

Thanks,
Pablo

> 



More information about the dev mailing list