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 9BD7EA0C4A; Wed, 7 Jul 2021 11:59:48 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 82FAA4135E; Wed, 7 Jul 2021 11:59:48 +0200 (CEST) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) by mails.dpdk.org (Postfix) with ESMTP id 8A45E406B4 for ; Wed, 7 Jul 2021 11:59:47 +0200 (CEST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id B194232007F0; Wed, 7 Jul 2021 05:59:43 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Wed, 07 Jul 2021 05:59:44 -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=fm1; bh= 4ngYvHVb7xzipGrHPDveykpeh9At0gUySwsA10nE720=; b=M/7fgZDl34tUc5dy PDQY/ay8EnXBiLThUC3dpXzdfPLO23q0BPqIFZVF0jkd/Uo3wYBj5DtjGrPqkSt4 8Zqx9SxNi08XJcH5hKqKBPb5XaDs0p3s7I5h4M2JnWZo++Wwvmom8u5d/B/BXWGA JB3wb+JnwUY3jXgijpuBU6vrim0qLUIA3skPNyYXhJ/W8jE/3BawKJUNPhRsFzw9 32JlPLf20lGsKpWUtMeCnohhOhTlVG3siGYLifFFFJwXkdl6T1BywZ65+F/vphG1 CjTpMcf4aQmEj5vq4WDASgrrtahWSHYlCvmZ22seElkLX69XScHOdlQ8D/mvn8d9 anbf6g== 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=fm3; bh=4ngYvHVb7xzipGrHPDveykpeh9At0gUySwsA10nE7 20=; b=VdCRLaazd2ZPW/QA95ywDI0vl8UzPW39UIZehOTwdAdyblxbhW5PV2VYl +toLIYG8WCTbU/fV9h1MOffURxM+HkYSM/WJ3aanO3+kWK1cX9z5vpkvGMl1LNz+ j/GYTn4SDKr7SNEYHioR73LaT1gBB51X+9ATqRntf08S2ZJg+Z1t2lpGN9OOyiCj YvrE1lnpXAXNd5+MmPWaiOdbf1fXACHlnlsMPxEUcprVL61irHf9ppiXel8qaCte 0FgieAsOKQWXoiW6ASmIKuVB/uct4CfyTmQw6Xaq3Rw3vtB9fD7hsMGWh4kkBkRY gtbcQwjnNsUGxMeE9epY2VrKPzeng== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrtddvgddvvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucggtf frrghtthgvrhhnpeffvdduvdehhfetvedtuefftdeludeuhfefueejheetgeevveeiffdv tdffteeuvdenucffohhmrghinhepshhouhhrtggvfigrrhgvrdhorhhgnecuvehluhhsth gvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhn jhgrlhhonhdrnhgvth X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 7 Jul 2021 05:59:41 -0400 (EDT) From: Thomas Monjalon To: Andrew Rybchenko , David Marchand Cc: Dodji Seketeli , Huisong Li , dev , "Yigit, Ferruh" , "Ananyev, Konstantin" , Ray Kinsella Date: Wed, 07 Jul 2021 11:59:39 +0200 Message-ID: <25012025.yGfkWu0M9X@thomas> In-Reply-To: References: <1620460836-38506-1-git-send-email-lihuisong@huawei.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH V2] ethdev: add dev configured flag 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" 07/07/2021 11:36, David Marchand: > On Wed, Jul 7, 2021 at 10:23 AM Andrew Rybchenko > wrote: > > > > On 7/7/21 10:39 AM, David Marchand wrote: > > > On Tue, Jul 6, 2021 at 10:36 AM Andrew Rybchenko > > > wrote: > > >> > > >> @David, could you take a look at the ABI breakage warnings for > > >> the patch. May we ignore it since ABI looks backward > > >> compatible? Or should be marked as a minor change ABI > > >> which is backward compatible with DPDK_21? > > > > > > The whole eth_dev_shared_data area has always been reset to 0 at the > > > first port allocation in a dpdk application life. > > > Subsequent calls to rte_eth_dev_release_port() reset every port > > > eth_dev->data to 0. > > > > > > This bit flag is added in a hole of the structure, and it is > > > set/manipulated internally of ethdev. > > > > > > So unless the application was doing something nasty like highjacking > > > this empty hole in the structure, I see no problem with the change wrt > > > ABI. > > > > > > > > > I wonder if libabigail is too strict on this report. > > > Or maybe there is some extreme consideration on what a compiler could > > > do about this hole... > > > > I was wondering if it could be any specifics related to big- > > little endian vs bit fields placement, but throw the idea > > away... > > After some discussion offlist with (fairly busy ;-)) Dodji, the report > here is a good warning. > > But it looks we have an issue with libabigail not properly computing > bitfields offsets. > I just opened a bz for tracking > https://sourceware.org/bugzilla/show_bug.cgi?id=28060 > > This is problematic, as the following rule does not work: > > +; Ignore bitfields added in rte_eth_dev_data hole > +[suppress_type] > + name = rte_eth_dev_data > + has_data_member_inserted_between = {offset_after(lro), > offset_of(rx_queue_state)} > > On the other hand, a (wrong) rule with "has_data_member_inserted_at = > 2" (2 being the wrong offset you can read in abidiff output) works. > > This might force us to waive all changes to rte_eth_dev_data... not > that I am happy about it. We are not going to do other changes until 21.11, so it could be fine.