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 62A0BA09E4; Thu, 21 Jan 2021 16:58:10 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 099F4140D20; Thu, 21 Jan 2021 16:58:10 +0100 (CET) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by mails.dpdk.org (Postfix) with ESMTP id D372F140D1B for ; Thu, 21 Jan 2021 16:58:07 +0100 (CET) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 501B65C0199; Thu, 21 Jan 2021 10:58:07 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Thu, 21 Jan 2021 10:58:07 -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= +/VYGLTQIH4uXtMK4EzzRePNZ7ImSZ0Kja1ot3VcvMA=; b=KM9XNmW/uANVUzMp yfDxBJ6L0SeEzl5Ls50wuHZDdjWYlGkvxymP+3UI8mOdXtLnQtPGxuTf/F/IAoWu Pd0V8biwQ8ZpmxVFbJMYKWO/CkbCx7C5yNfK5WuNL1iZ7U2N6LOBUFddwAcbjM/b HBluyQg5vV6VBWPYRxfhjWZTvJBb1jO6Y06qidccjyExUDjBfOu7Yf4x31vPPfl8 4WQ7TW7f/KjZsINbhML5t0y+4hChIDPISmg2ZhbESag1qSNazXoJE0BhgltHBR7C baMY9C6Ajn1j1Ta/NmWfDkZt2uu7p28NMegsboPtX2lS4pi3UOGcJT4oppc45ynN 9CPmnQ== 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=+/VYGLTQIH4uXtMK4EzzRePNZ7ImSZ0Kja1ot3Vcv MA=; b=aWMKxBI2HzuCZNu6qx8WyysQcXX79Zs9AsGiW3HZZkqupMVi6MdLRGLoE xP/fu200TmaqCFtLRLtUUOurwOhQiB0/Y4UsK3EEP/+uT5v+6iY80AsuM+YbjhCk bnay728XHqlScEd9eahbSQ3rGKFLYMcZHswkZsBXAIsSj+jXJxA06a7b6GfQdvN2 pB8aiLHK3S5iPvIeVWN462LF6lCuVr2rMzbGf6tzX2YOIZK5u1jKQQQZ0y7yfRQx aI82hgbPBpJZyPyAEDsgB3crB/g4Hc5ncpoypZop3rXqT4Zs1kZvZ33L0EIdOTqm 4tcJZoIc7Ek4jYBfb5eN96/w2d0Gw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrudeggdekhecutefuodetggdotefrodftvf 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 8834D108005F; Thu, 21 Jan 2021 10:58:05 -0500 (EST) From: Thomas Monjalon To: Dodji Seketeli Cc: Ray Kinsella , Neil Horman , Akhil Goyal , Konstantin Ananyev , Abhinandan Gujjar , dev@dpdk.org, david.marchand@redhat.com Date: Thu, 21 Jan 2021 16:58:04 +0100 Message-ID: <2579086.B9NNOlTe4A@thomas> In-Reply-To: <86sg6uiamx.fsf@redhat.com> References: <20210120142558.4120552-1-mdr@ashroe.eu> <15493004.lGub55pDpk@thomas> <86sg6uiamx.fsf@redhat.com> 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" 21/01/2021 16:15, Dodji Seketeli: > Hello Thomas and others, > > Thomas Monjalon writes: > > > Question to an expert, Dodji, > > Thanks for the kind words, but I am not an expert in anything, sadly. I > am just trying to keep learning about these things ;-) > > > 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. > > Right. > > I am curious, but normally, libabigail should raise the addition of > structures, but then it'll tell you that there was no size or offset > change between the two structures. If it doesn't, then that's a bug. I > hope it does :-) Yes it was raising a problem, that's why we are adding a rule. > > 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} > > > Yes, this rule should do what you think it says. > > > Do you confirm that the keyword "end" means the old reference size? > > Yes I do. > > > > What else do we need to check for adding a new field in a padding? > > Actually, that rule will work independantly of it there is enough > padding or not. It'll shut down the change report, even if the added > data exceeds the padding. I don't understand why. If "end" means the old reference size, then addition after the old size should be reported, isn't it? > You just made me think of an idea of a new feature there. > > Maybe we'd need a new property for the [suppress_type] directive that > would suppress changes only if said changes don't modify the size of the > type or any offset of any member of the type? > > Maybe something like: > > [suppress_type] > ; lots of properties can go here. > > ; ... > > ; If the type has any size or offset change > ; then this suppression directive will fail > ; and the change report will be emitted > has_no_size_or_offset_change > > Would that be useful to you in this case, > > Cheers,