From: Thomas Monjalon <thomas@monjalon.net>
To: Akhil Goyal <gakhil@marvell.com>, "Ji, Kai" <kai.ji@intel.com>,
"De Lara Guarch, Pablo" <pablo.de.lara.guarch@intel.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
Tyler Retzlaff <roretzla@linux.microsoft.com>,
"dev@dpdk.org" <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
Date: Thu, 12 Jan 2023 16:00:05 +0100 [thread overview]
Message-ID: <23216321.6Emhk5qWAg@thomas> (raw)
In-Reply-To: <DM8PR11MB5591AE804AAF3F744B6A563384FD9@DM8PR11MB5591.namprd11.prod.outlook.com>
12/01/2023 14:22, De Lara Guarch, Pablo:
> Hi Thomas,
>
> From: Thomas Monjalon <thomas@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: stable@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?
next prev parent reply other threads:[~2023-01-12 15:00 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-30 21:07 Thomas Monjalon
2022-12-30 21:38 ` Tyler Retzlaff
2023-01-04 11:56 ` [EXT] " Akhil Goyal
2023-01-11 9:03 ` Thomas Monjalon
2023-01-11 23:20 ` Thomas Monjalon
2023-01-12 10:32 ` Ji, Kai
2023-01-12 10:40 ` Thomas Monjalon
2023-01-12 13:22 ` De Lara Guarch, Pablo
2023-01-12 15:00 ` Thomas Monjalon [this message]
2023-01-12 16:16 ` De Lara Guarch, Pablo
2023-01-12 16:28 ` Thomas Monjalon
2023-01-12 16:56 ` [EXT] " Akhil Goyal
2023-01-12 16:34 ` Tyler Retzlaff
2023-01-12 19:30 Pablo de Lara
2023-01-12 20:39 ` Thomas Monjalon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=23216321.6Emhk5qWAg@thomas \
--to=thomas@monjalon.net \
--cc=brian.dooley@intel.com \
--cc=ciara.power@intel.com \
--cc=david.marchand@redhat.com \
--cc=dev@dpdk.org \
--cc=gakhil@marvell.com \
--cc=john.mcnamara@intel.com \
--cc=kai.ji@intel.com \
--cc=pablo.de.lara.guarch@intel.com \
--cc=roretzla@linux.microsoft.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).