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 07CB2A0C4A; Wed, 7 Jul 2021 11:37:04 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 7DA34406FF; Wed, 7 Jul 2021 11:37:04 +0200 (CEST) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mails.dpdk.org (Postfix) with ESMTP id 24A66406B4 for ; Wed, 7 Jul 2021 11:37:03 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1625650622; 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: in-reply-to:in-reply-to:references:references; bh=H3RHGDNSTMxtPfhnteJcSQcxcH6vzs9RNKwgIPT+DT4=; b=Dww90xyyTOdK1oys5OYyEbPXNZOwvZkimWENFAR1Zm6ZdJcHnhGi8EMOR2kDY77Dv5HK6+ Aw5BQBDhOdJoIPjCDJdnApOEaXoYNBtx+vdc/xlTWcOG4wDq4ZGv7T6Ml+FZ6fh4m3cDe+ UY31aF6PGaEpgjtiOYIqb8dbBW3kYqI= Received: from mail-ua1-f72.google.com (mail-ua1-f72.google.com [209.85.222.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-32-WJUGh7m3PIC6zYo2mapWpw-1; Wed, 07 Jul 2021 05:36:59 -0400 X-MC-Unique: WJUGh7m3PIC6zYo2mapWpw-1 Received: by mail-ua1-f72.google.com with SMTP id d7-20020ab066c70000b0290291b95bf303so644174uaq.16 for ; Wed, 07 Jul 2021 02:36:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=H3RHGDNSTMxtPfhnteJcSQcxcH6vzs9RNKwgIPT+DT4=; b=DWNykXC/V9PP0ONR+eIFZwBM8JKt0CRGsJ4LuYclk6loaTdlibM9Y7Ncfxk2B0J8Mc Byv6IF72nIzuQKpqKuUeOc44maMs5YMlTTg8IbZ91t9T3ibNO9a/B25bk0eKJ10mC55I RRj7tLLsud+XclO0FY6v47f/20F+VlE6OyOnw6HYQCbX//TzN0ITEA5xYH2T4VY08jQ1 x1rhsF1TfFzIVAW3sDbtSOkQ6POK7SumGKZGHNFZ+ViUJMtriNLyAaMMLXnaLLTLDpJO iI11paodl06TvNECy0pRvy4rSkoKu83IyudUN+b2g0/QUbmEvdYjLh+R3KzfgSucP+vr ejxQ== X-Gm-Message-State: AOAM530x2JWhgMLvTMoJ0naz0ARvqJqQLqF5CD1dROnZ9GvZCaQn1BNl 8S7HCLtoQ1w+CiYRXwrbuNUm3JkpkcqTDWv8lhu8SWNomcAMPirQkEobIGD3WG7GHbBHZ7AppDr arpQkLQquUTmJ0H4kE5w= X-Received: by 2002:a05:6102:3196:: with SMTP id c22mr12215517vsh.27.1625650619414; Wed, 07 Jul 2021 02:36:59 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyZ3vwJ63w5MKGPDEgIk0weU8W3TRbI8swE+5zDx+QkW03gbTTzWyM7D0Yfz3iModL1zszkgHd3ejdcFvidZLM= X-Received: by 2002:a05:6102:3196:: with SMTP id c22mr12215503vsh.27.1625650619188; Wed, 07 Jul 2021 02:36:59 -0700 (PDT) MIME-Version: 1.0 References: <1620460836-38506-1-git-send-email-lihuisong@huawei.com> <1625544608-30590-1-git-send-email-lihuisong@huawei.com> <966ec9cd-9142-b40d-b059-b63c8ece66bf@oktetlabs.ru> In-Reply-To: From: David Marchand Date: Wed, 7 Jul 2021 11:36:47 +0200 Message-ID: To: Andrew Rybchenko Cc: Dodji Seketeli , Huisong Li , dev , Thomas Monjalon , "Yigit, Ferruh" , "Ananyev, Konstantin" , Ray Kinsella Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=dmarchan@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" 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" 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. -- David Marchand