RE: [PATCH] crypto/qat: fix build

["Ji, Kai" <kai.ji@intel.com>]

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@dpdk.org
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 <thomas@monjalon.net>
> Sent: Wednesday, January 11, 2023 11:21 PM
> To: Ji, Kai <kai.ji@intel.com>; De Lara Guarch, Pablo
> <pablo.de.lara.guarch@intel.com>; Akhil Goyal <gakhil@marvell.com>
> Cc: dev@dpdk.org; Tyler Retzlaff <roretzla@linux.microsoft.com>;
> dev@dpdk.org; David Marchand <david.marchand@redhat.com>; Dooley, Brian
> <brian.dooley@intel.com>; Power, Ciara <ciara.power@intel.com>; Mcnamara,
> John <john.mcnamara@intel.com>
> 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@monjalon.net>
> > > > > ---
> > > >
> > > > owners of intel-ipsec-mb.h should guard against the namespace
> > > > conflict...
> > > >
> > > > Acked-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
> > >
> > > Applied to dpdk-next-crypto
> 
> If there is no better fix, we should at least add Cc: stable@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?
> 
>