From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124])
	by inbox.dpdk.org (Postfix) with ESMTP id B0A18423B8;
	Thu, 12 Jan 2023 17:34:42 +0100 (CET)
Received: from mails.dpdk.org (localhost [127.0.0.1])
	by mails.dpdk.org (Postfix) with ESMTP id 9538C42D55;
	Thu, 12 Jan 2023 17:34:42 +0100 (CET)
Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182])
 by mails.dpdk.org (Postfix) with ESMTP id 13D9042D4F
 for <dev@dpdk.org>; Thu, 12 Jan 2023 17:34:41 +0100 (CET)
Received: by linux.microsoft.com (Postfix, from userid 1086)
 id 6771F20DE4B7; Thu, 12 Jan 2023 08:34:40 -0800 (PST)
DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 6771F20DE4B7
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com;
 s=default; t=1673541280;
 bh=y3eRDl4uDo8szydgEXGhYGnXHfJw16sPOVSjsdgs7oo=;
 h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
 b=OQB1ksI48eLFUKTBSWJQLr48bP6lLYrtYNTsLZaw7Tl5ysIZoq6Bshhi+s2trhp/v
 LCTGDJB+eCWPPfktgxo4ySPm91qE5FA6h2njizKouEnWPrwyzPJwgH5ldf7r9RFezt
 Gxl7zHd1uaDFQVWVkCjN6ynosgu23DfwKliEoRc8=
Date: Thu, 12 Jan 2023 08:34:40 -0800
From: Tyler Retzlaff <roretzla@linux.microsoft.com>
To: "De Lara Guarch, Pablo" <pablo.de.lara.guarch@intel.com>
Cc: Thomas Monjalon <thomas@monjalon.net>, Akhil Goyal <gakhil@marvell.com>,
 "Ji, Kai" <kai.ji@intel.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
Message-ID: <20230112163440.GA7449@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net>
References: <20221230210728.86920-1-thomas@monjalon.net>
 <9337009.CDJkKcVGEf@thomas>
 <SN6PR11MB3408E4046FCE48AFA6E334AA81FD9@SN6PR11MB3408.namprd11.prod.outlook.com>
 <3685739.QJadu78ljV@thomas>
 <DM8PR11MB5591AE804AAF3F744B6A563384FD9@DM8PR11MB5591.namprd11.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <DM8PR11MB5591AE804AAF3F744B6A563384FD9@DM8PR11MB5591.namprd11.prod.outlook.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org

On Thu, Jan 12, 2023 at 01:22:09PM +0000, De Lara Guarch, Pablo wrote:
> Hi Thomas,
> 
> > -----Original Message-----
> > From: Thomas Monjalon <thomas@monjalon.net>
> > Sent: Thursday, January 12, 2023 10:41 AM
> > To: De Lara Guarch, Pablo <pablo.de.lara.guarch@intel.com>; Akhil Goyal
> > <gakhil@marvell.com>; Ji, Kai <kai.ji@intel.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
> > 
> > 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.

doesn't this mean the compat could have been retained with a simple
check?

#ifndef AES_BLOCK_SIZE
#define AES_BLOCK_SIZE IMB_AES_BLOCK_SIZE
#endif

anyway, you can ignore this comment if you already worked out a solution
on the mail thread.