[PATCH v11 2/3] net/macb: add NEON vectorized Rx/Tx

[Stephen Hemminger]

On Tue, 28 Oct 2025 08:32:30 +0000
Wencheng Li <liwencheng at phytium.com.cn> wrote:

> +static inline uint8x8_t macb_mbuf_initializer(struct macb_rx_queue *rxq)
> +{
> +	uint64x1_t mbuf_initializer;
> +	uint8x8_t rearm_data_vec;
> +	volatile struct rte_mbuf mbuf = {
> +		.buf_addr = 0,
> +		.data_off = RTE_PKTMBUF_HEADROOM + MACB_RX_DATA_OFFSET,
> +		.nb_segs  = 1,
> +		.port     = rxq->port_id,
> +	};
> +
> +	mbuf_initializer = vdup_n_u64(0);
> +	rte_atomic_store_explicit(&mbuf.refcnt, 1, rte_memory_order_relaxed);
> +
> +	/* prevent compiler reordering: rearm_data covers previous fields */
> +	rte_compiler_barrier();
> +	mbuf_initializer =
> +		vset_lane_u64(*(volatile uint64_t *)(&mbuf.rearm_data), mbuf_initializer, 0);

Why is a variable on stack marked volatile.
My understanding is that volatile is for cases where data is accessed
from two contexts (threads or signals). This is not the case for on-stack
variable.

The compiler barrier should be enough protection to prevent reordering.
And setting same variable twice seems wrong as well.