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?
/Bruce
