[PATCH v3 2/5] mbuf: add second dynamic field member for VA only build

[Thomas Monjalon]

21/09/2022 15:56, Shijith Thotton:
> mbuf physical address field is not used in builds which only uses VA. It
> is used to expand the dynamic field area.
> 
> Signed-off-by: Shijith Thotton <sthotton at marvell.com>

We cannot condition the use of the dynamic field.
I think it is enough justification to reject this patch.

And about adding a compilation option for IOVA in the first patch of this series,
I think it is not the direction the majority wants DPDK to go.
We tend to avoid compilation options.

> @@ -579,15 +579,23 @@ struct rte_mbuf {
>  	RTE_MARKER cacheline0;
>  
>  	void *buf_addr;           /**< Virtual address of segment buffer. */
> -	/**
> -	 * Physical address of segment buffer.
> -	 * This field is invalid if the build is configured to use only
> -	 * virtual address as IOVA (i.e. RTE_IOVA_AS_VA is 1).
> -	 * Force alignment to 8-bytes, so as to ensure we have the exact
> -	 * same mbuf cacheline0 layout for 32-bit and 64-bit. This makes
> -	 * working on vector drivers easier.
> -	 */
> -	rte_iova_t buf_iova __rte_aligned(sizeof(rte_iova_t));
> +	RTE_STD_C11
> +	union {
> +		/**
> +		 * Physical address of segment buffer.
> +		 * This field is invalid if the build is configured to use only
> +		 * virtual address as IOVA (i.e. RTE_IOVA_AS_VA is 1).
> +		 * Force alignment to 8-bytes, so as to ensure we have the exact
> +		 * same mbuf cacheline0 layout for 32-bit and 64-bit. This makes
> +		 * working on vector drivers easier.
> +		 */
> +		rte_iova_t buf_iova __rte_aligned(sizeof(rte_iova_t));
> +		/**
> +		 * Reserved for dynamic field in builds where physical address
> +		 * field is invalid.
> +		 */
> +		uint64_t dynfield2;
> +	};