From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 59E33A0A05; Wed, 20 Jan 2021 16:41:25 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id DEDEF140DBD; Wed, 20 Jan 2021 16:41:24 +0100 (CET) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by mails.dpdk.org (Postfix) with ESMTP id 8F8C8140DB4 for ; Wed, 20 Jan 2021 16:41:23 +0100 (CET) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id D6F365C0190; Wed, 20 Jan 2021 10:41:22 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Wed, 20 Jan 2021 10:41:22 -0500 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= He3civzFVKVIQ+02/Z4KOj0SfLojdKl9JN9T7X9ENiM=; b=raXxcrstp2JemeMS 79C/2I9dH7gCGRrDQWQUifdnIciVAvMk61prEeNq93UBn+WxabwmtUO68ISIrVql YJSwhwWCmblPYtwcxIMFRGmza/6BO7xOTGFk1UmMs30bgWKewHHv4zU1/2T2wixS BlYDCetc9eZKqdpl4buAouO08Tnfla+DY5lh8IBMgxegIL+sd+pjeTpWzbNHG8eq ERe2qf1jAF0qg0oy1ewjMPgB3WfXpEJoIXof3XiYqzpdUBgK0dkJDkAXH+J6RqNY m/1mNClAzHQralykpvXVbAa65naCMrQubUr9wtp9a6XiAXELD638cT5N/JxZ3VWN Wi20DA== 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=fm1; bh=He3civzFVKVIQ+02/Z4KOj0SfLojdKl9JN9T7X9EN iM=; b=OCgFMjuPcxzsJSF0eA7wTkJ2YwXwml9qpFDPvZlN3X2iclk5JLodIhzUu 8XRX92+mPC2j2Vx+Iqfyvxfu2Q/bpWrUoHIriJbBM0l7hHFug0JLu60obxzh7eUX DZUA4jShAsPFbKPdUXxFMQMgKirK50bffuJZRTZdTEzm1U894T0qZ98KJr5p3Ky1 OyVwcAo8KlLTs7r83uuewLc5FdzkBbVZjLM7/r5+aRc/wirZy/dD6RNPt+kC7sJQ CiTvcWaYg4A6tRpMP/D4mlFavuKPZEy6B5+72dkqKWDDXCieoVKv8PBqgueYhIsR k1o9Lt9feHuNT9MqPkTQx7efW8SNw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledruddvgdejlecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucggtf frrghtthgvrhhnpedugefgvdefudfftdefgeelgffhueekgfffhfeujedtteeutdejueei iedvffegheenucfkphepjeejrddufeegrddvtdefrddukeegnecuvehluhhsthgvrhfuih iivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhho nhdrnhgvth X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id F25E71080069; Wed, 20 Jan 2021 10:41:20 -0500 (EST) From: Thomas Monjalon To: dodji@redhat.com Cc: Ray Kinsella , Neil Horman , Akhil Goyal , Konstantin Ananyev , Abhinandan Gujjar , dev@dpdk.org, david.marchand@redhat.com Date: Wed, 20 Jan 2021 16:41:18 +0100 Message-ID: <15493004.lGub55pDpk@thomas> In-Reply-To: <20210120142558.4120552-1-mdr@ashroe.eu> References: <20210120142558.4120552-1-mdr@ashroe.eu> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v1] devtools: update abi ignore for cryptodev X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 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" Question to an expert, Dodji, We have this structure: struct rte_cryptodev { lot of fields... uint8_t attached : 1; } __rte_cache_aligned; Because of the cache alignment, there is enough padding in the struct (no matter the size of the cache line) for adding two more pointers: struct rte_cryptodev { lot of fields... uint8_t attached : 1; struct rte_cryptodev_cb_rcu *enq_cbs; struct rte_cryptodev_cb_rcu *deq_cbs; } __rte_cache_aligned; We checked manually that the ABI is still compatible. Then I've added (quickly) a libabigail exception rule: [suppress_type] name = rte_cryptodev has_data_member_inserted_between = {0, 1023} Now we want to improve this rule to restrict the offsets to the padding at the end of the struct only, so we keep forbidding changes in existing fields, and forbidding additions further the current struct size. Is this new rule good? has_data_member_inserted_between = {offset_after(attached), end} Do you confirm that the keyword "end" means the old reference size? What else do we need to check for adding a new field in a padding? Thank you 20/01/2021 15:25, Ray Kinsella: > Update the ignore entry for crytodev to use named fields instead of > bit positions. > > Fixes: 1c3ffb9559 > > Signed-off-by: Ray Kinsella > --- > devtools/libabigail.abignore | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/devtools/libabigail.abignore b/devtools/libabigail.abignore > index 1dc84fa74b..1f17fbed58 100644 > --- a/devtools/libabigail.abignore > +++ b/devtools/libabigail.abignore > @@ -15,4 +15,4 @@ > ; Ignore fields inserted in cacheline boundary of rte_cryptodev > [suppress_type] > name = rte_cryptodev > - has_data_member_inserted_between = {0, 1023} > + has_data_member_inserted_between = {offset_after(attached), end}