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

[Michael S. Tsirkin]

Quoting r. Roland Dreier <rdreier at cisco.com>:
> Subject: Re: [PATCH 1/7] IB/core - Add DMA mapping functions to allow device drivers to interpose
> 
>  > However, this means that the API must give the HCA the choice of
>  > what to keep inside the mapping. This could mean, for example, returning
>  > a structure that can include dma_addr_t, void*, or both, and a flag to
>  > distinguish between the two.
> 
> It's an interesting idea.  However I think it may be more trouble than it's
> worth, for at least two reasons.  First, the wrapper for dma_map_sg() will
> probably become really ugly, although maybe there's a clever idea.

Oh, my guess is s/g is usually for long messages so we can just always do dma in
that case.

> Second,
> the consumer right now only gets to pass a 64-bit address into the work
> request posting functions.  I don't think we really want to change that
> interface, so the driver would have to encode the flag in the address somehow
> anyway.

But how?
Wait, work request posting functions actually get a virtual
address and a key, not a dma address. Maybe something can be done with this?
Say, we have get_dma_mr at the moment - maybe we could have a special
mr, and let the dma functions also select which mr to use?


> Also handling highmem is a problem.  ipath just depends on 64BIT so it
> avoids the problem.  I guess mthca could only return a kernel virtual
> address if one exists, and always use DMA for highmem pages.  So that
> isn't really a serious objection.

Right.

-- 
MST