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. _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
