[ofa-general] [PATCH RFC v3 1/2] RDMA/Core: MEM_MGT_EXTENSIONS support

[Or Gerlitz]

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.