> -----Original Message-----
> From: Thomas Monjalon <tho...@monjalon.net>
> Sent: Thursday, January 12, 2023 3:00 PM
> To: Akhil Goyal <gak...@marvell.com>; Ji, Kai <kai...@intel.com>; De Lara
> Guarch, Pablo <pablo.de.lara.gua...@intel.com>
> Cc: dev@dpdk.org; Tyler Retzlaff <roret...@linux.microsoft.com>;
> dev@dpdk.org; David Marchand <david.march...@redhat.com>; Dooley,
> Brian <brian.doo...@intel.com>; Power, Ciara <ciara.po...@intel.com>;
> Mcnamara, John <john.mcnam...@intel.com>
> Subject: Re: [PATCH] crypto/qat: fix build
>
> 12/01/2023 14:22, De Lara Guarch, Pablo:
> > Hi Thomas,
> >
> > From: Thomas Monjalon <tho...@monjalon.net>
> > > 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?
> >
> > 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.
>
> OK good, so we can reject this patch?
>
Well, this patch is merged already, but mine will revert it and add the new flag
(pointing at the other commit to be fixed), so that should be OK, right?
