[PATCH] crypto/qat: fix build

[Thomas Monjalon]

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?

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