From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 5B5A4A054B; Thu, 16 Jul 2020 15:21:26 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id EF5DE1D51E; Thu, 16 Jul 2020 15:21:24 +0200 (CEST) Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.120]) by dpdk.org (Postfix) with ESMTP id A18B81D453 for ; Thu, 16 Jul 2020 15:21:23 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1594905681; 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=39D6WrTZRgek3G+paVIQhi5pjmjQyn89DxYuiEv5384=; b=LwRphbUfMpzT6THUVtmwzI0ToZheQhkkXiruLgVv+KFpo0hAGYii85wqTVwCMwgqpVHORd 9VqQbnMJ2R9oi/n25/Dat+D0dYilknsLw1NV3VKAugoG+8T/rMmfztHmzQzfb+BCOUIajX l5d1w/j/rQKjkf+F5j5eAEDrpwsp2/4= Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-310-H8Rp6kn4NN6mcY4x6mjDnw-1; Thu, 16 Jul 2020 09:21:06 -0400 X-MC-Unique: H8Rp6kn4NN6mcY4x6mjDnw-1 Received: by mail-wr1-f71.google.com with SMTP id v3so5515526wrq.10 for ; Thu, 16 Jul 2020 06:21:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:organization:references:date :in-reply-to:message-id:user-agent:mime-version; bh=39D6WrTZRgek3G+paVIQhi5pjmjQyn89DxYuiEv5384=; b=Y+lSUuTy5FUw7w4X+hodrdUN9DbKebQUeg0vaCK34qmLll4t1hVdIlYSnDSzX9mRch 4Ho4srmLdm2OHYKZwWdYyInEnIHkGI2USU/tC1i4BYpiKcqd9SRCNPHeXjAL+Qcs4ohp UDQXqJ3EPoTjjCMg90jPBm7S9cpsJRSJUk1zkPWWckvV419lJJPyNTlEoEzZPNrP/cFs Xgw/pmiCjnnoiTKa0r7cqdwbBLiTHgc3sjPQTyfhOT7EcwszkWABTLwTpi1s5IWJqN3J 8HoatEqv6J8hTAfs8dBZftaK7uuomS1t0WJ+0q0NrTeWfJ+Umx3gPDI2x2/OiVwdXogu tWEQ== X-Gm-Message-State: AOAM533aE98Grf5Gl1gucGAKIrQJ+Mq+Ttk/zcWMDACfNi4rnoOKj1C7 GL2b3DbXiLWkCPR/D+vYwF2C6I2Dw2RgBwN3AccrSXreujfSWhwb5fVsWsFJSgc7qs4E6PkQJH2 yBiQ= X-Received: by 2002:adf:bc41:: with SMTP id a1mr4903052wrh.186.1594905663053; Thu, 16 Jul 2020 06:21:03 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyX2qnD961zBDXsj2vMZWUziHhQ4GCQcbGFr2slY3S7nACNPh+b8e3Y9dlwxaygndcwHTivmQ== X-Received: by 2002:adf:bc41:: with SMTP id a1mr4903023wrh.186.1594905662685; Thu, 16 Jul 2020 06:21:02 -0700 (PDT) Received: from localhost (91-166-131-130.subs.proxad.net. [91.166.131.130]) by smtp.gmail.com with ESMTPSA id 92sm9981371wrr.96.2020.07.16.06.21.00 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Jul 2020 06:21:01 -0700 (PDT) Received: by localhost (Postfix, from userid 1000) id C5F50180097E; Thu, 16 Jul 2020 15:20:59 +0200 (CEST) From: Dodji Seketeli To: David Marchand Cc: Phil Yang , Olivier Matz , Ray Kinsella , dev , Stephen Hemminger , David Christensen , Honnappa Nagarahalli , Ruifeng Wang , nd , Aaron Conole Organization: Red Hat / France References: <1594289442-18594-1-git-send-email-phil.yang@arm.com> <1594310331-23345-1-git-send-email-phil.yang@arm.com> X-Operating-System: Red Hat Enterprise Linux Workstation 7.8 Beta X-URL: http://www.redhat.com Date: Thu, 16 Jul 2020 15:20:59 +0200 In-Reply-To: (David Marchand's message of "Thu, 16 Jul 2020 13:30:09 +0200") Message-ID: <87h7u7k344.fsf@redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain Subject: Re: [dpdk-dev] [PATCH v4 1/2] mbuf: use C11 atomic built-ins for refcnt operations X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 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" Hello, David Marchand writes: [...] On Thu, Jul 16, 2020 at 6:16 AM Phil Yang wrote: >> > >> > v4 does not pass the checks (in both my env, and Travis). >> > https://travis-ci.com/github/ovsrobot/dpdk/jobs/359393389#L2405 >> >> I think we need an exception in 'libabigail.abignore' for this change. >> Is that OK with you? David Marchand writes: [...] > Testing the series with libabigail 1.7.0: > > Functions changes summary: 0 Removed, 1 Changed (6 filtered out), 0 > Added functions > Variables changes summary: 0 Removed, 0 Changed, 0 Added variable [...] > in pointed to type 'struct rte_mbuf_ext_shared_info' at rte_mbuf_core.h:679:1: > type size hasn't changed > 1 data member change: > data member rte_atomic16_t > rte_mbuf_ext_shared_info::refcnt_atomic at offset 128 (in bits) became > anonymous data member 'union {rte_atomic16_t refcnt_atomic; uint16_t refcnt;}' [...] > We will have no other update on mbuf for 20.08, so the following rule > can do the job for 20.08 and we will remove it in 20.11. > > diff --git a/devtools/libabigail.abignore b/devtools/libabigail.abignore > index daa4631bf..b35f91257 100644 > --- a/devtools/libabigail.abignore > +++ b/devtools/libabigail.abignore > @@ -52,6 +52,10 @@ > [suppress_type] > type_kind = struct > name = rte_epoll_event > +; Ignore updates of rte_mbuf_ext_shared_info > +[suppress_type] > + type_kind = struct > + name = rte_mbuf_ext_shared_info [...] > Olivier, Dodji, Ray? Yes, that should work. Just for the sake of precision, I'd like to say that in the coming 1.8 version of libabigail, this change won't be reported by the tooling as a problem anymore. This is thanks to David filing the feature request https://sourceware.org/bugzilla/show_bug.cgi?id=25661 a while ago. Until then, I understand that the current tooling needs to work with libabigail 1.6. So maybe a more specific suppression rule (that you could still remove for the 20.11 stable branch) could look like: [suppress_type] name = rte_mbuf_ext_shared_info has_data_member_inserted_between = {offset_of(refcnt_atomic), offset_of(refcnt_atomic)} It's a "hack" that will only suppress change reports on the rte_mbuf_ext_shared_info type if: 1/ it it has a data member inserted at the offset of its data member 'refcnt_atomic', AND 2/ the size of rte_mbuf_ext_shared_info doesn't change. There are cases where this won't work, though. But it might work for this case. If it does, then great. I think it'd be a better solution than a blanket suppression of all the changes on the type. Cheers, -- Dodji