From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.9 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id F0124C2D0EA for ; Wed, 8 Apr 2020 07:52:53 +0000 (UTC) Received: from dpdk.org (dpdk.org [92.243.14.124]) by mail.kernel.org (Postfix) with ESMTP id 8C2B320747 for ; Wed, 8 Apr 2020 07:52:53 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="MBQUQaAT" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8C2B320747 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=dev-bounces@dpdk.org 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 ; 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 ; 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 X-Google-Original-From: Dodji Seketeli Received: by localhost (Postfix, from userid 1001) id 1362D1A4B72; Wed, 8 Apr 2020 09:52:43 +0200 (CEST) To: Dodji Seketeli Cc: Hemant Agrawal , David Marchand , "Hemant Agrawal \(OSS\)" , "Yigit\, Ferruh" , dev , Neil Horman , Thomas Monjalon Organization: Red Hat / France References: <20200302145829.27808-1-hemant.agrawal@nxp.com> <877dzscx97.fsf@redhat.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Hello Thomas, Hemant, Thomas Monjalon 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 writes: > Hello Hemant, > > Hemant Agrawal 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