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 10494A052E; Mon, 9 Mar 2020 16:47:44 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 797A31C0AC; Mon, 9 Mar 2020 16:47:43 +0100 (CET) Received: from mail-pg1-f193.google.com (mail-pg1-f193.google.com [209.85.215.193]) by dpdk.org (Postfix) with ESMTP id 639FC1C07E for ; Mon, 9 Mar 2020 16:47:42 +0100 (CET) Received: by mail-pg1-f193.google.com with SMTP id z12so4878389pgl.4 for ; Mon, 09 Mar 2020 08:47:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=/jhYdSVM90VPew8RaKJbddD2ZPmT/q1mpirIBctfq9M=; b=RQw0E+uqg9mk7zjl8CwCv3YpgJfe7U+uEDYUJeS+TEBL7/zhiIx/CvJa/6vqDkmJSH 5hAoKT3FUylPNJFz/vMROZX1oHJilqbhVgqOkN/wEvU872eRoX8WBYcyo+D1rj1RwV5t 4MZ9Vkf+FMZSOgLXTmfKy7o+ZbtPLc6O2poocSI9ZEmXsxsB+Jsi6b9ekgemYEJQXFZg GrRw5smsnItYOLULq8KG6xycf7ORrSUy8SyAmhozCp4ZFVjC9aiJ4+GyKjCaM2tpM6DY iSzvjwPVAdQCu09vONT97TvvoSFn9pK/liA0fUz775Shiu8N2R2ue1pKfBiDebf+wrHC PKrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=/jhYdSVM90VPew8RaKJbddD2ZPmT/q1mpirIBctfq9M=; b=Y6a9p1Bbi+sMiqsDS6WIwxpBeBIB5rgdBcGtfu0irFN1re2TNkcnU1oxXEBxlWc1Le BuhRRbUy20Nz3HO8qlemKaeMCIv9VQX9Ppgb9SD0mE8QEVPBZ+PAIdOubc9Hci+2/WQB Z/jtTF5ahn2ifw+uaxiOC92R2mhTxX6JXn77yB7TWcb/0lcJfpvdrDQIjYoSq8YGcpQd +yQNDTFFaVjpi7qBOYBiNy8i6xuKohLLfumOHFKDVe13g5i2+lQmnySgnHz9SkSxo8tY Y9mB1MCinu2ufjZJFyYM1phk/6ZnZosbDJhoAqg4cjn4VbXHyJ9U0A78ml5fpnWi4XNn tRVg== X-Gm-Message-State: ANhLgQ00fhJXhnLMIQUsNnmkN/ABcwkjSRYAwR2mGl8z91ydXcTyyCWW 65EmRV1R0zWZnsJW353Z3tHCVw== X-Google-Smtp-Source: ADFU+vvsQToWqdMncLb9J76UpAdvxlQPN+kcXeSBJkil3EDcqspgqXvTM0c7oyUKV3AAt40eHi1aXA== X-Received: by 2002:a63:fc62:: with SMTP id r34mr17335607pgk.437.1583768861514; Mon, 09 Mar 2020 08:47:41 -0700 (PDT) Received: from hermes.lan (204-195-22-127.wavecable.com. [204.195.22.127]) by smtp.gmail.com with ESMTPSA id x2sm43356079pge.2.2020.03.09.08.47.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 09 Mar 2020 08:47:41 -0700 (PDT) Date: Mon, 9 Mar 2020 08:47:32 -0700 From: Stephen Hemminger To: Ferruh Yigit Cc: Gavin Hu , dev@dpdk.org, nd@arm.com, david.marchand@redhat.com, thomas@monjalon.net, ktraynor@redhat.com, jerinj@marvell.com, honnappa.nagarahalli@arm.com, ruifeng.wang@arm.com, phil.yang@arm.com, joyce.kong@arm.com, stable@dpdk.org, Olivier MATZ , Konstantin Ananyev , Andrew Rybchenko Message-ID: <20200309084732.3f845eee@hermes.lan> In-Reply-To: <4135ab73-75d3-421a-264d-2951fc096133@intel.com> References: <20200303162728.93744-1-gavin.hu@arm.com> <20200307155629.45021-1-gavin.hu@arm.com> <4135ab73-75d3-421a-264d-2951fc096133@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v2] mbuf: replace zero-length marker with unnamed union 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" On Mon, 9 Mar 2020 08:55:05 +0000 Ferruh Yigit wrote: > On 3/7/2020 3:56 PM, Gavin Hu wrote: > > Declaring zero-length arrays in other contexts, including as interior > > members of structure objects or as non-member objects, is discouraged. > > Accessing elements of zero-length arrays declared in such contexts is > > undefined and may be diagnosed.[1] > > > > Fix by using unnamed union and struct. > > > > https://bugs.dpdk.org/show_bug.cgi?id=396 > > > > Bugzilla ID: 396 > > > > [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html > > > > Fixes: 3e6181b07038 ("mbuf: use structure marker from EAL") > > Cc: stable@dpdk.org > > > > Signed-off-by: Gavin Hu > > --- > > v2: > > * change 'uint64_t rearm_data' to 'uint_64_t rearm_data[1]' to fix > > the SFC PMD compiling error on x86. > > --- > > lib/librte_mbuf/rte_mbuf_core.h | 54 +++++++++++++++++++-------------- > > 1 file changed, 32 insertions(+), 22 deletions(-) > > > > diff --git a/lib/librte_mbuf/rte_mbuf_core.h b/lib/librte_mbuf/rte_mbuf_core.h > > index b9a59c879..34cb152e2 100644 > > --- a/lib/librte_mbuf/rte_mbuf_core.h > > +++ b/lib/librte_mbuf/rte_mbuf_core.h > > @@ -480,31 +480,41 @@ struct rte_mbuf { > > rte_iova_t buf_physaddr; /**< deprecated */ > > } __rte_aligned(sizeof(rte_iova_t)); > > > > - /* next 8 bytes are initialised on RX descriptor rearm */ > > - RTE_MARKER64 rearm_data; > > - uint16_t data_off; > > - > > - /** > > - * Reference counter. Its size should at least equal to the size > > - * of port field (16 bits), to support zero-copy broadcast. > > - * It should only be accessed using the following functions: > > - * rte_mbuf_refcnt_update(), rte_mbuf_refcnt_read(), and > > - * rte_mbuf_refcnt_set(). The functionality of these functions (atomic, > > - * or non-atomic) is controlled by the CONFIG_RTE_MBUF_REFCNT_ATOMIC > > - * config option. > > - */ > > RTE_STD_C11 > > union { > > - rte_atomic16_t refcnt_atomic; /**< Atomically accessed refcnt */ > > - /** Non-atomically accessed refcnt */ > > - uint16_t refcnt; > > - }; > > - uint16_t nb_segs; /**< Number of segments. */ > > + /* next 8 bytes are initialised on RX descriptor rearm */ > > + uint64_t rearm_data[1]; > We are using zero length array as markers only and know what we are doing with them, > what would you think disabling the warning instead of increasing the complexity > in mbuf struct? No to disabling warnings. Or get rid of the markers all together, the usage is awkward already.