[openib-general] [PATCH] fmr pool: remove unnecessary pointer dereference
Or Gerlitz
ogerlitz at voltaire.com
Tue Jul 11 00:30:52 PDT 2006
Roland Dreier wrote:
> Or> So this means that a ULP can not map on the same time these
> Or> two page sets: <A,B> and <A,B,C> suggesting the verbs layer to
> Or> have A being the IOVA at the HCA IOMMU (eg MPT/MTT in the
> Or> mellanox case), and getting some A* to be used for the second
> Or> map?
>
> I don't follow. The FMR implementation will always use the IOVA
> passed in by the consumer, so a ULP can always map whatever page sets
> it wants at whatever IOVA it wants (subject to alignment restrictions,
> of course). So there's no point in making the IOVA be an output
> parameter from the FMR pool implementation, since the IOVA from the
> consumer will never be changed.
OK, i was confused to think that the ib verbs layer, namely
ib_map_phys_fmr gets u64 *iova where i see now it gets u64 iova, so
indeed there's no point with the FMR pool have the iova being a pointer
in its API, sure, you can go a head and commit this fix allover, to iser
as well, i don' think its 2.6.18 material since it does not fix any bug.
As for my example from above, i was thinking and looking now in the
Mellanox PRM proves this thought to be wrong, that as of the HCA the
IOVA provided to the FMR map verb i just as ***suggestion*** to the
actual VA used for this mapping (this suggested VA had a restriction on
the "fmr page size" lower bits etc etc). So the HCA can set another VA
and reports it back through the driver as an out param of the FMR map
verb. This would allow for mapping the same page concurrently (as the
first one) in two maps, which for itself does not make much sense, the
only example i was able to think of is user space someone that wants to
read into the same page from two reading flows in parallel with direct
IO, never mind.
Or.
More information about the general
mailing list