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

[James Lentini]

On Fri, 3 Nov 2006, 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. 

Work requests posted using ib_post_send/recv are specified using a dma 
address obtained using the appropriate Linux DMA mapping API function. 
They are not virtual addresses.

> 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
> 
> _______________________________________________
> openib-general mailing list
> openib-general at openib.org
> http://openib.org/mailman/listinfo/openib-general
> 
> To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
>