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

Steve Wise swise at opengridcomputing.com
Sun May 18 09:46:21 PDT 2008



Or Gerlitz wrote:
> Steve Wise wrote:
>> - device-specific alloc/free of physical buffer lists for use in fast
>> register work requests.  This allows devices to allocate this memory as
>> needed (like via dma_alloc_coherent).
>>
> Steve,
> 
> Reading through the suggested API / patches and the previous threads I 
> was not sure to understand if the HW driver must not assume that it has 
> the ownership on the page --list-- structure until the registration work 
> request is completed - or not.
> 

Yes, the driver owns the page list structure until the WR completes (ie 
is reaped by the consumer via poll_cq()).

> Now, if ownership can not be assumed (eg as for the SG list elements 
> pointed by send/recv WR), the driver has to clone it anyway, and thus I 
> don't see the need in the ib_alloc/free_fast_reg_page_list verbs.
> 
> If ownership can be assumed, I suggest to have the core use the 
> implementation of these two verbs as you did that for the Chelsio driver 
> in case the HW driver did not implement it (i.e instead of returning 
> ENOSYS). In that case, the alloc_list verb should do DMA mapping FROM 
> device (I think...) since the device is going to do DMA to read the page 
> list, and the free_list verb should do DMA unmapping, etc.
> 

Some devices don't need DMA mappings at all (chelsio for instance). The 
idea of a device-specific method was so the device could allocate a 
bigger structure to hold its own context info.  So a core service that 
sets up DMA, in my opinion, isn't really useful.

Steve.




> Or.
> 



More information about the general mailing list