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 E30E7A0C3F;
Thu, 15 Apr 2021 15:34:05 +0200 (CEST)
Received: from [217.70.189.124] (localhost [127.0.0.1])
by mails.dpdk.org (Postfix) with ESMTP id 7A1C816228A;
Thu, 15 Apr 2021 15:34:05 +0200 (CEST)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com
[66.111.4.26]) by mails.dpdk.org (Postfix) with ESMTP id C0382162287
for <dev@dpdk.org>; Thu, 15 Apr 2021 15:34:04 +0200 (CEST)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44])
by mailout.nyi.internal (Postfix) with ESMTP id 2B0165C0181;
Thu, 15 Apr 2021 09:34:04 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162])
by compute4.internal (MEProxy); Thu, 15 Apr 2021 09:34:04 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h=
from:to:cc:subject:date:message-id:in-reply-to:references
:mime-version:content-transfer-encoding:content-type; s=fm3; bh=
7pShnUGgtaD0rtudm3XQNTbP6Q005ph6X86QTuyXooQ=; b=hb+HIKMS/qCJBGaD
W0ljvFDVX67yqANEfHc+u9by4gqmdF9VQmQcSWFFhC8jl8VsE1CPc5yN64e68inQ
bmAsaouxJxl6QVYC5oiDBrGydl1y/OlWYF4pei1U+ZRrSC7PV00V691wA5PU/FyA
p468ku2aH6C5cPXrF9/rG6qPpCIXqxhDBK1UJfI1SLemXOLX0XQxw631MGIMNj9u
YRRC9qaYJQ3XJ7muxaGIxER2/Np55MK5WP7x4J7xtz/Jml4L1YjRxp5aYW7PjQ1W
f0LO1vNVvHaL1x9oK5yegSMWW1iDm1SJU6tuvuiQwPmWPiSDWISi7cMm0w9oUORG
y4tDVg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
messagingengine.com; h=cc:content-transfer-encoding:content-type
:date:from:in-reply-to:message-id:mime-version:references
:subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender
:x-sasl-enc; s=fm2; bh=7pShnUGgtaD0rtudm3XQNTbP6Q005ph6X86QTuyXo
oQ=; b=coqYoMwntf9uZGbYeu27g5ywg2GhVKeWd0KMlorGixtN+1LBf1Zy3uezy
lVEvKRcAzp2fywefCqVa8MVnV1yJG2eUD9xVbhacJJY8hOc1wWHzi0s+WJJBw6LX
RRGsZ+kjgAqWl50mZxWnmxHrJjPwnscRtSfLbsc5Oqn/os233Ft9boThzNyGJd3f
9JTwh25ILHz8CY0D1M+cRsMbD2Fpi2LPrlgmlZnsmkH8s4tGG9+VVUTNJ1qk3kQi
wQ6q48cuLVn7cK9M5Iwxp83kDWmB4gTrZt4qmn/2MNHHCAL+701ly5i3mLTuYt/0
9+fuAJW9sk9nw/+TRh/tafdAJjELA==
X-ME-Sender: <xms:ykB4YMfR9i4FHe0LxW9yTilJ278s7YZoyufPWTMEZBJm2lV3n607WA>
<xme:ykB4YCDwuPzHkyHQ7pOua4HX6HoiKaN0nqA4OidJN30xddV9sVYcZIH6HcsrT9ymr
E-IB7eL1qrjsPP2-w>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrudelfedgjedtucetufdoteggodetrfdotf
fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen
uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne
cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr
shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg
ftrfgrthhtvghrnhepffdvuddvhefhteevtdeuffdtleduuefhfeeujeehteegveevieff
vddtffetuedvnecuffhomhgrihhnpehsohhurhgtvgifrghrvgdrohhrghenucfkphepje
ejrddufeegrddvtdefrddukeegnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghm
pehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth
X-ME-Proxy: <xmx:ykB4YGldSDK_CGpLqRCndUmpPus9SettS9JhAuTI0U6ctLB9nEWjbg>
<xmx:ykB4YFd3YguTxz5oXOHEfEw8yEEiyyewWZoEEEDKPlx4Dl1-78motg>
<xmx:ykB4YCT1wVRvAdjuGgnkoY-OXyQ--Bx0m9MHhxJJgB_2bCB8xefrqA>
<xmx:zEB4YKGRigqrI2lvXrX2l1i4ePDIyIdfJ-8lhs9oyj0RSco9rUuvqA>
Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184])
by mail.messagingengine.com (Postfix) with ESMTPA id 2952724005D;
Thu, 15 Apr 2021 09:34:02 -0400 (EDT)
From: Thomas Monjalon <thomas@monjalon.net>
To: Lijun Ou <oulijun@huawei.com>, Ferruh Yigit <ferruh.yigit@intel.com>
Cc: Ray Kinsella <mdr@ashroe.eu>, David Marchand <david.marchand@redhat.com>,
dev@dpdk.org, linuxarm@openeuler.org,
Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
Date: Thu, 15 Apr 2021 15:34:00 +0200
Message-ID: <3496858.GnYqsejKBr@thomas>
In-Reply-To: <fcafea95-9f3c-ce8a-5f3f-26830b979a02@intel.com>
References: <1616670560-62333-1-git-send-email-oulijun@huawei.com>
<9356626.RYGqZy0Vls@thomas> <fcafea95-9f3c-ce8a-5f3f-26830b979a02@intel.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Subject: Re: [dpdk-dev] [PATCH V3] ethdev: add queue state when retrieve
queue information
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
Sender: "dev" <dev-bounces@dpdk.org>
15/04/2021 14:45, Ferruh Yigit:
> On 4/15/2021 1:36 PM, Thomas Monjalon wrote:
> > 15/04/2021 14:33, Ferruh Yigit:
> >> On 4/15/2021 3:40 AM, Lijun Ou wrote:
> >>> Currently, upper-layer application could get queue state only
> >>> through pointers such as dev->data->tx_queue_state[queue_id],
> >>> this is not the recommended way to access it. So this patch
> >>> add get queue state when call rte_eth_rx_queue_info_get and
> >>> rte_eth_tx_queue_info_get API.
> >>>
> >>> Note: After add queue_state field, the 'struct rte_eth_rxq_info' size
> >>> remains 128B, and the 'struct rte_eth_txq_info' size remains 64B, so
> >>> it could be ABI compatible.
> >>>
> >>> Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
> >>> Signed-off-by: Lijun Ou <oulijun@huawei.com>
> >>
> >> Looks good to me, but it is causing an ABI error as we already discussed before
> >> as that is false positive.
> >>
> >> Ray, David,
> >>
> >> Should we add any exception to libabigail.abignore for this?
> >
> > We do not tolerate any ABI warning.
> > If we are sure the ABI change is false positive,
> > it must be suppressed in libabigail.abignore in the same patch.
>
> A new field is added to public structs, but struct size or the location of the
> existing fields are not changing (struct is cache aligned).
>
> Can you please support how this can be added to 'libabigail.abignore'?
This is how you can check the struct sizes (in 32 and 64-bit builds):
for lib in ethdev ; do for struct in rte_eth_{r,t}xq_info ; do for build in dpdk-build/build-{32b,x86-generic} ; do basename $build ; pahole -sC $struct $build/lib/librte_$lib.a ; done ; done ; done
I confirm the additions are not changing the ABI.
And because they are provided as output infos,
there is no issue like using potentially unitialized holes.
It must be explicited in libabigail with this syntax:
https://sourceware.org/libabigail/manual/libabigail-concepts.html#suppress-type
; Ignore fields inserted in alignment hole of rte_eth_rxq_info
[suppress_type]
name = rte_eth_rxq_info
has_data_member_inserted_at = offset_after(scattered_rx)
; Ignore fields inserted in cacheline boundary of rte_eth_txq_info
[suppress_type]
name = rte_eth_txq_info
has_data_member_inserted_between = {offset_after(nb_desc), end}