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: sta...@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? > The fully removal of Openssl dependency is already ongoing, I will take a > note to fix this properly > > Regards > > Kai > > > From: Thomas Monjalon <tho...@monjalon.net> > > 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 <tho...@monjalon.net> > > > > > > --- > > > > > > > > > > owners of intel-ipsec-mb.h should guard against the namespace > > > > > conflict... > > > > > > > > > > Acked-by: Tyler Retzlaff <roret...@linux.microsoft.com> > > > > > > > > Applied to dpdk-next-crypto > > > > If there is no better fix, we should at least add Cc: sta...@dpdk.org > > 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?
