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

[Steve Wise]

Or Gerlitz wrote:
> 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?
>

My point is that if you do the mappipng at allocation time, then the 
failure will happen when you allocate the page list vs when you post the 
send WR.  Maybe it doesn't matter, but the idea, I think, is to not fail 
post_send for lack of resources.  Everything should be pre-allocated 
pretty much by the time you post work requests...

Steve.



> Or.
>