[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