[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