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

[Ralph Campbell]

On Fri, 2006-11-03 at 01:44 +0200, Michael S. Tsirkin wrote:
> 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.

I'm open to suggestions if you have a proposal for making the interface
more usable.