From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from dpdk.org (dpdk.org [92.243.14.124])
by inbox.dpdk.org (Postfix) with ESMTP id 434A1A0597;
Wed, 8 Apr 2020 09:52:53 +0200 (CEST)
Received: from [92.243.14.124] (localhost [127.0.0.1])
by dpdk.org (Postfix) with ESMTP id 938381BFC1;
Wed, 8 Apr 2020 09:52:52 +0200 (CEST)
Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com
[205.139.110.120]) by dpdk.org (Postfix) with ESMTP id 02C141BF9D
for <dev@dpdk.org>; Wed, 8 Apr 2020 09:52:50 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
s=mimecast20190719; t=1586332370;
h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
to:to:cc:cc:mime-version:mime-version:content-type:content-type:
content-transfer-encoding:content-transfer-encoding:
in-reply-to:in-reply-to:references:references;
bh=RleMAu77NyFOTyA6MiOWcPZJf3rkav/QPIzbcTXmXHQ=;
b=MBQUQaATRkJUJKteYB475y8MBpTGfCx39KAXfl3redmffqSlBuupA1zmK5V9M9zAmH5kNS
bFJ8vgEGfi2MC8U2clAO13bs8CjKYsYDxfcg2irws6sa0VGRqu6Uh6fplemdM2GjVBtKcY
zbaWs9DqpXqXP3zxiUT72miFXjWxNYE=
Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com
[209.85.128.70]) (Using TLS) by relay.mimecast.com with ESMTP id
us-mta-314-1A8nu0a8OOmDKN58wiCEJw-1; Wed, 08 Apr 2020 03:52:48 -0400
X-MC-Unique: 1A8nu0a8OOmDKN58wiCEJw-1
Received: by mail-wm1-f70.google.com with SMTP id s22so2007416wmh.8
for <dev@dpdk.org>; Wed, 08 Apr 2020 00:52:47 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:from:to:cc:subject:organization:references:date
:in-reply-to:message-id:user-agent:mime-version;
bh=7s5IZk7n5EXu/w7L39BS7lfrZn8lCEbX4xeJnsx7jvY=;
b=OimzTWRMjneXCkmwG3Xnnij19uALWY7PngW1n6nu4xtBYswtqOUOC+AcXRjnZlhL68
6MARcT7+FZhMZXIBGyjpTC8HW/FMM9H+EW+aioF0mQRtQfchf0vYdZnCznnoh4c9ZosF
u5RuGV3+ezxQVqu1ubDs16A1J9jxeJudPR87LHyo10l9UXfebdSUYJwupl6doQ7jZXUP
CmxmeEIA0XlBxU3OgaIzyrf0geVkDE0SuSaCeaEOh1N2V/nYFjTjyaxkrPVCPy3Z18z5
RRHnfkKi+FFV2qXDYWK6Fxn7MJMSFguUv61GaGLEnor3CT+92vtoMd6PxQbWmAil1iKJ
uqyw==
X-Gm-Message-State: AGi0PubG/vgx46Rvl7hN+hv4JQQQJirwNsafQ6yWL2SHxPzuPEsNvHQ4
xUlVGhrgCIvN088adpKYfyKWQmNxPK+pxA7OTG0WdbUoiVgV+ufquBp0rqiFtzjPp+GonFsTsMQ
Fy/Y=
X-Received: by 2002:a1c:9e42:: with SMTP id h63mr3110397wme.115.1586332366184;
Wed, 08 Apr 2020 00:52:46 -0700 (PDT)
X-Google-Smtp-Source: APiQypKeURzU2pPbbx8uxd08fHPS7Wp8Q3IBbAtmSGjGUMioYiXYje/we4mVSXeOOblTQbOVmbwBVQ==
X-Received: by 2002:a1c:9e42:: with SMTP id h63mr3110375wme.115.1586332365817;
Wed, 08 Apr 2020 00:52:45 -0700 (PDT)
Received: from localhost (91-166-131-130.subs.proxad.net. [91.166.131.130])
by smtp.gmail.com with ESMTPSA id n6sm5729965wmc.28.2020.04.08.00.52.44
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Wed, 08 Apr 2020 00:52:45 -0700 (PDT)
From: Dodji Seketeli <dseketel@redhat.com>
X-Google-Original-From: Dodji Seketeli <dodji@redhat.com>
Received: by localhost (Postfix, from userid 1001)
id 1362D1A4B72; Wed, 8 Apr 2020 09:52:43 +0200 (CEST)
To: Dodji Seketeli <dseketel@redhat.com>
Cc: Hemant Agrawal <hemant.agrawal@nxp.com>,
David Marchand <david.marchand@redhat.com>,
"Hemant Agrawal \(OSS\)" <hemant.agrawal@oss.nxp.com>, "Yigit\,
Ferruh" <ferruh.yigit@intel.com>, dev <dev@dpdk.org>,
Neil Horman <nhorman@tuxdriver.com>, Thomas Monjalon <thomas@monjalon.net>
Organization: Red Hat / France
References: <20200302145829.27808-1-hemant.agrawal@nxp.com>
<CAJFAV8ykFnUo7StJ43jiGB+0DQJcFRJwXzawV9+SdVXfghV=xw@mail.gmail.com>
<VI1PR0401MB254158AB9661187C4461237789E20@VI1PR0401MB2541.eurprd04.prod.outlook.com>
<CAJFAV8zP8ogg+VDnrk3Xr1vzR-e1OYJ0tP4xJ4vhUi4tKJyeww@mail.gmail.com>
<VI1PR0401MB254100E72B2601D45800C68989E20@VI1PR0401MB2541.eurprd04.prod.outlook.com>
<CAJFAV8x=pGZzCm2GSZeU+W1dZPU-97JOCJdtD+HN9H3Fz+9VHA@mail.gmail.com>
<877dzscx97.fsf@redhat.com>
<VI1PR0401MB25416917B15E08C9F188B51689C30@VI1PR0401MB2541.eurprd04.prod.outlook.com>
<86v9mao34d.fsf@redhat.com>
X-Operating-System: Red Hat Enterprise Linux Server 7.7
X-URL: http://www.redhat.com
Date: Wed, 08 Apr 2020 09:52:43 +0200
In-Reply-To: <86v9mao34d.fsf@redhat.com> (Dodji Seketeli's message of "Wed, 08
Apr 2020 09:20:18 +0200")
Message-ID: <86r1wyo1mc.fsf@redhat.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)
MIME-Version: 1.0
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: redhat.com
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable
Subject: Re: [dpdk-dev] [PATCH 00/16] NXP DPAAx fixes and enhancements
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
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
Sender: "dev" <dev-bounces@dpdk.org>
Hello Thomas, Hemant,
Thomas Monjalon <thomas@monjalon.net> writes:
> 07/04/2020 12:25, Hemant Agrawal:
[...]
>> [Hemant] I have commented on Neil's series.
>> It needs more changes in existing code.
>> An approach like __rte_experimental will work better.
>
> I guess you mean __rte_internal?
>
> Please Hemant don't wait for someone else filling the gap.
> If __rte_internal is the right approach, please complete and use it.
Just so that I understand, is __rte_internal an ELF version that the
symbols per_lcore_dpaa2_held_bufs, dpaa2_io_portal and
per_lcore__dpaa2_io should have in the binary?
If that is the case, then it seems to me that the __rte_internal
approach that you are suggesting would be a much better approach that
the one I replied to Hemant about below.
I didn't mean to tell Hemant what approach he should take :-) I was just
trying to help him get the syntax of a libabigail suppression
specification right.
Sorry for the confusion I might have induced.
Dodji Seketeli <dseketel@redhat.com> writes:
> Hello Hemant,
>
> Hemant Agrawal <hemant.agrawal@nxp.com> writes:
>
> [...]
>
>>> >> > > [Hemant]
>>> >> > > As per the logs:
>>> >> > >
>>> >> > > Variables changes summary: 1 Removed, 2 Changed, 0 Added
>>> >> > > variables
>>> >> > > 1 Removed variable:
>>> >> > > 'dpaa2_portal_dqrr per_lcore_dpaa2_held_bufs'
>>> >> > {per_lcore_dpaa2_held_bufs@@DPDK_20.0}
>>> >> > > 2 Changed variables:
>>> >> > > [C]'dpaa2_io_portal_t dpaa2_io_portal[128]' was changed at
>>> >> > dpaa2_hw_dpio.h:40:1: size of symbol changed from 5120 to 2048
>>> >> > > [C]'dpaa2_io_portal_t per_lcore__dpaa2_io' was changed at
>>> >> > > dpaa2_hw_dpio.h:20:1: size of symbol changed from 40 to 16
>>> >> > >
>>> >> > > Error: ABI issue reported for 'abidiff --suppr
>>> >> > > devtools/libabigail.abignore --
>>> >> > no-added-syms --headers-dir1 reference/usr/local/include
>>> >> > --headers-dir2 install/usr/local/include
>>> >> > reference/dump/librte_bus_fslmc.dump
>>> >> > install/dump/librte_bus_fslmc.dump'
>
> [...]
>
>>> In the mean time, the tooling can be tought to ignore changes to these =
ELF
>>> symbols, as you you guys all know already.
>>>=20
>> [Hemant] will you please help me about adding entry to libagigail.abigno=
re=20
>> I tried doing following, but it is not helping
>> --- a/devtools/libabigail.abignore
>> +++ b/devtools/libabigail.abignore
>> @@ -2,10 +2,15 @@
>> symbol_version =3D EXPERIMENTAL
>> [suppress_variable]
>> symbol_version =3D EXPERIMENTAL
>> + name =3D per_lcore__dpaa2_io
>> + name =3D dpaa2_io_portal
>>
>> ; Explicit ignore for driver-only ABI
>> [suppress_type]
>> name =3D rte_cryptodev_ops
>> + name =3D dpaa2_io_portal_t
>
> So, I understand you want the tooling to ignore changes to the global
> arrays dpaa2_io_portal and per_lcore__dpaa2_io, right?
>
> If that is correct, then here are the entries you should add to the
> libabigail.abignore file (please make sure the comments I have added
> there is accurate):
>
> [suppress_variable]
> # This global variable is exported by the binary but is not par=
t of
> # the logical ABI. In a perfect world, that variable should no=
t be
> # global, and we should access it via an accessor function. We=
do
> # that right now because of performance concerns.
> name =3D dpaa2_io_portal
>
> [suppress_variable]
> # This global variable is exported by the binary but is not par=
t of
> # the logical ABI. In a perfect world, that variable should no=
t be
> # global, and we should access it via an accessor function. We=
do
> # that right now because of performance concerns.
> name =3D per_lcore__dpaa2_io
>
> I hope this helps.
>
> Cheers,
--=20
=09=09Dodji