[openib-general] [PATCH v2 1/7] IB/core - Add DMA mapping functions to allow device drivers to interpose

[Or Gerlitz]

On 12/5/06, Roland Dreier <rdreier at cisco.com> wrote:
> I think this seems reasonable.  And I think it also provides a way to
> address some hypothetical future situation where lowmem pages don't
> have a kernel virtual address -- you would just have to use this
> type of cookie implementation everywhere.

Such an approach would be much more cleaner and result in much less
(~zero changes) in the ulp level, just replace dma_map_xxx calls with
ib_dma_map_xxx calls.

A problem  see with the dma_addr_t being a cookie into a table of kv
addresses is that its legal for a consumer to use dma_addr_t with an
**offset** . So she gets addr y from ib_dma_map_xxx and then uses y +
offset in the SGE provided to ibv_post_send/recv or to the fmr map
function.

So this table is actually a search tree which allows you to match an
offset-ed dma_addr_t returned by dma_map_xxx called by ipath
ib_dma_map_xxx with its associated kvaddr.

I see now that i have managed to confuse myself b/c as Roland wrote
below and i have agreed we don't actually have the kv addr for and
unmapped page before the ipath driver maps it ie when it attempt to
use the page... It becomes late here... am i inventing a non existant
problem with the offset?

> (Although I don't think using kmap()/kunmap() is really the right
> approach -- you should probably just do kmap_atomic()/kunmap_atomic()
> only while you are actually using the page.  But the basic approach of
> using the dma address as a cookie into a mapping table seems sound to
> me -- you are basically doing a real sw iotlb)
>
> Or -- does this seem reasonable to you?

I agree that care should be made to do kmap_atomic/kunmap_atomic only
when there is actual need to access the page by the ipath driver.

Or.