Hi Kevin, > -----Original Message----- > From: Kevin Traynor <ktray...@redhat.com> > Sent: Wednesday, March 4, 2020 8:33 PM > To: Gavin Hu <gavin...@arm.com>; dev@dpdk.org > Cc: nd <n...@arm.com>; tho...@monjalon.net; > david.march...@redhat.com; jer...@marvell.com; Honnappa Nagarahalli > <honnappa.nagaraha...@arm.com>; Ruifeng Wang > <ruifeng.w...@arm.com>; Phil Yang <phil.y...@arm.com>; > sta...@dpdk.org > Subject: Re: [dpdk-dev] [PATCH v1] mbuf: replace zero-length marker with > unnamed union > > On 03/03/2020 16:27, Gavin Hu wrote: > > gcc 10.0.1 reports: error: array subscript 0 is outside the bounds of an > > interior zero-length array 'RTE_MARKER64' {aka 'long unsigned int[0]'} > > [-Werror=zero-length-bounds] 310 | *(uint64_t *)(&mbuf->rearm_data) = > > val; > > > > 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: sta...@dpdk.org > > > > Signed-off-by: Gavin Hu <gavin...@arm.com> > > --- > > 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..5390ddcfa 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;
To address this historical issue, how about changing this line to uint64_t rearm_data[1]? > > + RTE_STD_C11 > > + struct { > > + 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 { > > + /**< Atomically accessed refcnt */ > > + rte_atomic16_t refcnt_atomic; > > + /** Non-atomically accessed refcnt > */ > > + uint16_t refcnt; > > + }; > > + uint16_t nb_segs; /**< Number of segments. */ > > > > - /** Input port (16 bits to support more than 256 virtual ports). > > - * The event eth Tx adapter uses this field to specify the output port. > > - */ > > - uint16_t port; > > + /** Input port (16 bits to support more than 256 > > + * virtual ports). The event eth Tx adapter uses this > > + * field to specify the output port. > > + */ > > + uint16_t port; > > + }; > > + }; > > > > uint64_t ol_flags; /**< Offload features. */ > > > > > > > Hi Gavin, this causes some errors on x86: > > # gcc --version | head -1 > gcc (GCC) 10.0.1 20200216 (Red Hat 10.0.1-0.8) > > > In file included from > ../lib/librte_eal/common/include/arch/x86/rte_byteorder.h:13, > from ../drivers/net/sfc/sfc_ef10_rx.c:14: > ../drivers/net/sfc/sfc_ef10_rx.c: In function 'sfc_ef10_rx_process_event': > ../drivers/net/sfc/sfc_ef10_rx.c:309:39: error: subscripted value is > neither array nor pointer nor vector > 309 | RTE_BUILD_BUG_ON(sizeof(m->rearm_data[0]) != > sizeof(rxq->rearm_data)); > | ^ > ../lib/librte_eal/common/include/rte_common.h:292:65: note: in > definition of macro 'RTE_BUILD_BUG_ON' > 292 | #define RTE_BUILD_BUG_ON(condition) ((void)sizeof(char[1 - > 2*!!(condition)])) > | > ^~~~~~~~~ > ../drivers/net/sfc/sfc_ef10_rx.c:310:15: error: subscripted value is > neither array nor pointer nor vector > 310 | m->rearm_data[0] = rxq->rearm_data; > |