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: [email protected] The fully removal of Openssl dependency is already ongoing, I will take a note to fix this properly Regards Kai > -----Original Message----- > From: Thomas Monjalon <[email protected]> > Sent: Wednesday, January 11, 2023 11:21 PM > To: Ji, Kai <[email protected]>; De Lara Guarch, Pablo > <[email protected]>; Akhil Goyal <[email protected]> > Cc: [email protected]; Tyler Retzlaff <[email protected]>; > [email protected]; David Marchand <[email protected]>; Dooley, Brian > <[email protected]>; Power, Ciara <[email protected]>; Mcnamara, > John <[email protected]> > Subject: Re: [PATCH] crypto/qat: fix build > > Waiting for an answer here. > The commit log is not supposed to stay like this with questions. > > > 11/01/2023 10:03, Thomas Monjalon: > > 04/01/2023 12:56, Akhil Goyal: > > > > On Fri, Dec 30, 2022 at 10:07:28PM +0100, Thomas Monjalon wrote: > > > > > When trying to compile on a fresh system, I hit this error: > > > > > > > > > > intel-ipsec-mb.h:333: error: "AES_BLOCK_SIZE" redefined > > > > > 333 | #define AES_BLOCK_SIZE IMB_AES_BLOCK_SIZE > > > > > In file included from drivers/crypto/qat/qat_sym_session.c:8: > > > > > /usr/include/openssl/aes.h:26: previous definition > > > > > 26 | # define AES_BLOCK_SIZE 16 > > > > > > > > > > I don't know why it was not seen before. > > > > > Is it because of a change in intel-ipsec-mb.h or in OpenSSL? > > > > > > > > > > Signed-off-by: Thomas Monjalon <[email protected]> > > > > > --- > > > > > > > > owners of intel-ipsec-mb.h should guard against the namespace > > > > conflict... > > > > > > > > Acked-by: Tyler Retzlaff <[email protected]> > > > > > > Applied to dpdk-next-crypto > > If there is no better fix, we should at least add Cc: [email protected] > assuming it could be reproduced with an older DPDK. > > > > > > > Thanks. > > > > I'm concerned to have no answer from Pablo and Kai. > > It is real design problem. Is there any plan to have a protected > namespace? > >
