20/02/2023 16:35, Bruce Richardson:
> On Mon, Feb 20, 2023 at 04:30:20PM +0100, Thomas Monjalon wrote:
> > 20/02/2023 16:07, Morten Brørup:
> > > With the new viewing angle, the current define RTE_IOVA_AS_PA makes more
> > > sense to me now than before. So we should probably stick with it, rather
> > > than introduce something that might confuse developers who already have
> > > the same viewing angle.
> > >
> > > But it still seems counterintuitive to me that disabling some feature
> > > ("enable_iova_as_pa") is not supported throughout DPDK; the logic seems
> > > inverted. Apparently, it also makes it difficult to assign good titles to
> > > patches that support disabling such a feature. :-)
> > >
> > > <irony>
> > > On the positive side, since everything supports this "enable_iova_as_pa"
> > > feature, we don't need to add it to the PMD feature list. If the logic
> > > wasn't inverted like this, the PMD feature list should probably reflect
> > > which PMDs supported the "iova_as_va_only" compile time option. ;-)
> > > </irony>
> >
> > That's a change I would like to do:
> > The Meson variable in the drivers should be "support_iova_as_va"
> > and would mean we can compile the driver when "enable_iova_as_pa" is false.
> >
> All drivers (that I am aware of) support iova_as_va. What is missing is
> drivers supporting "iova_as_va_only". Any reference to va without the word
> "only" on it will be misleading.
>
> A third way of looking at it, is to work with the fact that the reason
> drivers require changes to support this "va_only" mode, ro no-pa mode, is
> due to the fact that the mbuf no longer tracks iovas and only VAs.
> Therefore, we can have a variable called "require_iova_in_mbuf", which
> would hopefully cut through this whole va vs pa addition/subtraction mess.
> What do you think?
Yes "require_iova_in_mbuf" describes better the reality,
so it is simpler to understand.
