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 <sthot...@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;
> + };
