09/03/2023 12:23, fengchengwen:
> On 2023/3/9 15:29, Thomas Monjalon wrote:
> > 09/03/2023 02:43, fengchengwen:
> >> On 2023/3/7 0:13, Thomas Monjalon wrote:
> >>> --- a/doc/guides/rel_notes/release_22_11.rst
> >>> +++ b/doc/guides/rel_notes/release_22_11.rst
> >>> @@ -504,7 +504,7 @@ ABI Changes
> >>> ``rte-worker-<lcore_id>`` so that DPDK can accommodate lcores higher
> >>> than 99.
> >>>
> >>> * mbuf: Replaced ``buf_iova`` field with ``next`` field and added a new
> >>> field
> >>> - ``dynfield2`` at its place in second cacheline if ``RTE_IOVA_AS_PA``
> >>> is 0.
> >>> + ``dynfield2`` at its place in second cacheline if ``RTE_IOVA_IN_MBUF``
> >>> is 0.
> >>
> >> Should add to release 23.03 rst.
> >
> > Yes we could add a note in API changes.
> >
> >> The original 22.11 still have RTE_IOVA_AS_PA definition.
> >
> > Yes it was not a good idea to rename in the release notes.
> >
> >>> -if dpdk_conf.get('RTE_IOVA_AS_PA') == 0
> >>> - build = false
> >>> - reason = 'driver does not support disabling IOVA as PA mode'
> >>> +if not get_option('enable_iova_as_pa')
> >>> subdir_done()
> >>> endif
> >>
> >> Suggest keep original, and replace RTE_IOVA_AS_PA with RTE_IOVA_IN_MBUF:
> >> if dpdk_conf.get('RTE_IOVA_IN_MBUF') == 0
> >> subdir_done()
> >> endif
> >
> > Why testing the C macro in Meson?
> > It looks simpler to check the Meson option in Meson.
>
> The macro was create in meson.build:
> config/meson.build:319:dpdk_conf.set10('RTE_IOVA_AS_PA',
> get_option('enable_iova_as_pa'))
> It can be regarded as alias of enable_iova_as_pa.
It is not strictly an alias, because it can be overriden via CFLAGS.
> This commit was mainly used to improve comprehensibility. so we should limit
> the 'enable_iova_as_pa' usage scope.
> and the 'if dpdk_conf.get('RTE_IOVA_IN_MBUF') == 0' is more comprehensibility
> than 'if not get_option('enable_iova_as_pa')'
To me, using Meson option in Meson files is more obvious.
Bruce, what do you think?
> >> Meson build 0.63.0 already support deprecated a option by a new option.
> >> When update to the new meson verion, the drivers' meson.build will not be
> >> modified.
> >
> > I don't understand this comment.
>
> I mean: the option "enable_iova_as_pa" need deprecated future.
Why deprecating this option?
> Based on this, I think we should limit 'enable_iova_as_pa' usage scope, this
> allows us to
> reduce the amount of change effort when it's about to deprecated.
I don't plan to deprecate this option.
And in general, we should avoid deprecating a compilation option.
