patches for DPDK stable branches
 help / color / mirror / Atom feed
From: Ferruh Yigit <ferruh.yigit@intel.com>
To: Gavin Hu <gavin.hu@arm.com>, dev@dpdk.org
Cc: 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 <olivier.matz@6wind.com>,
	Konstantin Ananyev <konstantin.ananyev@intel.com>,
	Andrew Rybchenko <arybchenko@solarflare.com>
Subject: Re: [dpdk-stable] [dpdk-dev] [PATCH v2] mbuf: replace zero-length marker with unnamed union
Date: Mon, 9 Mar 2020 08:55:05 +0000	[thread overview]
Message-ID: <4135ab73-75d3-421a-264d-2951fc096133@intel.com> (raw)
In-Reply-To: <20200307155629.45021-1-gavin.hu@arm.com>

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 <gavin.hu@arm.com>
> ---
> v2: 
> * change 'uint64_t rearm_data' to 'uint_64_t rearm_data[1]' to fix
>   the SFC PMD compiling error on x86. <Kevin Traynor>
> ---
>  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?

  reply	other threads:[~2020-03-09  8:55 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-03 16:27 [dpdk-stable] [PATCH v1] " Gavin Hu
2020-03-04 12:32 ` [dpdk-stable] [dpdk-dev] " Kevin Traynor
2020-03-07 14:52   ` Gavin Hu
2020-03-07 15:56 ` [dpdk-stable] [PATCH v2] " Gavin Hu
2020-03-09  8:55   ` Ferruh Yigit [this message]
2020-03-09  9:45     ` [dpdk-stable] [dpdk-dev] " Gavin Hu
2020-03-09 11:29       ` Ferruh Yigit
2020-03-09 13:30         ` Morten Brørup
2020-03-09 14:16           ` Richardson, Bruce
2020-03-09 14:50             ` [dpdk-stable] [dpdk-dev] [PATCH v2] mbuf: replace zero-length markerwith " Morten Brørup
2020-03-11  7:50           ` [dpdk-stable] [dpdk-dev] [PATCH v2] mbuf: replace zero-length marker with " Gavin Hu
2020-03-11  9:04             ` Morten Brørup
2020-03-11 12:07               ` Bruce Richardson
2020-03-13  7:36                 ` Gavin Hu
2020-03-13  9:22                 ` Gavin Hu
2020-04-07 17:13                   ` Kevin Traynor
2020-04-08 15:04                     ` Gavin Hu
2020-04-08 15:22                       ` David Marchand
2020-04-09  9:48                         ` Gavin Hu
2020-04-09 10:49                           ` Thomas Monjalon
2020-04-09 16:09                             ` Ray Kinsella
2020-04-11  2:50                             ` Gavin Hu
2020-05-14 13:24                         ` Kevin Traynor
2020-03-09 15:47     ` Stephen Hemminger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4135ab73-75d3-421a-264d-2951fc096133@intel.com \
    --to=ferruh.yigit@intel.com \
    --cc=arybchenko@solarflare.com \
    --cc=david.marchand@redhat.com \
    --cc=dev@dpdk.org \
    --cc=gavin.hu@arm.com \
    --cc=honnappa.nagarahalli@arm.com \
    --cc=jerinj@marvell.com \
    --cc=joyce.kong@arm.com \
    --cc=konstantin.ananyev@intel.com \
    --cc=ktraynor@redhat.com \
    --cc=nd@arm.com \
    --cc=olivier.matz@6wind.com \
    --cc=phil.yang@arm.com \
    --cc=ruifeng.wang@arm.com \
    --cc=stable@dpdk.org \
    --cc=thomas@monjalon.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).