Steve Wise wrote:
dma mapping would work too but then handling the map/unmap becomes an
issue. I think it is way too complicated too add new verbs for
map/unmap fastreg page list (in addition to the alloc/free fastreg page
list that we are already adding) and force the consumer to do it. And
if we expect the low-level driver to do it, then the map is easy (can be
done while posting the send) but the unmap is a pain -- it would have to
be done inside poll_cq when reapind the completion, and the low-level
driver would have to keep some complicated extra data structure to go
back from the completion to the original fast reg page list structure.
And certain platforms can fail map requests (like PPC64) because they
have limited resources for dma mapping. So then you'd fail a SQ work
request when you might not want to...
I see the point in allocating the page lists in dma consistent memory to
make the mechanics of letting the HCA to DMA the list easier and
simpler, as I think Roland is suggesting in his post. However, I an not
sure to understand how this helps in the PPC64 case, if the HCA does DMA
to fetch the list, then IOMMU slots have to be consumed this way or
another, correct?
Or.
_______________________________________________
general mailing list
[email protected]
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
