[PATCH] common/cnxk: allow enabling IOVA field in mbuf

[Jerin Jacob]

On Mon, Oct 14, 2024 at 4:37 PM Shijith Thotton <sthotton at marvell.com> wrote:
>
> Value of RTE_IOVA_IN_MBUF was always disabled on cnxk platforms, as IOVA
> in the mbuf is not required. This change modifies that behavior,
> allowing RTE_IOVA_IN_MBUF to be enabled if the build option
> -Denable_iova_as_pa=true is explicitly specified.
>
> Signed-off-by: Shijith Thotton <sthotton at marvell.com>
> ---
>
> diff --git a/config/arm/meson.build b/config/arm/meson.build
> index 012935d5d7..ca54524376 100644
> --- a/config/arm/meson.build
> +++ b/config/arm/meson.build
> @@ -439,10 +439,7 @@ soc_cn9k = {
>      'description': 'Marvell OCTEON 9',
>      'implementer': '0x43',
>      'part_number': '0xb2',
> -    'numa': false,
> -    'flags': [
> -        ['RTE_IOVA_IN_MBUF', 0]
> -    ]
> +    'numa': false
>  }
>
>  soc_cn10k = {
> @@ -451,8 +448,7 @@ soc_cn10k = {
>      'flags': [
>          ['RTE_MAX_LCORE', 24],
>          ['RTE_MAX_NUMA_NODES', 1],
> -        ['RTE_MEMPOOL_ALIGN', 128],
> -        ['RTE_IOVA_IN_MBUF', 0]
> +        ['RTE_MEMPOOL_ALIGN', 128]
>      ],
>      'part_number': '0xd49',
>      'extra_march_features': ['crypto'],
> diff --git a/drivers/common/cnxk/meson.build b/drivers/common/cnxk/meson.build
> index dc2ddf1f20..bba780e750 100644
> --- a/drivers/common/cnxk/meson.build
> +++ b/drivers/common/cnxk/meson.build
> @@ -108,4 +108,13 @@ deps += ['bus_pci', 'net', 'telemetry']
>
>  require_iova_in_mbuf = false
>
> +cnxk_socs = ['cn9k', 'cn10k', 'cn20k']
> +
> +# Enable RTE_IOVA_IN_MBUF only if enable_iova_as_pa is set explicitly, else disable it
> +if meson.version().version_compare('>=1.1.0')
> +    if '-Denable_iova_as_pa' not in meson.build_options() and soc_type in cnxk_socs
> +        dpdk_conf.set10('RTE_IOVA_IN_MBUF', false)
> +    endif
> +endif

Since this is added in driver/common/cnxk, it will be late to decide.
For example,

Following PMDs will have mis match:
common - cpt, dpaax, idpf, ionic
bus - cdx, dpaa, fslmc, ifpga, uacce

I think, this check needs to move up in the chain. @Richardson, Bruce
Any thoughts on cleanly adding this kind of check in top-level meson
objects?


> +
>  annotate_locks = false
> --
> 2.25.1
>