12/01/2023 17:16, De Lara Guarch, Pablo: > From: Thomas Monjalon <tho...@monjalon.net> > > 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?
The patch was merged in the crypto tree but we can discard it. Akhil, please remove this patch from your tree, thanks.
